A finance lead does not reject a support automation proposal because the savings look too small. They reject it because they cannot tell which numbers are measured and which are hoped for. The business case that gets approved is the one where every input has a source, the pilot has a pass bar agreed in advance, and the risks are priced rather than waved away.

This post is a template for that document. It contains no results from other companies, on purpose: the only numbers that belong in your case are yours.

Start with a baseline you measured, not one you remember

Before anyone talks about automation, record what support costs and looks like today. Take at least one full month, ideally the last three, and write down:

  • Conversation volume by channel (web chat, WhatsApp, email, phone), because an AI agent only touches some channels. LayBuild, for example, covers web chat, WhatsApp and a REST API, not email or phone.
  • The mix of topics. Tag a random sample of a few hundred conversations by topic and note which ones are answerable from documentation (how-to, pricing, policy) and which need account access, judgment or a refund decision.
  • Fully loaded support cost for the team handling those channels, and cost per human-handled conversation (loaded cost divided by conversations handled).
  • First response time and time to close, from your helpdesk reports.
  • CSAT or whatever satisfaction measure you already collect.

The topic sample is the most useful part of the baseline. It sets a ceiling: if only a third of conversations are answerable from documentation, no AI agent grounded in your docs will handle much more than that, and your case should say so.

Design the pilot so it can fail

A pilot that cannot fail proves nothing to finance. Write the pass bar down before it starts and get the finance lead to agree to it.

Keep the scope narrow. One channel, one or two agents, and the topics your baseline marked as answerable from documentation. Run it long enough to cover a normal month's pattern of questions; a few weeks is usually enough to see whether the knowledge base covers what people ask.

Decide in advance how you will label outcomes. Pull a random sample of pilot conversations every week and have a person who knows the product mark each as correct, wrong, partially correct, refused, or handed off. Two reviewers on a shared subset will tell you whether your labels are consistent.

A pass bar might read: "The agent answers at least X% of in-scope conversations correctly, with no more than Y% wrong, and CSAT on AI conversations is no lower than Z." You pick X, Y and Z from your ROI model (below), not from a vendor's marketing.

What to measure during the pilot

Measure the things that feed the money calculation and the things that would make you stop.

  • Share of conversations answered correctly without a human, from the labelled sample.
  • Share answered wrongly, and what those wrong answers were about. A wrong answer about opening hours and a wrong answer about refund eligibility are different risks.
  • Share that ended in LayBuild's fixed no-answer reply ("I do not have specific information about that in the knowledge base..."), which the agent sends when retrieval finds nothing or the answer overlaps too little with the sources. This is your documentation gap list.
  • Handoff rate. In LayBuild, handoff happens when a customer asks for a human and the org has human handoff enabled (it is off by default), or when a conversation passes 25 AI turns.
  • Human hours spent on the channel, compared with the baseline.
  • LLM token spend, from your provider's dashboard if you bring your own key.
  • CSAT on AI conversations. LayBuild records a 1 to 5 rating per conversation and shows the average and the share of 4s and 5s.

Turn the pilot into money with explicit formulas

Use the pilot's measured rates in a model finance can recompute. The full method is in how to calculate AI support ROI; the short version is:

text
avoided_cost = volume x share_correct x cost_per_human_conversation
added_cost   = platform_price + llm_cost + review_time_cost + (volume x share_wrong x cost_per_wrong_answer)
net_monthly  = avoided_cost - added_cost

Put the platform price from the vendor's price sheet. LayBuild's plans are flat: ₹1,499, ₹3,999 or ₹9,999 a month for 1,500, 8,000 or 20,000 conversations, lower if billed annually (see pricing). Put review time in as a real cost line. Put the cost of a wrong answer in as a stated estimate, and say who estimated it.

Then say whether the result is cash or capacity. Avoided cost only becomes cash if a budget line goes down: fewer contractor hours, a hire you no longer need to make, an outsourcing contract you shrink. If headcount stays the same, the case is about capacity (absorbing growth, shorter queues), and it should be written that way.

Name the risks and put a number or a control on each

Finance leads distrust a business case with no risk section more than one with a long one.

Wrong answers are the main risk. LayBuild answers only from your content and replaces answers that share too little vocabulary with the retrieved sources (fewer than 25% of the answer's stemmed words) with the fixed no-answer reply. That check is lexical, not a citation check: it can let through a wrong answer that reuses the right words, and it can block a correct answer that paraphrases heavily. So the control is your weekly labelled sample, plus keeping high-stakes topics (refunds, legal, account changes) out of scope or routed to humans.

Automatic learning is the second risk, and you should describe it plainly. After each reply, LayBuild automatically publishes exchanges it judges learnable into the knowledge base as a document and a Q&A pair, without human approval. If the customer rates that conversation 2 stars or lower, the learned knowledge is retracted. Since most customers do not rate, a wrong learned answer can stay in the knowledge base until someone finds it. The control is a scheduled review of learned entries, budgeted as part of review time.

Other risks worth a line each: documentation that goes stale (LayBuild does not re-sync URLs on a schedule, so someone has to re-import changed pages), non-English questions (the default embedding model and full-text search are English, so retrieval is weaker for other languages), and vendor lock-in (how you would export conversations and knowledge if you left).

Show a sensitivity table, not a single number

A single ROI figure invites the question "and if you are wrong?". Answer it before it is asked. Take your pilot's measured correct and wrong rates and show net monthly value across a range around each: for example, correct rate at the pilot value, 10 points lower and 10 points higher, crossed with wrong rate at the pilot value, double it, and triple it. Then state the break-even points: the correct rate below which the platform and review costs are not covered, and the wrong rate above which the case goes negative.

If the case stays positive only in the best corner of the table, say so, and propose a smaller scope. A modest case that holds up is easier to approve than a large one that depends on everything going right.

What the one-page summary should contain

Finance will read the summary and skim the rest. Put these on the first page: the baseline cost and volume for the in-scope channels, the pilot's pass bar and whether it was met, net monthly value at the measured rates, the break-even rates, the top two risks with their controls, and whether the saving is cash or capacity. Link everything else as an appendix, including the labelled sample, so anyone can check the rates.

Next steps