For companies that provide professional services to their customers, they often contract these services in a statement of work (SOW). This document serves two purposes; it gives the customer a clear understanding of what services will be performed, and it protects the service provider by setting limits to what will be performed. The SOW is a critical component to a business because, based on how it's written and interpreted, it can literally make or break your services business. For this reason, companies need to be very careful in who they allow to scope, write, and approve SOWs.
I had the chance to sit down with Greg Higgins (VP, Professional Services & Support @ Splash) and we discussed some of the challenges his organization faces in managing the SOW process as well as the pros and cons that we see in assigning SOW responsibilities by various roles:
Sales team (core product new business & expansion)
Pros:
If the sales team could write perfect SOWs, it would be the dream approach. They are the closest to the customer, they are hearing first hand and in real time what the customer wants, and they are typically responsible for all other contract execution. At Spash, Greg and team try to make it as easy and safe for sales to contract services, so they provide them two "menus" of services. One menu is customer facing and aids in the services discussion. The other is a larger, "secret menu", that is for sales to know what can be added to a published service. That allows sales to customize an offering by still using some off-the-shelf language.
Cons:
Letting sales write SOWs is very unsafe. Not because sales people have ill intentions or aren't intelligent, it's because they don't have the domain knowledge or experience to identify all of the nuance and detail that is needed to properly scope a service. So what inevitably happens is that SOWs are written with ambiguity. This leads to a potential litany of problems such as: difficult conversations with customers around expectations once engagements commence; scope is over or underestimated; multiple change orders are needed along the way; intended profit margins are missed; resources are overutilized. Greg points out that to the sales team, selling product licenses is much easier than spending time on services. The sales team also has a better compensation structure for products vs. services. So putting in a ton of effort to sell services doesn't make sense.
Sales Engineering team (Solutions Consultants, Solutions Architects, etc.)
Pros:
From and accuracy perspective, leveraging the Sales Engineering team (vs. the sales team) to write SOWs tends to result in a more accurate contract. They are familiar with asking discovery questions and getting to the route of requirements. They also understand the capabilities of your product and ways to aid in product extensibility through custom services.
Cons:
Sales Engineers probably have a better understanding as to the level of effort (LOE) that goes into a service being delivered. But it's still not their job and they don't have that domain experience. Since they don't deliver services or manage the delivery of services, it's unreasonable for them to estimate the LOE with any degree of accuracy. So although the SOW language should be more accurate, you'll still have issues with intended profit margins being missed and resources are overutilized.
Customer Success team (relationship managers)
Pros:
See all of the same "Pros" as the sales team. With a minor exception if CSMs don't already perform contract execution work. One unique pro for CSMs is that they probably have a deeper understanding of what their customer really needs to be successful and how much hand holding it's going to take to get them there.
Cons:
See all of the same "Cons" as the sales team. With the extra Con that they don't work with net new accounts. So you'll still need someone writing SOWs for new customers. At Splash, Greg says that their CSMs will help write SOWs for the Sales team. That adds an extra layer of communication and hand offs and causes the sales team to get frustrated with the time it takes to draft the SOW. It's actually a similar frustration to Sales. Customer Success Managers get frustrated because they want to be spending their time driving adoption, building relationships, and securing renewals.
Professional Services team (practice leaders, senior practitioners)
Pros:
Maximum accuracy. Use your services team if you want to ensure that SOWs are written in a way that accounts for all scope details, have the best possible estimation of LOE, and protects the organization from scope creep.
Cons:
If you're contracting a lot of services with SOWs, this can become a huge time commitment. With the delivery management requirements of this team, they may be slower to draft SOWs, leading to internal friction. If you're maintaining low, break even, or loss-leader margins on services in support of your product, adding a full-time resource to manage SOWs is unviable.
Services Sales team (new and expansion services business)
Pros:
Service sellers have the domain experience and relationship with practice leaders to write accurate SOWs and know when to ask for more help. They are infrequently constrained for bandwidth and can quickly respond to requests. By having these folks act as hunters, they can build the services pipeline, assist sales and CS, and free up the services delivery team from scoping activities that may never lead to actual engagements.
Cons:
Service sellers can be an expensive resource, so you need to be selling services as a revenue center to fund their position. Typically, the sacrifice made to accuracy by having this role is marginal, but can still exist. If their compensation isn't tied to scope accuracy, you may have problems with delivery feasibility and or margins of the completed projects.
OK, so just tell us, "who should be writing SOWs?"
Unfortunately the answer is "it depends". It depends how large and mature your company is (in terms of sellers, customers, service practitioners and engagements). There is an answer to this question for each situation and if you'd like to reach out for a free consultation, we'd be happy to talk about your unique circumstance. But to be able to give some advice, here's one scenario:
Let's say you have a B2B SaaS company of 200 employees. The services team is well established. It's run as a cost+ (minimal margin) business. The sales team contracts to all new customers and works the expansion deals (including services) for existing customers. There is a Sales Engineering (SE) team that is responsible for demos, RFP responses, and solution feasibility analysis. You have a customer that wants to use your product but it's been identified in the sales process that custom services will need to be performed to make the product work for them. Here's how I would approach this:
Have the SE run discovery and scope the work to be completed
Have them assess if there are any "off the shelf service products" (predefined SOWs) that they can sell to the customer.
If not, they will provide all discovery details to the services Practice Leader. They can even draft all of the SOW language. The Practice Leader provides the LOE for said scope and partners with sales on how to price it for margin. Sales delivers it to the customer.
If there is a predefined SOW that needs a little bit of customization, the SE informs the Practice Leader, the Practice Leader makes a small adjustment and sends it to Sales for delivery to the customer.
In this scenario, you have 3 people involved, but the work is evenly distributed and not outside the comfort zone of any one role. Because of the division of labor, everyone stays focused on their prime responsibilities while supporting the opportunity as best as possible. And the SOW that is delivered to the customer is something that the entire organization will feel comfortable and confident with. Feel free to comment below and let us know how your organization handles the authoring of SOWs.
Comments