Business Model Flow Diagram
Show who provides goods, services, information and money to whom, with explicit directions, assumptions and agreement gaps.
Use this business-focused architecture diagram to explain value delivery and payment relationships. Put the focal service at the center and trace exchanges to the parties. Use separate diagrams for detailed processes, organizational hierarchy or software deployment.
Business scope, parties and roles, typed exchanges, agreement status, and money units and periods.
A readable party-and-exchange map, an edge list, money assumptions and responsibility or contract checks.
How to use it
- Define an existing or proposed model, period and scope, distinguishing contracts from hypotheses.
- List identified parties, putting the focal business first without implying reporting hierarchy.
- Record each directed goods, service, information or money exchange; use separate edges for different return flows.
- State each payment's currency, period and assumptions, keeping startup inputs and period expenses distinct.
- Explain the model from its edge list and identify missing responsibilities or agreements before adding detailed processes.
Keep its limits in mind
This is a business model flow diagram, not software deployment, a capability hierarchy or an org chart. Edges are exchanges, not a process sequence. Separate information from goods and money. A balanced arithmetic example proves neither transactions nor profit; a pilot permission does not approve a paid business model.
Separating book, site and membership exchanges
Fictional teaching example: Starbridge Library Service explores after-hours returns. C4 contains 20 synthetic visits on Oct 12–14, 2026 (12 during staffed hours, eight outside), three people's writing records, pilot estimates and a hypothetical monthly model. People, permissions, prices and behavior are invented. No pilot or paid service has run.
On a small screen, scroll across the diagram to read it.
Read exchanges: P supplies S, S lends to U, U returns books through S's box, and O provides the site/collection service. S sends receipt information to U. These are distinct exchanges, not a timeline.
Reconcile the hypothetical money: Ten assumed memberships at CNY20 give CNY200. Assumed payments to P and O are CNY80 and CNY60. The CNY60 remainder excludes staff, tax, depreciation and startup and is not profit. The one-off CNY800 box estimate is a separate basis.
Result: Four parties and eight directed exchanges expose contract and receipt questions. There is no actual membership demand, payment or approved paid launch; the narrow pilot permission does not supply them.
Hypothetical monthly 10×CNY20=200, less80 and60, leaves60 as a partial balance, not profit. Startup800 is separate; no paid launch or business approval is implied.
Next step: Verify demand, agreements and receipt duties, then use a process flowchart if steps and exceptions need explanation.
Three reasons to redraw the business boundary
First, pause when the picture mixes parties with internal equipment or software components. A reader, a book partner, and a site operator have different responsibilities from a database or a box. Choose the business question first. Internal detail belongs in a separate view unless it changes the exchange being explained.
Second, do not combine several directions into an unlabeled relationship. Books can move toward a reader while money moves toward the service. A line marked “cooperation” hides who supplies what and under which conditions. Record each type and direction separately, and keep a missing agreement visible rather than drawing it as a settled transaction.
Third, stop before using an attractive financial balance to justify launch. A diagram may omit staff, losses, taxes, or startup expenditure. Reconcile the stated period and boundary without inventing the missing amounts. A permission to try a removable box is narrower than an agreement to sell memberships or operate a permanent service.
Choose between exchanges, steps, operating assumptions, and roles
This business architecture view explains parties and exchanges. Its arrows do not establish the chronological order of work. Select a related method when the unresolved question needs a different unit of analysis.
| Input and question | Method | Output and boundary |
|---|---|---|
| Parties, offerings and directed exchanges | Business model flow diagram | An exchange map and agreement gaps; no contract or launch approval. |
| Operational steps, decisions and exceptions | Business process flowchart | A sequence and exception paths; no business economics. |
| Customers, delivery, partners and economics need to fit | Business Model Canvas | Connected assumptions; not verified demand. |
| An agreed deliverable lacks execution or approval roles | RACI matrix | A responsibility discussion; acceptance remains explicit. |
Trace all eight Starbridge exchanges before discussing revenue
The complete fictional C4 monthly model has four parties: S Starbridge coordinates the box and register, U represents readers, P is the book partner, and O is the site operator. The model assumes ten memberships at CNY20 in one month, with CNY80 paid to P and CNY60 to O. These are assumptions, not members, contracts, sales, or payments already obtained. The separate box startup estimate is CNY800.
The edge list below preserves eight directed exchanges. O’s proposed site and collection service remains a service exchange; it is not a reporting line or a software connection. S’s receipt information is separate from physical returns. A numbered reference can identify a claim without confirming that the returned item has been checked into inventory.
The monthly arithmetic is 10×20=200 and 200−80−60=60. That partial balance excludes staff, tax, depreciation, and startup. Do not call it profit, a cash forecast, or a recovery period for the box. The proposed preparation task is to check the membership assumption, the exchanges, and the parties’ actual responsibilities before asking for a paid launch decision.
| From → to | Type and content | Status or question to verify |
|---|---|---|
| P → S | Goods: book stock | Partner supply terms and responsibility need agreement. |
| S → U | Goods: loans | Reader eligibility and lending conditions need definition. |
| U → S | Goods: box returns | Deposit is separate from verified inventory receipt. |
| O → S | Service: site and collection | Actual collection duty and access need agreement. |
| S → U | Information: stub / receipt status | Wording must distinguish reference and checked receipt. |
| U → S | Money: assumed CNY200 | Ten assumed members at 20; no transactions observed. |
| S → P | Money: assumed CNY80 | Same hypothetical month; not a confirmed contract. |
| S → O | Money: assumed CNY60 | Same hypothetical month; not all operating costs. |
Review the explanation and the business evidence separately
Ask another reader to explain each edge using the list. If they cannot distinguish a book movement, an information update, and a payment, clarify labels before adding decoration. This checks whether the explanation is readable; it does not verify that any party will accept the arrangement.
For every proposed exchange, record the parties, conditions, responsibility, and actual agreement status. Keep an unanswered request separate from refusal or acceptance. Collection and inventory confirmation need a clear handoff, including how exceptions would be handled. These are unresolved design questions, not defects already observed in a running service.
If the business is investigated further, retain demand evidence and a fuller cost boundary separately from the diagram. A new price, member assumption, or contract condition changes the model and should be dated with its reason. Preserve the original hypothetical month instead of rewriting it as a successful forecast.
The next decision can be to gather evidence, revise an exchange, or stop. A paid service requires its own appropriate agreements and authorization. No pilot, real membership, payment, or profitable operation is reported here; the current result is a complete, inspectable explanation of a proposed model.
Check your work
- Parties, directions, types and exchange contents are explicit.
- Exchanges are not process steps, reporting lines or deployment links.
- Hypothetical payments, partial balances and agreement status remain qualified.
Framework references
References explain the framework and its scope; they do not validate the fictional example's results.
Put the framework to work
Copy the outline and add your question, evidence, and open questions.