One Key to Driving Project Alignment in a Modern SaaS Company
The relationship between the Sales and Services teams is probably the most critical connection in a SaaS company. That’s because company success and valuation hinge on building a larger and larger base of happy, renewing customers. Get the relationship between Sales to Service right and you have taken a huge step toward building that base of delighted customers. Mess it up and it can start a negative feedback loop from which it is hard to recover.
There are many dimensions to the Sales/Services relationship, from how services work is defined, presented and priced to the role of sales during ongoing projects. But this quick essay is about just one aspect, which is the handoff between sales and services at the start of a project.
In your company, when a new services project is sold, how is the information about the project communicated to the services team? Is it thrown over a metaphorical wall, hopefully caught, and not fumbled, by services. Or is it transferred in a well-defined process, so that everything learned during the sales cycle is transferred to the Services team?
Here is an example of how not to do it. Real story from a real services leader at a real company.
Me: Tell me how a new project is conveyed to you?
Him: Well, we get an email, and we are supposed to read the documents in a shared folder with the documents from the sales cycle, and the SOW. And based on that we know what the scope of the project is.
Are you freaking kidding me?! You mean to say that the relationships, the context and the nuances of the customer’s situation are wasted, just dumped out onto the floor – basically thrown away – between the two phases? That is, frankly, a travesty. For me, this was basically the discovery of a new low, a new benchmark for a “worst practice”.
To make the point even more clear, let me ask you, the reader of this minor rant, a question. How do you feel when, after connecting to – for example – your internet service provider or your cable company, and then when you are transferred for a third time, with no handoff, and you have to start over and explain your problem AGAIN from the start? Pretty cranky, I bet.
As I mentioned before, I call this whole approach the “throwing it over the wall” mode”. The image in my mind is two teams, each on their own side of a high brick wall, with a project and its context lobbed over the top. Landing with a thud at someone’s feet.
If this “Wall” model is anywhere close to the mark in your organization, congratulations on being typical. Because it is often the case that the transition between closing a new customer and selling a project and the start of the delivery of the project is pretty clumsy.
The good news is that it is also pretty easy to fix this issue. There is a clear best practice, and you can basically put it in place tomorrow.
Here are five simple processes that comprise the best practice. Put them in place and your next transfer of a project from Sales to Services will look like the baton handoff in the Olympic 4000 meter relay.
One. Have a Meeting
Yes, you can have a form. You want a form, describing the key aspects of the project? Fine, have a form, filled out by Sales and delivered to Services. But please have a meeting as well.
No one likes meetings, but sometimes we humans do need to talk together in a group at the same time, in a shared space, to communicate detail and nuance. This is one of those times.
So every new project needs to start with an internal transition meeting – the Handoff – with a structured agenda that covers the who, the what and the why of the customer’s situation. And especially, the who’s), like who is the boss, who is the key influencer, who is the cynic and who is the ally.
Two. Have a Briefing Deck
In the meeting I just convinced you to have, use a structured, five slide deck as a tool to guide the exchange. Slide one, project scope. Slide 2, project schedule. Slide 3, project and schedule drivers. Slide 4, brief descriptions of the customer’s team, both their names and roles and their personas and agendas.
And slide five, perhaps the most important slide, known risks. Known risks are things like “needs a new feature” or is “averse to changing their existing process” or “needs to be live in 15 days”..
If you do this right, no one can say later that they were not told, or did not know a crucial fact about the project. There will be no bus-under-throwing on this project!
Three. Do the Kickoff Together.
This is absolutely critical. The project kickoff meeting is the actual relationship handoff from Sales to Services, made visible to everyone. Sales starts the meeting:
Thanks everyone for joining! This is an exciting day, because it marks the formal start of the project! And that means that we will be expanding our team, and transitioning the lead role to Ken, who is responsible for ensuring your success with our product.
Ken and I and our teams have spent quite a bit of time talking about you – behind your back of course – so that his team understands what you are trying to accomplish. At this point he is fully up-to-date – Ken, would you like to get us started?”
See how easy that was?
This simple, orchestrated handoff conveys to the customer that you are part of one company, one team, with one shared goal: to make them successful.
Four. Yes DO READ the SOW.
For all I denigrated the “worst case” example above, they were doing one thing right. EVERYONE on a project must read the SOW. Only that way can we be sure that everyone knows the specific commitments made in terms of scope and schedule. It is far from sufficient, but reading the SOW is completely necessary. And that means everyone on the project.
Five. Really dig in on those Known Risks
Remember slide 5 above? The one that lists known risks? In the meeting, take the time needed to explore the known risks. Ask questions. How will you handle the new feature request? How will you address the fact that the customer has an impossible schedule to meet?
And then focus on what you are going to do to mitigate those risks. Add a specialist to the team? Start a weekly meeting with the Dev team on the feature that was promised? STart to manage the customer to a new schedule expectation?
====================
As I said at the top, an effective handoff addresses just one aspect of the Sales to Services relationship that is at the heart of SaaS customer success. But it is an easy one to nail. So don’t put it off.
With the handoff well executed, the project is immediately on a better footing. And more importantly, the relationship with the customer is on a better footing. Communication channels are opened, expectations are set. And that means that the path to renewal has been illuminated.
Because the handoff, while just the first step, is in fact a foundation for everything that follows. It is part of an approach, when combined with standardized project components, an effectively defined roles for Sales over the course of the project and effective oversight and escalation models, that drive delivery times down, costs down and customer delight up. And that will show up in churn, which will show up in valuation.
It is “the hand bone’s connected to the arm bone thing”, but in this case the handoff is connected to the valuation of the company. Remarkable, huh?
Some of the other aspects of the relationship between Sales and Service benefit from products like WorkRails, which can (for example) help reinforce standard project components and deliverables, which drives up quality. But for the handoff, you just need a template of five slides, and a commitment to start doing things in a standard way.
I will get into some of those other aspects of this essential relationship in upcoming editions of Reflections of Services Leader.
Till then, crush those projects.
#crushthoseprojects. #workrails
