Pre-Sales Customer Success to Tech Handoff

Tanuj Diwan

Hi everyone, we have started helping enterprises in Indonesia with Feedback solutions with our CX product. And our current state of customer success starts from pre-sales till upselling. 

As we provide custom solutions it involves a lot of tech communications between clients and CS team. However we are facing a consistent problems of clients asking for more customizations as a Scope is not defined.

Has anyone in the community gone through this process at a SAAS startup and uses any format for Scope of Work and getting it finalized even before the tech team involvement.

If yes could you please share a sample doc or process followed.

Thanks a lot

 

Alex Turkovic

Hi @Tanuj Diwan - unfortunately I am unable to share specific docs, however I can provide a bit of guidance on how we've handled this sort of thing.

Standard Entitlements: All of our offerings (both product and services) have a pre-defined and published set of entitlements which dictates what features, functionality and services the customer receives upon purchase of certain line-items. The product entitlements are pretty specific on intended functionality and similarly, the services entitlements define how much work we will do for the customer.

Custom Development: Customers can purchase custom development if certain features are necessary to solve a customer's specific problem/fulfill the need. These requests are funneled through formal channels in our product organization and are subsequently approved or denied based on a variety of factors. The scoping of these requirements dictates how much effort will be involved in this custom development and in turn defines the price point to the customer based on specific hourly rate. Most of this work is then made widely available across the platform, even though it was developed for and funded by a specific customer.

Statement of Work: All of the above - and any deviations from the above are expressly written out at deal close into a statement of work which can be referenced as the project continues until A) it is complete or additional work is necessary via addendums.

I hope this helps.

Tanuj Diwan

Hi @Alex Turkovic Thanks for the response, I understand the process of custom development and we follow a similar process. Only thing I am strugling with mapping that scope of work as sometimes once you start designing the prototype customers keep on adding stuff they need which require extra effort which goes to even weeks. Untill now I have not been able to come up with a doc/guide to map this for Custom Development.

You mentioned something about statement of work, how you define it when there is complexity involved in a feature/solution request and you need time to actually do the research to give an answer but has to be done urgently because customer is pushing for the project to start soon. Only in those cases its difficult to really map the scope before hand

Alex Turkovic

Agreed that it can be extremely difficult to get a very detailed scope defined at the outset, knowing that the very act of prototyping is a creative venture which will require iteration.

The best way I've handled this in the past is to ensure a product manager is assigned from the beginning to help with the scoping of the request. The 80/20 rule is definitely at play here as you might be able to catch 80% of the scope of what needs to be built and the other 20% will reveal itself as development progresses.

Being as specific on intended functionality up-front is important. Equally important in the contract/SOW is language that "scope creep" could delay the project and require additional addendums/fees.

This is why I feel it always boils down to negotiation skills and proper expectations. If additional requests are made during dev which detract from the MVP (minimum viable product), then a dialogue will need to be had with the client as to the side effects (additional costs, more time, etc.)

Tanuj Diwan

I think PM at the start of scoping would be the ideal way of addressing this situation for now. Thanks @Alex Turkovic 

Laura Lakhwara

I don't have anything I can share outside of the company, but we were doing all custom development. Therefore, our solutions engineers would actually participate as sales engineers (we were small) and create a custom professional services solution as a part of the sale. 

We then standardized this to three tiers which gave the customer options to select which would then be put into a SOW. We learned the more structure we gave the more success that was driven with both the customer and our delivery. 

If anything was added or changed, we would have additional engineering hours costs that would be discussed and added to the agreement. 

Our sales team could not do this without technical involvement. By bringing them in earlier into the pipeine, it saved us a ton of work and delivery delays post sales. 

Tanuj Diwan

Thanks Laura for this insight, I can relate this to what @Alex Turkovic also mentioned about having a Tech/Product guy act as Sales Engineer to create the SOP. I would try to follow this from now on and will measure the impact.