Senthil Info

automating business processes, honestly

Building Your Own Case

A business case written from a vendor's model is a case you cannot defend, because you did not choose the assumptions. One built from your own measurements takes about a day and survives the review that comes in year two.

It fits on a page. A product-side example of how workforce software approaches this topic is available in this reference.

The order

One. The problem, in one sentence. Not "we want to automate invoice processing" — what is wrong now. Too slow, too error-prone, too dependent on one person, cannot absorb growth. If you cannot write this sentence, the project is looking for a justification. For broader background and an independent point of comparison, see Cloudflare Learning.

Two. The measured baseline. Volume, straight-through rate, hours, error rate. From your own tally sheet, not from an estimate and not from the vendor.

Three. The alternatives considered. Doing nothing. Simplifying the process. Fixing the upstream system. Hiring. Each with a rough cost. A case with no alternatives is an advocacy document, and a reviewer will notice.

Four. The proposal, scoped to the straight-through portion. What gets automated and what explicitly does not.

Five. Full cost. The quote plus the five lines that are not in it — internal effort, exception handling, parallel run, year-two maintenance, contingency.

Six. Benefit, split. Cash saving and capacity gain as separate lines, each with what makes it real.

Seven. What would make this fail, in writing. The assumptions that carry the case, and what happens if the straight-through rate comes in twenty points lower.

Eight. What we will measure afterwards, and when we will look.

The numbers to use

Your straight-through rate, measured. Two weeks of tallying beats any assumption, and it is the number the whole case rests on.

A rate you would actually stop paying, for the cash line. Not a loaded rate applied to time that redistributes.

Maintenance at a stated percentage of build, even if it is a guess — a stated guess is defensible and an omission is not.

And a duration a third longer than quoted. Slippage removes benefit months and adds cost months, and it is the most reliably optimistic figure in any proposal.

The section that makes it credible

"What would make this fail."

Nobody writes it, and it is the section that distinguishes an analysis from a pitch. Three or four sentences:

This case assumes an 82% straight-through rate, measured over 200 instances in March. At 65% the payback moves from 14 months to 22. The largest risk is supplier format variation, which we have not tested outside the current top twenty.

A reviewer reading that trusts the rest of the document. A reviewer reading a case with no risks stated discounts all of it, correctly.

The follow-up nobody schedules

Put a date in the case: we will report actuals against these figures at month nine.

Two effects. It changes how the numbers are written, because they will be checked. And it produces the only real data anyone in your organisation will ever have about how automation performs in your operation, which makes the next case better.

Most organisations run several automation projects and never compare a single one against its own business case.

The one-page template

Problem                one sentence
Baseline               volume / straight-through / hours / errors
Alternatives           do nothing | simplify | fix upstream | hire
Scope                  automated: ___   not automated: ___
Cost                   quote + internal + exceptions + parallel
                       + maintenance yr2 + contingency
Benefit                cash: ___        capacity: ___
Risks                  assumptions and what happens if wrong
Review                 actuals reported at month ___

Eight lines. Harder to write than a vendor model and considerably easier to defend.

The short version