Describe the transaction before choosing the layout
Write a plain-language account of one customer relationship before opening a slide template. Who buys the offer? What do they receive? What determines the charge? Is the payment recurring, usage-based, a transaction fee or a one-off project fee? The answers give the slide its content; “B2B” or “subscription” alone does not.
In his Y Combinator guide to pitching, Michael Seibel advises founders to explain the simple business model rather than present a collection of possible ways to make money. For the slide, the practical implication is to distinguish the main revenue mechanism from ideas the business may explore later.
Start with the arrangement you actually use. If there are no paying customers yet, describe the proposed arrangement and label it accordingly. A useful explanation can be precise about the intended customer and charging unit while being honest that the commercial terms remain untested.
Separate the paying customer from the product user
The person using the product may be different from the organisation paying for it. In a fictional building-inspection software business, site coordinators could record inspections while a facilities operator buys access for the sites it manages. Calling both groups “users” would leave an investor unsure who holds the contract.
Name the paying organisation and the operational users separately where that distinction matters. Add the buyer’s role if it helps explain the sale, but avoid turning the slide into an organisation chart. The commercial relationship and the everyday use should be clear at a glance.
For a marketplace or an offer funded by a third party, draw the relevant sides explicitly. Label who pays whom and what the fee relates to. Keep the value of the underlying transaction distinct from the amount the business earns from it.
A worked example: show what the subscription covers
Consider a fictional inspection software company preparing its first investor deck. Its draft business model slide reads “Recurring SaaS revenue”, followed by “Subscriptions”, “Setup services” and “Future analytics”. It does not identify the buyer, the charging unit or the role of the people using the tool. This is an invented teaching example, not a Pitchwave project or an account of a real business.
For the revision, suppose the team proposes an annual subscription priced per managed site. A facilities operator would hold the contract; its site coordinators would use the software. Initial configuration would have a separate one-off fee. The proposed subscription would cover inspection recording and a central review screen. None of these terms has been tested with paying customers in this example.
The revised headline becomes “Proposed annual subscription per managed site”. The diagram below connects the operator’s payment to the software access it would buy, then identifies the people who would use that access. A note keeps the setup fee separate from the recurring subscription.
This changes the conversation. The investor can now ask how a managed site is defined, how sites are added or removed and what work the supplier must do to configure an account. “Future analytics” is removed from this slide because the example has no defined commercial offer for it. It can be discussed as a future possibility without presenting it as an existing revenue stream.
Show the payment, the access and the people using it.
↳ Next to resolve: the definition of a managed site, changes during the contract and the effort required to configure and support it.
Define the charging unit and the important exceptions
A unit such as “per site”, “per seat” or “per transaction” needs enough definition to be interpretable. For the fictional example, the slide could describe a site as a physical location included in the customer’s subscription. The team would still need to decide how temporary locations or changes during the contract are handled.
If pricing is established, show the relevant amount with its currency, unit and billing period. Explain whether a quoted monthly rate is billed monthly or under an annual contract. If prices vary materially by customer or scope, an unexplained “from” price may obscure more than it clarifies.
Keep a material exception beside the claim it changes. A compulsory implementation fee, a minimum commitment or an excluded service may be necessary to understand the arrangement. Put the full rate card and detailed terms in follow-up material, while retaining the qualifications needed to interpret the main slide.
When pricing is still proposed, show that status next to the price or unit. Do not use an attractive invented amount to make the slide look complete. A missing commercial decision is something to resolve, not something a layout should conceal.
Show what delivering the offer requires
The charging mechanism is only part of the explanation. If each sale also requires substantial setup, support, purchased services or other delivery work, indicate the relevant cost drivers. That helps the reader understand what has to happen alongside revenue growth.
Y Combinator’s Demo Day guidance asks founders to explain the model in simple terms while making its economics credible. It does not prescribe a universal slide layout. For a business where delivery costs are material, a short note about those costs may explain more than another list of monetisation options.
In the fictional inspection example, the team would need to examine configuration effort and ongoing support before claiming that adding sites produces attractive margins. The diagram shows a proposed commercial arrangement; it cannot establish the cost or profitability of delivering it.
Use actual, consistently defined figures when available, with their period and scope. Keep current results distinguishable from planned economics. A detailed financial model can support follow-up questions, but it should agree with the units and revenue categories shown in the deck.
Match the visual to the relationship you need to explain
For a straightforward subscription, a labelled exchange between customer and supplier may be enough. A marketplace may need both sides and the fee shown on the appropriate payment route. A combined hardware-and-service offer may need to separate the initial purchase from ongoing charges.
Use arrows for a named relationship: payment, access, delivery or use. An unlabeled arrow forces the reader to guess. Avoid adding every operational step to a diagram whose purpose is to explain the commercial model; the product walkthrough can show how the work itself happens.
Check that the slide, traction figures and financial plan use the same definitions. Paying accounts, subscribed sites and individual users are different quantities in this example. A deck becomes difficult to assess when each section quietly changes the unit.
When preparing an investor presentation with a designer, provide the customer relationship, the charging basis, material terms and the evidence behind any economic claims. The design can then reveal how the arrangement works, rather than filling gaps with generic revenue icons.
- CustomerCan a reader identify who holds the contract and who uses the offer?
- PaymentAre the charging unit, period and any material separate fees clear?
- ScopeIs it clear what the payment buys and what falls outside it?
- DeliveryAre important cost drivers or service obligations acknowledged?
- StatusCan the reader distinguish an operating model from a proposed one?
Sources and further reading
- Y Combinator — How to Pitch Your Company ↗ · Published
- Y Combinator — A Guide to Demo Day Presentations ↗ · Published