The fastest Q2C implementations I’ve been part of had something counterintuitive in common: they spent the first four to six weeks not touching a single system.
That time went into process design. Mapping how a quote should actually move through the organization. Defining what a contract needed to say. Deciding when billing should trigger and what revenue recognition should look like. Getting every function aligned on the answer before anyone opened a configuration screen.
The slowest implementations did the opposite. They started configuring immediately, made assumptions that turned out to be wrong, and spent months undoing decisions that should have taken days to make correctly in the first place.
Process design isn’t a delay. It’s the investment that makes everything else faster.
Why Teams Skip It
The pressure to start building is real. You’ve signed a contract with an SI. Executive leadership is watching. The board wants to see progress. “We’re in design” doesn’t feel like progress. “We’re building” does.
But there’s a difference between visible activity and productive activity. Configuration that’s built on unvalidated assumptions isn’t progress. It’s debt. You’ll pay it back later, with interest, in the form of rework, re-scoping, and the particularly painful process of convincing an implementation team to undo work they’re proud of.
The other reason teams skip process design is that it requires decisions that are uncomfortable to make. Who has approval authority over a $500K deal? What’s the company’s standard payment term? When does a customer-requested contract change require legal review versus just a sales manager sign-off? These questions have political dimensions. People avoid them because answering them means committing to a position.
That’s exactly why they need to be answered before configuration, not during it.
The Five Design Questions That Drive Everything
1. What is the lifecycle of a quote?
Map every stage a quote goes through, from creation to execution. How does a rep initiate a quote? What information is required to create one? What happens when a customer requests changes? How many rounds of revision are typical? When does a quote expire? What triggers conversion from quote to order?
This seems basic. In practice, most organizations have never formally mapped this. Different sales teams handle it differently. Edge cases are handled ad hoc. The implementation is your opportunity to standardize, but you can only standardize if you’ve defined what the standard should be.
2. Who approves what, under what conditions?
Approval workflows are the most contentious part of CPQ design because they touch organizational hierarchy, risk tolerance, and political dynamics. Every function has opinions. Finance wants approval on any discount over 10%. Legal wants to review non-standard terms. Executives want visibility on large deals. Sales wants to close quickly.
The right approval design balances control with velocity. You need enough oversight to manage risk without creating a process so slow that sales routes around it. Map your approval matrix explicitly: deal size thresholds, discount authorization levels, non-standard term triggers, customer type considerations. Get this signed off before configuration. An approval workflow that’s revised mid-implementation is one of the most expensive changes you can make.
3. What variations exist in your contracts?
Pull ten recent contracts and read them. Then pull ten more from a different segment or region. Note every place they differ: payment terms, warranty provisions, service level commitments, renewal conditions, limitation of liability caps, termination rights.
Every variation represents a configuration decision. Some variations are legitimate and should be supported. Others are negotiated exceptions that should require a formal approval process. And some are mistakes, inconsistencies that crept in because nobody was governing contract language.
Your Revenue Cloud implementation can enforce contract consistency in a way that manual processes can’t. But first you have to decide what consistency looks like. That decision has to come from legal, finance, and sales leadership jointly, and it has to happen before contracts are templated in the system.
4. What triggers billing, and what governs invoice timing?
Billing is where Q2C implementations most often surprise clients. The question seems simple: when does billing start? In practice, it’s multi-dimensional. Does billing start on contract execution date, or on go-live date? What if implementation takes longer than expected, does the customer pay during implementation? How are mid-contract changes handled: prorated, effective next billing cycle, or renegotiated? What happens when a customer is late paying, does interest accrue automatically?
Map your billing triggers for each product type and contract structure you sell. Then align with finance on how these billing events connect to invoice generation. Then align with the implementation team on how Revenue Cloud needs to be configured to produce those results. This is a three-way conversation that needs to happen before billing is configured, not after the first invoice runs incorrectly.
5. How does revenue recognition connect to your contract structure?
Revenue recognition under ASC 606 is not a finance problem that happens after the deal closes. It’s a design constraint that shapes how you structure quotes, contracts, and billing from the beginning.
The key question is: when does each element of your deal satisfy its performance obligation? A software license delivered on day one recognizes revenue on day one. A support contract recognizes revenue ratably over the contract term. Implementation services recognize revenue as work is completed. A bundled deal with all three requires you to allocate transaction price across each performance obligation and recognize each independently.
If your CPQ bundles these as a single line item, your finance team can’t recognize revenue correctly. The solution is to design your product structure and contract architecture with revenue recognition in mind, which means finance needs to be in the design conversation from the start, not consulted after configuration is complete.
What Good Design Produces
When you do this process design work well, the output is a set of documented, stakeholder-approved process flows that the implementation team uses as their blueprint. Configuration decisions become straightforward because the business decisions have already been made. Edge cases get handled consistently because the rules are explicit. Approval workflows launch correctly because the matrix was designed before the system was built.
More importantly, your go-live is cleaner. Your users understand the system because it reflects a process they were involved in designing. Finance trusts the numbers because they understand where they come from. Operations fulfills orders correctly because the flow was designed with their constraints in mind.
The implementations that skip this work launch into chaos, not catastrophic failure, but the slow-burn chaos of constant exceptions, manual interventions, and the creeping realization that the system isn’t quite working the way anyone expected.
Four to six weeks of process design before configuration is not a delay. It’s how you deliver an implementation that actually works.
I work on Revenue Cloud and Q2C implementations at Slalom. Connect with me on LinkedIn if you want to talk about running a process design sprint before your implementation.