Where Revenue Cloud implementations go wrong

A quote that took two minutes in the old system now takes eleven, and the ticket says the platform is slow. It is not slow. It is being asked to evaluate several hundred price rules against a bundle nested three levels deep, every time somebody changes a quantity. The symptom is performance. The cause is a modelling decision taken in week three, and no amount of tuning will reach it.

That gap is what makes quote-to-cash rescues hard. Quote-to-cash is one long chain, and a chain reports its failures at the end. Nobody rings to say the catalogue is too deep. They ring to say quoting is slow, approvals are stuck, the invoice is wrong, or the date has moved again. Each of those is a late-stage description of an early-stage problem, and a team that takes the description at face value spends a quarter optimising the wrong thing.

This is the diagnostic companion to Revenue Cloud: the decisions that set the shape of everything after. That piece is for programmes that have not started, and it argues about the decisions taken before build. This one is for programmes already underway, where the build exists, something is visibly wrong, and the decisions in question were made months ago by people who have since rolled off.

#Read the symptom back to its stage

The third column is deliberately small. Each entry is a move that confirms or eliminates a cause inside a day, not a remediation plan, because the expensive error in a struggling programme is committing a quarter to a confident wrong diagnosis.

#Quotes take too long

The symptom. Reps say the system is slow. Configuration screens take seconds to respond to a quantity change. The complaint usually arrives two or three weeks after go-live, once real deals rather than test data are going through, and it arrives as a performance ticket with a stopwatch attached.

Where the cause lives. Two places, both in the model rather than the infrastructure. The first is bundle depth. Every level of nesting multiplies the records sitting behind each line a rep can see, so a quote that looks like a dozen lines on screen can be carrying several hundred underneath. The second is rule count. Rules written to reproduce individual deals accumulate quietly, each one defensible on the day it was added, and every one of them evaluates on every relevant change.

The useful tell is whether the slowness scales. If a two-line quote is also slow, look at integrations, callouts or something synchronous firing on save. If a small quote is fine and a full bundle is not, the cause is how much model the system is being asked to evaluate, and no amount of tuning reaches that.

First move. Take one slow quote and count what it actually produces, not what the rep can see, then count the rules that evaluate against it. Show both numbers to the people who designed the catalogue. In our experience the numbers surprise them, and that surprise is the finding: the depth was added for clarity, and nobody ever added up what it cost.

Watch for the workaround while you are there. When quoting is slow, reps build a private library of cloned quotes and edit them, which suppresses the complaint while quietly guaranteeing that stale pricing goes out for the rest of the year.

#Approvals stall

The symptom. Cycle time went up after go-live rather than down. Deals sit for days. Ask how many approvals were rejected last quarter and the answer is close to none.

Where the cause lives. In the approval design, and specifically in a matrix modelled on the org chart rather than on genuine authority. Levels accumulate the way rules do. Somebody senior asked to be included once, for one deal type, and the level stayed. An implementation is often the moment those levels get transcribed rather than examined, because transcribing is faster and nobody wants the other conversation.

A level that has never rejected or materially changed a deal is not a control. It is delay with a notification attached, and it carries a second cost: approvers who are never asked to think stop reading, so the one deal that genuinely needed scrutiny gets the same reflex approval as the ninety before it.

First move. Pull the last twelve months of approval history, including the period before go-live, and count per level how often each one rejected or changed something. Take that table to the sponsor. It is the only version of this conversation that succeeds, because it replaces an opinion about seniority with a count.

#Amendments produce the wrong numbers

The symptom. A customer adds seats mid-term and the amendment quote shows a figure nobody expected. Finance queries the invoice. Somebody opens the original contract and everyone in the room reads it differently.

Where the cause lives. In amendment policy that was assumed rather than specified. Proration, co-terming and renewal inheritance are commercial decisions, and they are the ones most often left out of a requirements document because everybody believes they already know the answer. Sales assumes the original discount carries. Finance assumes proration runs by day. Delivery assumes added quantity co-terminates. The build encodes one assumption, silently, and nobody notices until a real mid-term change is quoted against a real contract.

First move. Pull three real amendments from the last year, the awkward ones rather than the clean ones, and quote them end to end. Compare each line against what the contract says should have happened. The differences are your specification gap, itemised, and they are the agenda for the session that closes it.

