Create an Expansion Business Case With Customer Facts

An expansion business case gives customer leaders a document for internal testing, challenge, and discussion. The document does not need a dramatic return estimate. Start with the decision under discussion. Is the customer deciding whether to evaluate a broader workflow, assign staff time, approve a limited test, or postpone work until a later planning cycle? One clear decision keeps discussion from becoming a loose collection of benefits.

Write the decision at the top in ordinary language. For example, a fictional merchant might ask whether finance and support should spend time evaluating a change to refund research. This wording differs from “approve the solution.” The group has not reached an approval decision yet. The case should match a real stage. If leaders need permission to investigate, show effort required for investigation and questions whose answers will inform a later choice.

Describe current process with facts a customer recognizes. Ask a support lead to walk through one recent refund research request. Where does a request begin? Which record does support open? When does finance become involved? Where does an answer go? Record each step using participant language. Do not turn a five minute conversation into an invented process map. If a step differs by case type, note the difference and ask for another example.

Facts need owners. Place a source beside every factual statement. “Support lead described a practice request on September 4” gives a reviewer a person for follow up. “Finance reported a daily reconciliation review” points to someone who understands a routine. A source label does not make a statement permanent truth. The label gives a customer a route for correction. When no one owns a fact, label a field unknown and write the person who will investigate.

Numbers need equal discipline. A manager might hear, “We spend a lot of time on refunds.” Do not turn “a lot” into a number. Ask what measure a team already trusts. Support might track request volume in an existing report. Finance might retain a review record. Neither team might have a usable count. Each answer belongs in a business case. A missing measure is useful information because leaders see evidence a decision would need.

Separate evidence from assumptions on a page. Evidence comes from a customer source, such as a current workflow description, a report already used by a customer, or an observed practice session. An assumption states something worth testing. For a fictional merchant, an assumption might read, “A shared refund record would reduce handoffs between support and finance.” Leave this sentence labeled as an assumption. Do not place a percentage beside such language. Do not describe a hoped for outcome as a customer result.

Keep a proposed change specific enough for people to assess effort. “Improve refunds” asks too much of a vague phrase. “Evaluate whether support and finance should use a shared record for refund research” gives a clear subject. Ask which teams would touch a new process, what work they need to review, and what existing process must continue during evaluation. An honest effort description helps leaders choose between a small next step and a larger initiative.

A customer business case needs effort views from more than one role. Support might need time to explain intake and handoffs. Finance might need time to identify records used during reconciliation. An internal systems owner might need time to review data flow or access questions. Do not claim such roles must approve a decision. Ask a customer who needs a voice before work begins and who holds a decision. Organizations assign those responsibilities in different ways.

The fictional merchant offers a worked example. Support says refund research begins when a customer asks about status. A representative searches order information, then requests a finance check for some cases. Finance says a daily review uses a separate record. An account manager records both descriptions. No one knows how many requests need a finance check. Instead of guessing, a case lists “Count of research requests needing finance review” as unknown. The support lead agrees to check an existing queue during a short sample period.

The manager then asks what leaders need before choosing an evaluation. An executive sponsor says leaders need a description of current handoffs, a view of available records, and an estimate of staff time for a practice review. Notice this language. The sponsor did not ask for promised savings. The case now holds a decision, known facts, a documented unknown, and work needed before executive review. Each item has an owner.

Avoid making an account manager an author of customer truth. Your role is to organize discussion and preserve distinctions between reported fact, open question, and assumption. Read each line aloud during review. Ask, “Whose view does this sentence represent?” If nobody claims ownership, move a sentence to an open question. If someone says a sentence feels fair but unproven, label a sentence as an assumption and write evidence needed for a test.

Keep a document short enough for an executive sponsor to use. A practical version often fits on one page. Include a decision, current process, evidence sources, assumptions, effort questions, decision owner, and next review date. Short sections do not mean shallow work. Each line should give a participant a clear chance to agree, revise, or accept a follow up task. A long document full of unsupported detail creates more room for confusion.

Prepare for review by sending questions before a meeting. Ask a support lead for one representative request path. Ask finance for a record used during review. Ask a sponsor which decision date matters. Explain why you ask. The group will separate known facts from items needing confirmation. Do not ask participants for a polished presentation. A few accurate notes and a sample record give discussion a better starting point.

During a meeting, keep a visible evidence plan. For every open item, record a question, owner, source for review, and response date. Use dates only when an owner agrees. A vague phrase such as “follow up soon” invites drift. “Support lead checks five practice requests before Tuesday” has a clear boundary. If a task needs specialist review, record who will route a question rather than offering an answer outside your scope.

Practice language helps when pressure rises for a number. If someone asks, “What will we save?” say, “We do not have a customer measure for savings. We have a reported concern about research handoffs. Would a short review of existing requests give you a fair basis for a later estimate?” This response protects a record without stopping discussion. The customer chooses whether a measurement exercise deserves effort.

For the fictional merchant, open a blank one page case during the next call. Enter a decision as an evaluation question. Add support and finance workflow notes, then mark request volume unknown. Assign a support lead to review five recent practice requests before Tuesday. Book executive review for Wednesday after notes return. At 3:00 Monday, send the lead a calendar note with five request identifiers and ask for a short record beside each identifier.