Mistakes of our Past

Starting out with DealHub? Avoid these 10 mistakes even seasoned experts make. Here is the list we compiled while completing 80+ DealHub projects.

Our 10 Mistakes fit into the following 3 themes:

Theme 1: Don’t miss the easy wins
Theme 2: Avoid unnecessary complexity.
Theme 3: Don’t neglect administrative fundamentals.

We made these mistakes when DealHub was new to us. Our systems were difficult to maintain. Simple fixes were unpredictable and had consequences in other areas of the build. We struggled to add new features, products, and document changes. These issues led to quoting delays and errors.

We saw users and buyers alike get frustrated and look for ways to work around the system reducing the return on CPQ investments.

10 Mistakes - the List

Don’t Miss the Easy Wins

Because DealHub makes it so easy to dive in and start building a Playbook, adding products, and setting pricing rules, it’s tempting to just get started. Thinking through a few outcomes and tactics at the beginning makes the whole build faster, easier, and more coherent.

Below, we highlight a few helpful steps that are easy to miss if you’re new to DealHub.

Mistake 1: Starting with the Playbook

Start with the Output Documents, not the Playbook.

Starting your build in the Playbook leads to a chaotic and fragile build with unnecessary features, complicated logic and random interfaces to products, assignment rules and pricing rules. It’s like writing a story without an outline. You can do it, but it won’t be easy.

We have a rallying cry for new builds at Thriviti: “Race to the document.” This means we start by understanding the outputs before we build..

Until you know what the document looks like, what’s included, and how it varies from quote-to-quote, you don’t really know what to build. The document is the outline of your build. It tells you what elements need to be created for a successful build.

DealHub provides powerful and flexible pricing tables. Get your products into those pricing tables early in the build process. This will help you see the power of a simple, straightforward build. Simple builds are the most powerful, scalable, maintainable and changeable builds.

Mistake 2: Failing to Use Product Counters

Count the products you quote.

Counters will give you an easy way to select content elements in the Output Documents based on what products are quoted. 

Include counters in every build. We use a combination of a proposal attribute on each product and document parameters to make decisions in the Output Documents.

Using counters has two advantages: 

1. Flexibility: You can combine counters with other proposal attributes to count products, products from families, or products with other attributes. Example: “Show this text if the quote contains a hardware item.”
2. Resilience: There are other ways besides using the Playbook to add products to the Product Summary. The counter will catch what’s added to the Product Summary regardless of how it was added, so you don’t accidentally miss one and inadvertently leave out an important clause.

We recommend that you add a counter product attribute with a default value of “1” or use the item quantity and then configure the document parameters as you determine how you will use the counter.

Mistake 3: Failing to Plan Your Tags

Get familiar with tags, what they are good for, what they are not good for, and plan accordingly.

Tags have two primary uses:

1. Discounting and Pricing - You can apply specific workflows or logic to tagged products (e.g., services vs. hardware). Tags can opt products into or out of discounts, promotions, geo-specific factors, or partner-specific pricing rules.
2. Output organization - Tags can be used to group and filter products in output tables.

You will find uses, but when planning your tags, we recommend you get clear about their primary uses and get them working before using them for anything else.

Plan your tags early to avoid rework later. Replacing tags throughout a build can be time consuming.

Avoid Unnecessary Complexity

Focus on what you need the system to do, not everything it can do. DealHub’s flexibility is powerful, but it can be overwhelming. Stay focused on the essential functions of your new CPQ system until your users are successfully quoting.

Mistake 4: Building Multiple Playbooks, Documents and DealRooms

Plan for a single Playbook, Document and DealRoom.

Playbooks
We see many implementations with multiple Playbooks, usually because we are asked to consolidate them into a single Playbook. Of the three mistakes covered here, creating multiple Playbooks is the worst.

Complicated Maintenance: Multiple Playbooks makes changes harder and more time consuming. Errors need to be corrected in multiple Playbooks. Here are other tasks that you may need to repeat: updating picklist values, the order of questions, the wording of questions, new or edited question tips, formulas, conditional answers, new question groups and more.

Duplicated Products and Rules: Multiple Playbooks multiply the product catalog. Each Playbook needs its own set of products and therefore, assignment and pricing rules, even if they are identical for each Playbook. Now, if you need to update a product, you repeat the update for that product associated with each Playbook. When you add a product, you have to add it for each Playbook. In addition to being time consuming, it adds significant cognitive load to what should be a simple change. Did I update it for the Main Playbook? Did I forget the product update for the Inside Sales Playbook? What about the Partner Playbook?

Output Documents
Keeping multiple Documents and DealRooms aligned is a little easier thanks to shared elements, but even then, they get out of sync. It is so easy to update one document and neglect the others. It also makes finding errors more difficult because the offending error might be found in only one document of many.

Design single instances of these fundamental elements and make  the environment easier to manage.

Instead,  use conditional logic based on the user’s role, a custom question, the products included in the quote (see Mistake 2), and more, to change what is presented in the Output Documents. Thoughtful planning can drive tailored quoter and buy experience without the need for multiple documents.

Mistake 5: Overautomating

Start simple and keep it as simple as you can.

Avoid the temptation to automate everything. It looks easy in DealHub, because it is. But living with overautomation is fraught with frustration and expense.

Just because a thing can be automated, doesn’t mean it should be.

Pro-Tip: Let users do what they are good at and let the machine do what it is good at. You can build a series of formulas to totally customize the construction of a paragraph in the Document, but you probably shouldn’t. 

Here’s why:

Fragile: Overautomated builds are fragile, meaning they break under changing conditions or minor adjustments. The Playbook should always work, even when you add new products. If your Playbook has to change because you added a new product, you may have over-automated.