If the numbers go wrong only on contracts that came across from a previous platform, the cause sits in migrated data rather than in policy. That is a different problem with a different fix, and it is covered in the migration itself: sequencing a move off CPQ.

#Finance cannot reconcile

The symptom. The first month-end after go-live takes days longer than the last one before it. A spreadsheet appears, somebody owns it, and within two cycles it is load-bearing.

Where the cause lives. Almost always in requirements that were never gathered. Quoting was scoped with sales in the room and finance on the distribution list. Nobody worked backwards from a real invoice or a real revenue report to ask what quote lines would have had to exist for either to be produced without a human intervening.

The specifics that go missing are consistent: which identifier ties a booking to an invoice to recognised revenue, what billing schedule shapes are genuinely in use, which tax treatments vary by product or geography, and what counts as bookings as against expansion. Revenue Cloud Billing does its part cleanly or otherwise depending almost entirely on the shape of the data arriving from the quote, which is why a billing symptom so often has a catalogue cause.

First move. Take one real invoice and one real revenue report, and trace each backwards to the quote lines that should have produced them. Where the trace breaks is the gap. Do this before agreeing to any billing configuration work, because configuration cannot compensate for a line that was never modelled.

Definitions matter as much as data here. If bookings and annual contract value mean different things to two teams, the reconciliation never closes, and the same ambiguity poisons the forecast built on top of it, which is the argument in opportunity stages that mean something in a forecast.

#The catalogue nobody will change

The symptom. A pricing change that ought to take an hour is quoted in weeks. Change requests are refused, or accepted and then quietly not delivered. Ask why and you get a version of: we are not sure what else it touches.

Where the cause lives. In undocumented exceptions and the absence of a named owner. The catalogue accumulated rules written to unblock individual deals, none with a stated commercial policy behind it and none with a name against it. Nobody can predict the blast radius of a change, so refusing becomes the rational response, and the catalogue stops being maintainable while still looking healthy on every report.

This is the failure that ages worst. Every month it persists, the organisation prices new business through a structure it has decided it cannot touch, and the workarounds migrate into manual quoting where nobody can see them at all.

First move. Ask in writing who owns the catalogue. If establishing the answer takes more than a day, that is the finding. Then inventory the rules: for each one, the policy it implements and the person who asked for it. Rules where neither answer exists are removal candidates, and the count of them tells you how far the drift has gone.

#The project that cannot get out of UAT

The symptom. The defect count is not falling. Fixes go in, retests pass, and new defects arrive at the same rate. Every fortnight the date moves by a fortnight.

Where the cause lives. In commercial decisions being discovered as defects. A tester writes that the discount on a renewal is wrong. That is not a defect, because nothing ever specified what a renewal should inherit. It enters the log anyway, gets assigned to a developer, who picks a plausible answer and ships it. The next tester disagrees and raises another. The loop cannot converge, because a defect log has no mechanism for deciding policy and keeps being asked to.

The tell is in the language. Read the log and count how many items say the system does not do what was specified, and how many say the system does something the reader does not agree with. A programme where the second group is large is not behind on defects. It is behind on decisions, and it is trying to close them one ticket at a time.

First move. Re-read the log and split it in two, with the business analyst and one commercial stakeholder in the room, item by item, in an afternoon. Everything landing in the second column stops being development work immediately, which on its own usually restores a delivery rate the team had stopped believing in.

#Recovery starts by separating decisions from defects

The most common reason a struggling quote-to-cash programme stays struggling is that it tries to fix commercial problems with technical work. A decision routed to a developer becomes a guess. A defect routed to a steering group becomes a delay. Both feel like progress and neither is, which is how these programmes look busy for months without moving.

So split the backlog before working it. One column holds genuine defects, where the system does not do what was specified, and the delivery team owns those outright. The other holds questions nobody has answered: what a renewal inherits, how proration runs, who must genuinely approve, what finance needs to see. That column needs a forum with the authority to decide and a date by which it will, and its outputs get written down as policy rather than closed as tickets.

Then work them in that order. Decisions first, because a defect fixed against an undecided policy is a defect you will fix twice. Revenue Lifecycle Management will express whatever commercial model it is given, faithfully and for years, which is exactly why the model has to be agreed by people rather than inferred by whoever is holding the ticket.

The programmes we have seen recover are not the ones that fixed the most. They stopped fixing for a fortnight, worked out which of their problems were decisions rather than defects, took those decisions properly, and then found the remaining list was a fraction of the one they had been carrying.