If you’re new to this newsletter then welcome! Thank you to the 1,400 revenue operations professionals who continue to subscribe to this newsletter. You’re the reason I continue to write each and every week on a Go To Market related topic. When I have a template to share paid subscribers will get access. I don’t have all the answers in revenue operations. That’s impossible because RevOps can be uniquely situated for each unique situation. But what I hope you can take away a few guiding principles or tactical snippets which you can use in your day to day. Before jumping into the newsletter, let’s hear from our sponsors that keep most of this newsletter free to readers.
Salesforce is powerful and robust. But it wasn’t built to help sales teams identify the next steps to take and guide them on who they need to build relationships with in order to win deals. Prolifiq helps Revenue & Sales Operations professionals solve this gap through strategic account planning and sales intelligence technology.
Most forecasts suck. It’s not just an accountability problem. It’s also an alignment and an insights problem. And those problems affect ALL REVENUE WORKFLOWS including pipeline management. Wouldn’t it be nice to align teams and to hold them accountable with trusted data insights? That’s how you start to boost sales performance with better pipeline management and forecast accuracy of over 95%. Talk to BoostUp
RevOps aren’t system admins. Growblocks is building the 1st RevOps platform, giving you full funnel analytics, continuous monitoring and revenue planning tools - so you can become strategic. Check it out here.
A few weeks back we covered operations support for the Presales function. I thought it would be important to think through process design and the exact deliverables that may be needed in your process.
In a typical sales process the first stage focuses on qualifying and discovering. In the qualification stage, you’re quickly assessing whether you should move forward or not. If you’re a RevOps professional and you’re looking to build out your SDR Qualification function check out a previous article on the topic here. The Discovery stage will focus on whether or not there is a real problem at the client which you can solve. This is all about context building.
Questions such as:
Tell me about your company.
Tell me about your role, what does success look like for you and how are you measured?
What problem(s) are you trying to solve for?
Amongst these, how would you prioritize them?
What business metrics do these impact?
Who else are you working with internally and externally to solve for this?
What have you tried in the past? How did those work out?
How urgent and by when would you need a solution in place?
Obviously the goal here is to not turn the Discovery call into an interrogation. This is where becoming a smooth operator with Discovery is critically important.
At the end of the Discovery call the goal is to firm up a time to showcase your solution with a demonstration. You may have already given them a short preview in the Disco call but truth be told you may be better off saving it for a more detailed, in-depth demo.
There’s plenty of sage advice out there for how to run a demo but my former colleague Kevin Dorsey put an excellent framework together from his 30 Minutes to President’s Club checklist manifesto. Shout out to my PatientPop Mafia crew!
But we may need to go beyond the AE Demo
The AE Demo should limit the number of features you showcase. The goal is to avoid showing ALL the bells and whistles. Prospects aren’t impressed by the number of features you have. QUALITY OVER QUANTITY every day of the week. Remember, you need to showcase how you may actually SOLVE their problem. Show just enough.
That’s where the next phase comes up. The Presales demo. The CUSTOM demo. Based on what you hear in the Discovery and the Demo it’s time to move ahead of your competition by showing EXACTLY what you can and cannot do.
Revenue Intelligence and Intake Forms
In between the AE Demo and the Custom Demo a few things may need to happen.
Presales needs to learn more about the opportunity
Sales and Presales come together to game plan
Sales and Presales execute the game plan
Presales needs to learn more about the opportunity
After the Demo the sales teams needs to transfer the information to presales. How to do this? Here are a few options and more than likely you may use one more than one of these:
Custom fields to share information to Presales
Intake survey (can be done with a form or a screenflow in Salesforce)
Internal meeting
Some methods are more time consuming than others. Revenue Operations can perform a time study here to understand if there are opportunities to shorten the time and maximize information sharing.
Either way, the goal is to develop the technical scope and to identify what the technical success criteria should be. If the prospect agrees that is indeed the problem parameter set and what success could look like then you have true problem-impact-solution alignment.
Let’s say for example you have a business that sells commission automation software. What would you include in your technical scope? Off the top, here are some examples:
[Data Sources] What CRM software do you use?
[Data Sources] Do you calculate commissions using the data downloaded from a CRM report?
[Data Sources] Which object(s) do you pull from?
[Data Sources] Are there external data sources which you combine with this data?
[Comp Design] How many different types of comp plans do you currently manage?
[Comp Design] Do you have different tiers which you support?
[Comp Design] Do you have ramp periods built in?
[Comp Design] Do you have accelerators?
[Comp Design] How do you handle clawbacks?
[Comp Design] Do you have hold payment until certain factors are achieved?
You decide how deep you want to go. If the client is WILLING to play ball with you they’ll work with you to give this information. It molds your solution to their problem. It also shows that they’re serious. Few people are going to get this deep into specifics with you unless they have a REAL problem to solve and real INTENT to do something about it.
Technical Scoping isn’t just a one time thing
Just because you filled out the intake form, you might not have all the information necessary. The AE should work to ensure all relevant individuals from the prospect join the meeting. Otherwise you’re left with the unenviable situation of having to piecemeal the information together. Be mindful you may also be stepping into political landmines here. Your solution could be seen as a threat by certain individuals or departments. Job security is real and some people will do anything to ensure they have it.
If you have the intake form sitting in your CRM you can mine the information. Imagine the team building out a report looking for LOOKALIKE opportunities.
Do we have any past deals where we worked with a company in the Automotive industry?
Have we worked with any customers who used Zoho as their CRM?
Have we worked with any customers who used Xero as their account backend?
Without this data structured appropriately the team endlessly circulates messages in Slack. That’s a lot of capturing lightning in a bottle. The right person has to be able to see the message at the right time. It also burdens the entire organization to tag one another. “Hey Johnny, did you see this message? I think you may be able to help Cynthia on this one”. 👍 Yep, that sounds scalable to me. 🤦🏻
Optional SOWs and Required Implementation Plans
After building out the technical scope it’s time to convert the juicy tidbits into an SOW. A statement of work (SOW) and an implementation plan are both important documents for project management, but they serve different purposes.
A SOW is a formal document that describes the project goals, scope, deliverables, and requirements. It is typically used when contracting with external vendors or consultants, as it provides a clear understanding of what is expected of the vendor and what the project will deliver.
An implementation plan, on the other hand, is a more detailed document that outlines the steps involved in executing the project. It includes information such as the project schedule, resources, budget, and risks. The implementation plan is typically used by the project team to track progress and ensure that the project stays on track.
The SOW should be created before the implementation plan, as the implementation plan will be based on the information in the SOW.
The SOW should be clear, concise, and easy to understand. It should be written in a way that both the project team and the vendor can understand.
The implementation plan should be flexible enough to accommodate changes that may occur during the project.
Both the SOW and the implementation plan should be reviewed and updated as needed throughout the project.
What's the best way to ensure that a Statement of Work aligns with a customer facing Proposal?
For paid subscribers here are my additional thoughts.
Keep reading with a 7-day free trial
Subscribe to RevOps Impact Newsletter to keep reading this post and get 7 days of free access to the full post archives.