What Should a Business Model Slide Explain?
What Should a Business Model Slide Explain?
A product slide says what you offer. A pricing slide says what someone pays and under what terms. A business model slide is the one that has to connect them: it follows an ordinary instance of your business from the customer's need through to the money, and it names the work that makes that exchange possible.
That is the whole job, and it is smaller than it sounds. Most weak versions fail the same way — they put a label where the explanation should go. "We're a subscription business." "It's a two-sided marketplace, we take a commission." "Freemium." Those phrases are efficient shorthand between people who already understand the arrangement. Shown to someone who doesn't, they answer the question by repeating it.
Practically, the slide usually holds one diagram plus a few lines of text. The diagram follows a single ordinary cycle and shows:
- the customer and the need being met,
- who chooses the work and who pays for it, when those differ,
- what triggers payment,
- what your company must actually do to deliver,
- what that work depends on — people, suppliers, equipment, capacity,
- what the payment is for, and which costs recur,
- what repeats across customers, and what varies.
If that list looks familiar, it overlaps with standard planning checklists. The U.S. Small Business Administration's guidance on planning your business names components including value proposition, customer segments, key resources, key partnerships, cost structure and revenue streams. That is a list of questions a plan has to answer, not a slide layout. It won't tell you which connection matters most in your case or in what order a reader should meet them. That ordering is your work.
Identify who uses, chooses, and pays
Start with a real instance rather than a taxonomy of model types. Here's an invented one to work with.
Bell Street Repairs is a fictional small shop, described here only for teaching. Its stipulated facts: customers bring in small household appliances — kettles, toasters, desk fans, sewing machines. The shop assesses the item, tells the customer what's wrong and what the repair would cost, and charges nothing for the assessment, which costs a technician part of an hour. The customer either authorises the work or declines and takes the item home; some items can't be repaired because no part is available. Authorised work happens on the bench, using technician time and parts ordered from an outside supplier, occasionally salvaged from appliances that couldn't be repaired. The customer pays on collection, after the repair is tested. Payment covers labour and parts. The shop guarantees its repairs for a stated period, and redoes a failed repair at no charge inside it. Whether a customer ever returns with a second item is possible, not assured. The shop can complete only as many repairs as its technicians' hours allow.
In that instance, the person using the appliance and the person paying the shop are the same person. Say so, or a reader will spend the slide wondering. Then handle the case where they diverge, because it is common and it changes the picture. A landlord brings a tenant's broken appliance. The tenant uses it. The landlord authorises the repair and pays for it.
Now the slide has two relationships to declare instead of one. Who can start the work, and who is billed when it's done. Those are different facts, and a repair shop that has the tenant's verbal approval but not the landlord's signature hasn't got a job yet. It also has a different reason to be paid: the landlord isn't paying because the appliance is pleasant, but because keeping it working is an obligation. Attractive experience for the user doesn't explain the payer's decision. Only the payer's own situation does.
Keep a third distinction in view while you write: what happens now versus what you hope will happen. If Bell Street is considering a maintenance plan for landlords with several properties, that's a proposed arrangement. It can go on the slide clearly marked as proposed, or on a later roadmap slide. What it can't do is sit in the diagram looking like a current fact, because a reader comparing your revenue description to your figures will find the gap and start doubting the parts of the deck that were accurate.
Show the work required to deliver the value
The middle of the slide is the part founders skip, and it's the part that makes the slide worth its page. What has to occur between someone's need and a completed exchange?
For Bell Street: intake, assessment, diagnosis, a quote, the customer's decision, ordering parts, bench work, testing, hand-over, payment, and then the warranty obligation that sits quietly in the background for a stated period afterward. A reader who can follow that sequence understands the business.
Name the dependencies where the model genuinely rests on them. Technician hours are Bell Street's capacity limit — not marketing, not demand. The parts supplier's availability and lead time decide whether a job can be promised this week. The bench and test equipment decide how much work fits in the room at once.
Then draw the branch that doesn't end in money. Assessments that lead nowhere consume technician time and produce no payment, and they happen routinely: the customer declines, or the part doesn't exist any more. A diagram showing only the successful path implies that every request converts, and anyone who has run a service business will read that as either inexperience or evasion. The dead end belongs on the slide, labelled with what it costs you — time spent, nothing billed.
What doesn't belong is your operating procedure. The slide isn't the manual, and a reader assessing the business doesn't need the torque settings. The test for any element is whether it changes the reader's understanding of how money arrives or what it takes to keep the doors open. If it doesn't, cut it.
One more caution: a tidy three-box diagram can quietly erase the human work. If the real business is a technician spending an hour bent over someone's kettle, make sure the slide says labor, in words, somewhere. Diagrams are persuasive, and they persuade most strongly about the things they leave out.
Connect revenue to the major cost logic
Three questions, answered plainly, do most of the work here.
What is sold. A completed repair — not an assessment, not a promise. This matters because it tells the reader when value actually changes hands.
How often it can happen. For Bell Street, this is a capacity question before it's a demand question: as many repairs as the technicians' hours allow. And whether a given customer comes back is an open question the model shouldn't answer for them. Say that repeat visits happen, or that the shop hopes they will, and let the reader see which one you mean.
What it consumes. Technician time on both successful and unsuccessful assessments, parts that were bought or salvaged, bench and test equipment, and rework inside the warranty period. That last one is easy to forget because it arrives after the money does, and it belongs in the cost logic precisely for that reason.
Then hold the line the slide is most tempted to cross. The logic of a model is not its margin. You can explain that Bell Street charges for labour and parts and absorbs some rework at no charge — that's the arrangement, and it belongs on this slide. You cannot conclude from that diagram that the charges cover the rework, or the technician's hour, or the rent on the bench. That conclusion needs your own records: what jobs actually cost, what you actually collect, how often repairs come back. Those numbers belong on a financial slide, and they carry a different kind of claim than the diagram does.
So use figures sparingly here, and when you do, mark their origin inside the slide. "From last quarter's job records" and "placeholder, to be replaced" are not the same claim, and a reader who can't tell them apart will assume the stronger one. This example uses no amounts at all, which is normal and respectable at the stage where you're still explaining the arrangement.
Compare the model with product-only and price-only slides
The fastest way to see what the business model slide is for is to write the other two and look at what goes missing. Same fictional company, three versions.
Version one: the offer.
Bell Street Repairs
We repair small household appliances.
Honest assessment. Careful work.
Guaranteed for the stated period.
A reader learns what's available and nothing about how it becomes a business: who pays, when, on what trigger, what the shop needs in order to do the work, or what happens when an assessment leads nowhere.
Version two: the charges.
Charges
Assessment — no charge
Labour — quoted before work begins
Parts — included in the agreed quote
Warranty rework — no charge
Payment due on collection
This is clearer about terms, and it still leaves the actual activity invisible. Nothing here says where a part comes from, how long a repair occupies a technician, or why the shop absorbs the rework. A price list answers how much, under stated conditions. It doesn't answer how the arrangement works.
Version three: the exchange.
Customer's item stops working
│
▼
Assessment (no charge; technician time spent)
│
├──► customer declines, or no part available
│ item returned, nothing billed
│
│ customer authorises; price agreed
▼
Repair on the bench
• technician time
• parts ── ordered from the parts supplier (lead time)
• └─ or salvaged from unrepairable items
│
▼
Test ──► customer collects ──► payment (labour + parts)
│
▼
Warranty: rework at no charge inside the stated period
│
▼
Possibly repeated: the same customer, another item
The third version does something neither of the others can. It shows the reader a complete circuit — need, work, dependency, payment, obligation — and it does so in one pass. It stays readable because it follows one instance rather than describing the business in the abstract.
The failure mode to avoid is turning this version into a catalog. Once a founder starts drawing, every edge case wants in: the customer who pays a deposit, the part that arrives wrong, the appliance collected a month late. Add a branch only when it changes what the reader understands about money or capacity. The unconverted assessment earns its place because it consumes real time and produces nothing. A late collection doesn't, unless it holds up your bench.
What the finished slide lets a reader do
Hand the slide to someone who doesn't work at your company and ask them to say, in their own words, who pays, for what, and what the company has to do to deliver it. If they can say all three, the slide works — even with no amounts on it anywhere. If they answer by naming a model type instead, and that label isn't how you actually get paid, the slide let shorthand do its job for it.
Keep three things visually separable as you revise: what happens today, what you're proposing to add, and what your records show. The business model slide is where the first of those lives. The other two can share the page, but never in a form that requires the reader to guess which one they're looking at.
Frequently asked questions
What is the main job of a business model slide?
It connects the product slide and the pricing slide by following an ordinary instance of the business from the customer's need through to the money, and by naming the work that makes that exchange possible. It should not just offer a label such as subscription, marketplace, or freemium.
Why do shorthand labels fail on this slide?
Phrases like we are a subscription business or we take a commission are efficient between people who already understand the arrangement. Shown to someone who does not, they answer the question by repeating it instead of explaining who pays, when, for what, and what the company must do to deliver.
How should the slide handle cases where the user, chooser, and payer differ?
Declare the relationships separately. In the Bell Street Repairs example, a landlord may authorise and pay for a repair while a tenant uses the appliance. Who can start the work and who is billed are different facts, and the payer's own situation explains the payment decision, not the user's experience.
What belongs in the delivery work shown on the slide?
Show the real sequence: intake, assessment, diagnosis, quote, customer decision, ordering parts, bench work, testing, hand-over, payment, and the warranty obligation afterward. Name dependencies such as technician hours, supplier availability, bench space, and test equipment. Include dead-end assessments that consume time and produce no payment.
Can the business model slide show margins or prove that charges cover costs?
No. The logic of a model is not its margin. It can explain that charges cover labour and parts and that some warranty rework is absorbed, but it cannot conclude that the charges cover rework, technician time, or rent. Those conclusions need actual records and belong on a financial slide; figures used here should be sparing and marked by origin.