By Kristin Hubbard, Managing Consultant, VFP Consulting + Salesforce MVP 2023-2025
Most quote-to-cash overhauls don’t fail because the software can’t do the job. They stall because teams skip decisions, defer them, or make them in the wrong order.
Quote-to-cash touches everything that turns a signed deal into recognized revenue: product catalog, pricing, quoting, contracts, delivery billing, collections, and revenue recognition. Every one of those areas has an owner, a legacy process, and years of exceptions baked into it. When a program goes sideways, it’s rarely one big mistake. It’s a handful of small “we’ll figure that out later” moments that all come due at the same time, usually right before go-live.
What follows is a list of the things I’d tell any finance, operations, or sales leader not to do, drawn from what I’ve seen in the field leading large Salesforce and Certinia quote-to-cash programs. None of it is theoretical.
Before you start
Don’t treat the product catalog as a cleanup task for later
Your product catalog is the foundation for quoting, billing, and revenue. If it isn’t rationalized before design starts, every downstream process inherits the mess. I’ve watched teams discover late in the program that a meaningful share of legacy contracts didn’t map to the new catalog at all. At that point, the options are all bad: re-paper client contracts, or route unmapped items into a catch-all product and give up reporting precision.
Decide what you sell, how it’s priced, and how each product type is recognized (services against delivery, subscriptions against billing schedules) before anyone builds a quote template.
Don’t leave pricing logic living in spreadsheets
If your sellers calculate prices in an offline spreadsheet and then type the result into the quoting tool, you’ve built in overrides on day one. Overrides trigger approvals nobody needs, distort margin reporting, and make the system’s list prices meaningless. Either bring the pricing logic into the platform or make an explicit, documented decision about how the interim state will work.
What happened when the agent took on the build?
Quick Answer: It finished 44 requirements in 4.5 hours. The same work was budgeted at 24 to 59 builder-hours, which means roughly 82% of budgeted build hours came off the table. And it got 97.7% of the contracted components right on the first pass.
The numbers are good, but what surprised us was where the time went back. Our consultants didn’t disappear from the project. They spent it reviewing output, pressure-testing the design, and talking with the client about what actually matters to their business.
Don’t leave scope to interpretation
Write down what’s out, not just what’s in. Who owns data extraction, mapping, cleansing, and reconciliation? Which testing events cover sales processes and integrations, and which don’t? Who sets up users for testing? Every one of those questions will be asked again mid-program, usually under pressure. A line in the statement of work saves a week of debate.
Also expect “out of scope” items to come back. Reporting requirements that sat on the shelf for a year and a half can suddenly become must-haves. A clean scope record lets you treat that as a change, not a surprise.
Don’t underestimate your systems inventory
Quote-to-cash platforms sit in the middle of your tech stack. Customer-facing apps, ERP, HR systems, and reporting tools all read from or write to them. Moving to a new org or tenant means new record IDs, which can quietly break integrations that nobody listed. Inventory every connector and field dependency up front, and name an owner for each.
Don’t kick off without a governance process
Governance answers one question before it gets asked under pressure: who decides, and how fast? Without it, design questions bounce between teams, escalations go to whoever is loudest, and leaders hear about problems only once they’re already on the critical path.
Set it up before kickoff. Define decision rights for each area (pricing, contracts, billing, revenue), so everyone knows which calls belong to a process owner, which go to a business unit leader, and which go to the steering committee. Put a regular cadence in place: weekly working sessions, a recurring steering committee, and a clear path for urgent escalations between meetings. Agree on how decisions get recorded, how issues get closed, and what readiness evidence leadership will expect at each milestone. A steering committee that sees the same scorecard every time will spot trouble months earlier than one that gets a slide deck rebuilt from scratch each meeting.
Don’t rely on your partner’s project manager to run your side
Your consulting partner will bring a project manager, and so will any other vendor. Their job is to deliver their scope. They can’t chase your process owners for decisions, clear your internal calendars, or hold your business units to their deadlines, and they shouldn’t be expected to.
Name a client-side project manager before kickoff. That person owns your internal plan: securing SME time, driving decisions through governance, tracking client-owned work like data cleansing and user setup, and coordinating across every partner. When the partner’s PM ends up filling that role by default, accountability gets blurry, client tasks slip without anyone noticing, and the partner becomes the easy explanation for delays it doesn’t control.
During design and build
Don’t let decisions live in Teams, Slack, and email
On a large program, decisions get made in hallway conversations, chat threads, and meeting side notes. If they don’t land in a single system of record, three teams will have three versions of the truth. Payment terms and proration rules are classic examples. Capture every decision against the requirement it affects, with a date and an owner.
Watch the vocabulary too. When documents use three different names for the same role, or a draft field name looks like a built one, people spend hours chasing gaps that don’t exist.
Don’t skip change control because “it’s just one more thing”
New requirements will keep arriving, especially once business users start seeing the system. Without a formal change-control process, each one gets absorbed informally, and the timeline erodes one reasonable request at a time. Put the process in place at kickoff, not after the go-live date is already at risk.
Don’t let operating model questions wait until Testing
A new quote-to-cash platform often brings a new way of working: centralized resource requests, standardized project management, new approval routing. If business units first learn how that model applies to them during user acceptance testing, Testing turns into a design debate. Walk each business unit through the future-state operating model and get their questions answered, well before testing starts.
Don’t manage risks and issues informally
A risk that gets discussed in a status meeting but never logged is invisible to every dashboard and escalation path. A parking lot with priority tags but no owners and no target dates isn’t a plan; it’s a list. Every open item needs a named owner, a due date, and a clear call on whether it must be resolved before go-live.
Testing, data, and go-live
Don’t start data cleansing late, or assume the pace
Data migration is the most underestimated workstream in quote-to-cash. Legacy contracts have to be mapped to new products, open orders reconciled, and billing and revenue history moved without breaking anything. Cleansing is manual and judgment-heavy, and it competes for the same subject-matter experts who are also testing. Measure actual daily throughput early and compare it to what the plan requires. If the gap is large, add people or automation now, not in the last month.
And test migrated data through the real quote-to-cash processes before it goes to business owners for sign-off. Data that loads cleanly can still fail the first time someone tries to amend or invoice it.
Don’t mix questions with defects
When users log everything as a defect, the backlog becomes impossible to read. Separate true defects from questions, enhancements, and exploratory findings, and publish answers clearly. Answered questions often surface new defects, so close the loop rather than just closing the ticket.
Don’t give the same people two full-time jobs
Business process owners can’t realistically finish retesting and write the policies, playbooks, and training content on the same deadline. Split the work: delegates and subject-matter experts handle retesting, and process owners focus on documentation. Training and communications depend on those documents being final, so they’re on the critical path.
Don’t accept sign-offs you don’t believe
Pressure to hit a date produces sign-offs that mean “we ran out of time,” not “this works.” Ask each team to report what it can genuinely approve today and a real date for the rest. That’s the only way leadership gets an honest readiness picture. Don’t accept silence as agreement, either.
Don’t hold a go-live date the data doesn’t support
If data readiness and system readiness are both red, the date is a wish. Moving go-live is painful, but it’s far less painful than launching on dirty data and spending hypercare fixing invoices in front of your customers. Make readiness criteria explicit early, track them weekly, and let them drive the decision.
Structuring the team
The technology rarely decides whether a quote-to-cash program succeeds. The people around it do. A few structural mistakes show up again and again.
Don’t run the program without one owner and one plan
When the client team, the consulting partner, a second vendor, and a data migration firm each run their own plan, gaps open between them, and blame fills the gaps. Name one program manager who owns a single integrated plan across every workstream, and give them the authority to hold every party to it. Pair that with a steering committee of executive sponsors who make the calls the program team can’t.
Don’t let critical knowledge sit with one person
If one leader holds the testing approach, the scenario logic, and the stakeholder relationships, the program is one resignation away from a stall. Build a bench behind every critical role: a named backup, shared documentation, and decisions recorded where others can find them. When a key person leaves mid-testing, the team that can keep going without losing weeks is the one that planned for it.
Don’t put business process owners on the program part-time and unbacked
Process owners are the most important people on the client side. They validate data, approve designs, sign off on testing, and write the playbooks that drive training. They also still have day jobs. If nobody backfills their regular work, they’ll fall behind on all of it at once. Budget for backfill or delegates before kickoff, not when the schedule slips.
Don’t cut program roles to save money before go-live
Cost pressure is real, but releasing program leaders or specialists late in the program trades a small saving for a large risk. The knowledge walks out the door right when cutover needs it most. If roles must be reduced, plan the handoff deliberately and keep core roles through hypercare.
Don’t let business unit leaders sit on the sidelines
When business unit leaders aren’t engaged early, they show up late, often in testing, ready to challenge the design. Give them a defined role from the start: review the future-state model, own their issues list, and formally close resolved items. A short pulse survey after each steering meeting is a simple way to surface concerns before they turn into resistance.
Don’t blur the lines between partners
Multi-vendor programs need a clear responsibility matrix: who builds what, who fixes which defects, who owns each integration and each data object. Tagging defects by responsible team speeds triage and takes the heat out of “whose problem is this” conversations. Ambiguity between partners is where trust breaks down first.
Don’t treat leadership changes as a footnote
New executives, reorganizations, and departures change priorities, often without anyone saying so. When leadership shifts, reconfirm sponsorship, scope, and the go-live criteria right away. A sponsor who steps up and resets how the work is run can steady a program; one who isn’t re-engaged lets it drift.
The short version
Every item on this list comes back to the same idea: the decisions you defer don’t go away; they get more expensive. Before you kick off your next quote-to-cash overhaul, make sure you can answer yes to these:
- Is the product catalog rationalized, and does every legacy contract map to it?
- Does pricing logic live in the platform, or is there a documented interim plan?
- Does the statement of work say who owns data migration and what each testing event excludes?
- Is every integration and its owner on a list?
- Are amendments, renewals, and terminations designed and tested as their own workstream?
- Is there one system of record for decisions, and a change-control process from day one?
- Has each business unit seen the future-state operating model before testing?
- Is data cleansing throughput measured against what the plan requires?
- Are go-live readiness criteria written down, and will they actually drive the date?
Get those right, and the software will do what it was bought to do.
