Onboarding - SoW Sign-Off

Hi All,

Hope you had a lovely Valentines weekend.

Does anybody use a Schedule of Work to set and manage expectations in the onboarding stage, and then seek sign-off before moving into a BAU phase? This may include specific activities needing to be delivered, specific targets/goals to be met or specific gates to go through before progress further.

Thoughts?

Find more posts tagged with

Outcomes

Data

Retention

Comments

Ben Wright

Hey Matt,

Just throwing in my two cents here, one of the practices that we incorporate into our Onboarding Process, was an executive sign off call, whereby the buyer + those that would be administering the software to the org, would be required to walk through the technical pre-requisites, but also align on the business reason behind why the software was purchased in the first place.

This acts as gate, and as a strategic step to ensure all stakeholders are aligned before progressing into roll out.

Happy to walk through this process with you if needed!

Will Stevenson

Hey Matt,

Agree with everyone else here.

I think the overall concept of gaining alignment upfront and across all parties is really important. In addition, (in my experience) continued visibility through the onboarding process is just as important. That said, there might be a few ways to get there.

I've used shared docs, generic project management software, etc. to do this in the past, but it's actually why I created Onboard.io.

Would be happy to chat further.

Wayne McCulloch

Hey @Matt Myszkowski - we incorporate this into the Customer Success Plan (CSP). The CSP has 5 distinct sections that we share with the customer.

1. Value Defined (Onboarding)
2. Value Consumed (Adoption)
3. Value Realized (Retention)
4. Value Expanded (Expansion)
5. Value Confirmed (Advocacy)

Each of these sections has the equivalent of an SOW built into it. The key is that we wanted to not use the term SOW with a customer (CSP seemed more aligned and clear on responsibilities etc) but still have a document the customer and vendor agree to throughout the customer lifecycle. Having said that, the thinking around this topic is dead-on - document what success looks like, to a) attain it together and more importantly b) celebrate these milestone in a meaningful way).

Cheers,
Wayne

Andreas Knoefel

Hi Matt,

I do this all the time, not just in onboarding, so that there are is a clear understanding of what each party needs to do, in what timeframe, and how we move forward.

In particular in onboarding, where you have potentially several parties at the customer involved, and Time-to-Value is highly impacted, good project management is mandatory. That doesn't mean every time a bespoke plan. A good template that has everything laid out sufficed for more OOTB solutions. The high level plan/expectations are shared during Sales, and refined at kickoff, when actual dates and names for responsible parties are filled in and locked in. Helps a lot in scenarios where you have delays on the customer side.

I do something similar for low ARR situations, to set expectations and trigger when a customer is falling behind.

Since I emerged into CS from Professional Services, where Schedule of Work, project mgmt etc. are common practice, happy to talk more offline.

Matt Myszkowski

Great point on the tech vs business requirements needing to be called out separately.

Matt Myszkowski

Hi Jung,

This sounds great. Let me send you a DM for us to connect offline.

Thanks!

Jung Kim

Hi Matt,

We utilize a business requirements document that accounts for the inevitable discovery and slight scope change that occurs in the beginning of the customer implementation & launch process. This clarifies the existing deliverables & any new ones that have come up (early stage company, so there are always a few exceptions that need to be accounted for).

This doc is utilized as a part of the key milestones to confirm and commit to the go-live. Happy to chat further and send a template if you ever want to!

Best,

Jung

Srikrishnan Ganesan

Agreed with Jeff. It is standard practice to use SOWs for onboarding mid-market and enterprise customers.

Few pointers:

1. Add milestones, timelines to the list so you can also call out by when you expect customers to deliver on some things for you to be able to finish on time!

2. Sometimes it helps to separate out business requirements and technical requirements.

3. Agree on high level deliverables - don't let this document turn into a long wishlist that you cannot deliver on!

Jeffrey Kushmerek

Matt,
Yes- this is essential. If you don't list all the tasks, dependencies, and assumptions, you will inevitably have projects that are never signed off on, never out of your teams' hands, and possibly affecting revenue recognition. I like to list the tasks out in a tool like Basecamp or Baton to then track them . Happy to get into more detail