Complex:  Overautomated builds are difficult to manage. Sophisticated automations  involve several questions and question groups. An error or change may cascade across a dozen questions involving multiple question groups and require dozens of changes to support the initial change.

Rigid: Overautomated builds are restrictive and frustrating to users, causing quoting delays. Some builders try to enforce every policy through programmed guardrails. When allowable exceptions arise the automations make it impossible to produce the desired quote or output without significant changes.

When allowable exceptions occur, the quoter has two bad options in a fragile, complex and rigid build:

1. Quote outside the system.
2. Wait for the Playbook to be changed to allow the exception.

Instead, we recommend  an “allow and approve or reject” approach that triggers an approval workflow for discounts beyond a certain percentage, uncommon product pairings, or custom language inclusion.

Don’t hardcode constraints that may need to change later when an approval workflow will do.

It is possible to safely build a highly automated CPQ system in DealHub. The more automation you build, the more you have to treat this like a software project, rather than a configuration project and manage its lifecycle accordingly.

Mistake 6: Building a Distracting DealRoom

Make it easy for your buyer to sign.

Don’t do anything in the DealRoom to distract your client from signing.

Consider your purpose for having a DealRoom. As a custom web page, a DealRoom can have any purpose a web page can have. Our suggestion for a constructive purpose is the: The DealRoom exists to promote the quote and facilitate a fast, easy signature.

A properly configured DealRoom does three things well:

• It focuses the buyer on signing the agreement.
• It makes sharing and communicating about the agreement easier.
• It gives the Sales Rep insight into who accesses the DealRoom and what actions they take.

Your team will never want to email a document for signature again.

Too many elements: You may want to include a confidence-building testimonial, a brief explainer, a list of advantages, a logo scroller, a message from the Sales Rep, a message from the CEO, or something else.

Less is more. Do something, but don’t do everything. Your DealRoom can’t close the deal for you, but it can cause your prospect to pause. We recommend that you pick an essential element from this list or something unique to your offer and keep it free of distractions and links outside of the DealRoom.

Pro-Tip: The DealRoom should look like your brand, include very few elements, and feature the signature block prominently.

Mistake 7: Over-using Numeric List and Numeric Range

Avoid the Numeric List and Numeric Range question types. Use Numeric, instead.

We built many Playbooks with Numeric Lists and Ranges. Both question types have the same drawback. You need to know the range or the specific list of possible answers in advance. When the list is missing something you need, you need to adjust the range or add to the list. If you have other questions dependent on those answers, you may need to adjust the downstream answers. It is a time consuming hassle that you can avoid by simply using a numeric question type.

Numeric Range looks cool in a demo. In practice, it slows users down and, especially when you have several of them, it is frustrating to use.

In all but a few cases, we have swapped out our Numeric Ranges and Lists for numeric answers. Remember that you can control the step and range of a Numeric answer, too.

Don’t Neglect Administrative Fundamentals

Make the most of DealHub’s built-in version management to keep track of your progress and keep your motor clean.

Mistake 8: Infrequent Versioning

Version frequently. Don’t solve multiple problems in a single version.

Build something. Test it. When it works, version up before building anything else. When in doubt, version up.

DealHub allows you to iterate your build through a process called versioning. The version contains all the settings and elements that exist outside System Settings and User Management. Basically, the version contains all the structure that makes your CPQ system your system: the Playbook, the Products, the Output Documents, the Workflows and more.

Versioning frequently allows you to perform mini-experiments with simple, testable solutions. When you make dozens of changes in a single version, testing can become unwieldy. If test outcomes are unpredictable, it can be difficult to determine which change caused the problem.

Save yourself time and hassle by versioning frequently after small changes. Versions are free.

Mistake 9: Not Including Version Comments

Comment your versions.

Speed up troubleshooting: Meaningful version comments help you pinpoint when changes were made.  This is especially helpful when a change causes problems that show up several versions later. With good comments, you can find the first relevant instance of the change and follow the progress through versions.

Frequent versioning and good comments go great together!

Mistake 10: Allowing Garbage to Accumulate

Don’t allow old ideas, abandoned content, and unused elements to accumulate in your active versions.

Not everything you try will work. When you try something that doesn’t make the cut, get rid of it.

Before you do, make sure you version up so that feature is stored in your system. You may find reason to refer to the attempt in the future. Follow the advice from steps 8 and 9 above. Duplicate the version. Add a note like “Failed attempt to auto-calculate the end date” on the version that will retain the attempt, and remove anything in the new version that is no longer needed.

Keeping  your environment free of non-functional elements and content will make troubleshooting faster and easier and save you and your team lots of frustration.

A Brighter Future

Avoiding these mistakes will make building, managing and changing your new CPQ system faster and easier. It can also help you create a better, more flexible user experience.

Our recommendations for a better CPQ experience:

Begin with the end in mind. Start with the signable quote, proposal, or agreement you need to produce. Serve that purpose first. Make a plan that includes counters and how you will use tags.

Keep it simple. Prioritize the essential functions to get the right data in the right place. Create a parking lot for all non-essential features. Be ruthless. Focus on a build that features one Playbook, and one set of Output Documents. Resist overautomation, focus the DealRoom on the task of signing and avoid restrictive question types.

Mind the fundamentals. Don’t let the simplicity of the system make you overconfident. DealHub is like poker. It’s easy to learn the rules, but it takes time to master. Make the journey easier on yourself by practicing good fundamentals like frequent versions, good comments and garbage collection.

Avoid these costly mistakes and let us know how it goes or share your questions with us!