Most Salesforce enhancement tickets I’ve seen sit in a backlog for months, get bumped every sprint planning, then quietly disappear into a colder list somewhere. Not because the idea was bad. Because nobody ever wrote down what it was worth.
A ticket describes a symptom. “Case assignment is slow.” “Reps re-enter the same data three times.” “The approval process takes two days when it should take two hours.” None of that tells a product owner or a steering committee why this fix matters more than the other fifteen things competing for the same sprint. A business case does that job. It’s the difference between an idea getting funded and an idea getting forgotten in a backlog nobody re-reads.
Start with the metric, not the feature
The instinct is to describe the solution first: “we need a new Flow,” “we should build a custom LWC for this screen,” “let’s add validation rules.” Stop there and you’ve written a technical spec, not a business case. Nobody outside the Salesforce team can evaluate whether a Flow is worth building. They can evaluate whether cutting case resolution time by 20% is worth three sprints of effort.
Work backwards from a number the business already tracks, not one you invent for the pitch. Average handle time, case backlog size, order fulfilment cycle time, first-contact resolution rate, the number of manual steps in a process someone in ops complains about weekly. If leadership doesn’t already watch the metric, your business case has to do double duty: justify the fix and justify why anyone should care about the number in the first place. That’s a much harder sell.
Three questions before you write anything
- What number moves, and by roughly how much? Don’t chase false precision here. “Reduces average handle time by 60 to 90 seconds per case” is more credible than a suspiciously exact 73 seconds nobody can defend under questioning.
- Who feels the current pain, and how often? A process that annoys one admin twice a month is a different case than one that costs every service rep four extra clicks on every single case.
- What happens if this doesn’t get built? Sometimes the honest answer is “nothing much,” and that’s useful information too. It tells you to deprioritise it yourself before someone else does.
What a real business case looks like
I’ve worked with a contact-centre team where case assignment ran on a static round-robin queue, built years earlier when the team had a third of the headcount it has now. New agents got flooded with complex cases they weren’t trained for, senior agents sat idle between escalations, and average handle time had crept up for over a year with nobody able to say why. The fix, in Salesforce terms, was a skills-based Omni-Channel routing configuration with capacity weighting. Unremarkable, technically. Maybe two sprints of configuration and testing.
The business case wasn’t “let’s configure Omni-Channel routing better.” It was: current average handle time is trending up 4% quarter over quarter, misrouted cases account for an estimated 15% of escalations, and every escalation costs the team roughly double the handling time of a case routed correctly the first time. Fix the routing logic, and the model predicted a measurable drop in escalation volume within two reporting cycles. That’s a sentence a delivery lead can put in front of a steering committee without translation.
Size the cost honestly, including the boring part
Every enhancement has a cost beyond the sprint estimate: testing, user training, change management, and the risk of breaking something that currently works fine. Leaving these out doesn’t make the business case stronger. It makes it fragile, because the first person who asks “what about regression testing on the existing automation?” exposes a gap you should have owned upfront.
State the cost plainly. Two sprints of build, one sprint of testing and UAT, a half day of training for the team that uses it. If the enhancement touches a process with downstream integrations, say so and name what needs revalidating. A business case that admits its own cost is more credible than one that pretends the work is free, and it survives scrutiny from someone who’s seen enhancements blow their estimates before.
Who actually reads this, and what they’re looking for
A technical lead reading your case wants to know the approach is sound and the estimate is realistic. A product owner wants to know it fits the roadmap and doesn’t conflict with something already committed. Whoever controls budget wants one thing above all: a number they can defend to their own leadership later. Write for that last person first, because if they can’t repeat your case in their own words in a follow-up meeting, it won’t survive contact with prioritisation.
That means cutting anything that only makes sense to someone who already knows Salesforce. “Reduces flow interview steps by consolidating three screen flows into one” is an implementation detail. “Cuts the time to process a standard order from four minutes to under ninety seconds” is a business case. Keep both versions if you need them, the technical detail for your own team, the outcome for everyone else, but don’t hand the wrong one to the wrong audience.
The case that never got approved, and why
I’ve also seen the other version: a well-built enhancement, genuinely useful, that never got funded because the request arrived as a two-line ticket asking for “improved data quality on the Account object.” True, probably, and completely unactionable for anyone deciding where to spend the next quarter’s capacity. Nobody could say what “improved” meant, what it currently cost the business to not have it, or what would change if it shipped. It sat in the backlog for over a year before someone finally reframed it around duplicate account records causing incorrect territory assignment, at which point it got approved in the next planning cycle without much debate.
Same technical work, same team, same effort estimate. The only thing that changed was whether anyone reading the request could tell what it was worth.
Write it short
A business case for a Salesforce enhancement doesn’t need to be long. Half a page is usually enough: the metric, the current cost of not fixing it, the proposed change, the estimate including the boring parts, and what success looks like in numbers someone can check later. Anything longer starts competing with the reader’s patience instead of their attention.
Log the ticket if you want a record. But if you want the enhancement built, write the case first. The ticket describes what’s broken. The business case is what gets someone to spend their limited capacity fixing it instead of the fifteen other things asking for the same slot.