/* CSS to modify the options in the menu when the user clicks on them */
/* CSS to disable the scroll when the menu is open */
Ah, the building blocks of RevOps. While they don’t always make for the most exciting projects, it’s what ultimately allows us to do the interesting stuff. Of course, we get excited to do the big innovative projects (see Intercom’s automated expansions), but before you can do those, there are some early foundational things to be mindful of.
💡 We think of Revenue Architecture as the core building blocks of our systems. We spend a lot of time thinking not only about the tools we implement, but also the data model, integrations, order of operations, and permissions.
The first principles of a great opportunity infrastructure are:
Here is the most common design for record types in SaaS with sample stages:
✱ At a minimum, your stages should reflect:
✱ Limit the number of record types – ideally, each record type should represent a distinct sales process with its own stages and requirements. As mentioned above, these are typically aligned to New Sale, Renewal, and Expansion.
✱ Clearly define exit criteria for each of your sales stages, and ensure your sales team is enabled on this criteria.
✱ Leverage Sales Paths and the Guidance to Success section to highlight the criteria or other useful information.
You will not regret spending time to design a clean product table.
To ensure a comprehensive view in your system, you will need to add the products themselves, as well as fields to accurately describe them. Having a clear definition of what properties reside in each of the product objects is key to a scalable org.
We usually recommend sticking to the following when it comes to the Product and Opportunity Product objects:
✱ Product: should contain fields related to the product’s intrinsic characteristics, and these should be applicable independently of who you are selling them to. Some examples of fields you might want to create in this object:
✱ Opportunity Product: fields indicating how the product is adjusted to a specific client should live under this object. Some common examples of fields in this object:
Note: You might want to consider having some of the Product fields copied to the Opportunity Product. This allows your team to edit some of the characteristics of the product if needed.
Once you feel solid in the architecture you’ve built, you’ll have the foundations to do the fun stuff like: