B2B SaaS Lean Canvas Example: All Nine Blocks Completed

A complete example, with assumptions visible

CoachSlot is a fictional scheduling product for independent fitness coaches. This is an editorial teaching example, not a customer case study or evidence of demand. The numbers are assumptions to test. A canvas is useful when its blocks fit together and expose the riskiest assumptions.

1. Problem

Coaches coordinate recurring appointments in spreadsheets and messages. Rescheduling creates extra administration; clients sometimes miss sessions. Our initial hypothesis is that this costs a coach at least two hours each week. That time estimate is unverified.

2. Customer segments

Start with independent strength coaches serving 10–30 recurring clients, who currently schedule through messages and spreadsheets. The buyer and daily user are the coach. Clients use a booking link. We exclude gym chains and studios needing staff management.

3. Unique value proposition

Let recurring clients book and reschedule within your rules, without managing a calendar through messages. The promise is less scheduling administration. Avoid claiming a specific time saving until you measure it.

4. Solution

The first version includes availability rules, a client booking link, confirmation messages, and rescheduling. It deliberately excludes workout programming, payroll, memberships, and a marketplace. Every included feature supports the same scheduling workflow.

5. Channels

Test an ungated availability worksheet that coaches can use immediately, supported by a worked scheduling example. A booking page can include a discreet product link when the coach agrees. These are hypotheses about distribution, not proven acquisition channels. Track worksheet completion, coach activation, and paid pilots separately.

6. Revenue streams

Test a $19 monthly subscription per coach. At 50 paying coaches, monthly revenue would be $950 before expenses and taxes. A five-coach pilot would generate $95 per month. This is arithmetic, not a forecast. Ask for payment to test the offer rather than treating praise as willingness to pay.

7. Cost structure

List hosting, email delivery, support time, payment processing, and product maintenance. Track actual support minutes per active coach during the pilot. Set a spending ceiling before starting. Do not infer profitability from revenue alone or omit the founder's support workload.

8. Key metrics

Activation: the coach publishes availability and receives a first real booking. Retention: the coach receives repeat bookings in later weeks. Revenue: paid pilots and renewals. Product value: reported scheduling time before and after use. Record the denominator for every conversion rate and distinguish test bookings from real use.

9. Unfair advantage

None established yet. A scheduling feature is easy to copy. Trust in a specific coaching community or unusually strong knowledge of coach workflows might develop into an advantage, but neither should be presented as something the business already possesses.

Check whether the blocks agree

The customer segment requires recurring scheduling, so the solution supports recurring appointments. The price is per coach, not per client, so revenue estimates count coaches. The acquisition example addresses scheduling, not general fitness. This alignment is more useful than making each block sound impressive independently.

What to test next

First observe five coaches performing their current scheduling process. Then run a small paid pilot with a defined time window. Write down the proposed decision threshold before starting: for example, three of five coaches pay and use the product weekly for four weeks. This small result would be directional evidence, not proof of product-market fit.

If coaches do not feel the pain, revise the segment or problem. If they use the pilot but will not pay, investigate price and alternatives. If they pay but stop using it, examine the recurring workflow before adding features.

Apply the example

Use the editable worksheet below to write your own nine blocks. Keep unknowns visible. Evaluate the assumptions before expanding the feature list.