“Business modeling” can sound like something consultants do with sticky notes. In practice it’s simpler and more useful than that: a business model, in the operational sense, is a clear description of how your organization actually works — what it keeps track of, what it knows about each of those things, and the steps that information moves through.
Every business already has one. It’s just usually unwritten, spread across people’s heads, spreadsheets and habits.
Two meanings of “business model”
It helps to separate two ideas that share a name:
- The commercial business model — how the business makes money: who the customers are, what they pay for, what it costs to deliver.
- The operational business model — how the work is organized: the entities, information and processes that make delivery possible.
This article is about the second. It’s the one that decides whether your systems help or get in the way.
The three layers of an operational model
1. Things (entities)
The nouns of the business: customers, properties, orders, cases, assets, employees, suppliers. A good test is whether you’d put it on a list and count it.
2. Information (attributes and records)
What you know about each thing: a customer’s contact details, a property’s address and site details, an order’s line items. Some of this is stable profile information; some accumulates over time as history or measurements.
3. Process (states and steps)
How things move: a request is received, reviewed, scheduled, completed. Who is responsible at each step, what must be true before moving on, and who needs to know when something changes.
A useful model covers all three. Many systems model only one — a CRM models customers, a form tool models information capture, a task tool models steps — which is why the pieces never quite fit together.
Why model deliberately
- Onboarding gets faster. A written model tells a new hire what the business tracks and where it lives.
- Systems fit better. You can choose or configure tools to match the model instead of reshaping the business to fit the tool.
- Data gets more reliable. When everyone agrees what a “property” or an “order” is, records become comparable.
- Growth becomes additive. New services or locations become additions to the model rather than a reason to start over.
A method you can use this week
- List the things. Ask the team, “What do we keep track of?” Write every noun. Cross out tasks (“billing”) and states (“overdue”).
- Group and nest. Decide which things stand on their own and which always belong to something else — a site survey belongs to one property.
- Write down the information for each thing. Look for groups of fields that repeat across things — contact details and addresses almost always do.
- Sketch the main process for each thing. Four or five named stages is plenty to start.
- Assign responsibility. For each thing and each stage, name the team that answers for it.
- Test it against a real week. Walk through last week’s work and check that everything had a place in the model.
Keep it on one page. A model that nobody reads isn’t doing its job.
Common pitfalls
- Modeling the org chart instead of the work. Teams change; the things the business tracks change much more slowly.
- Modeling tasks as things. “Inspections” can be a thing; “inspecting” is a step.
- Too much detail too early. Start with the few things that matter most and grow the model as you learn.
- Letting the tool decide. If a tool forces a concept on you that the business doesn’t use, the model will fight the tool forever.
From model to system
Once the model exists on paper, the question is which system can hold it without distortion. That’s the idea behind Stratosphere Atlas: you describe the things you track as classifications, the information as reusable schemas, and the process as pipelines, and Atlas becomes that system. Modeling your business in Atlas walks through the same method inside the product.
A worked example: a service business on one page
Here’s what the method produces for a small landscaping company.
Things: customers, properties, site surveys, crews, equipment, service visits, quotes, invoices.
Nesting: customers, properties, crews and equipment stand alone. Site surveys and service visits belong to a property.
Information:
| Thing | What we keep |
|---|---|
| Customer | Contact details, billing address |
| Property | Service address, site details (lot, irrigation, gate) |
| Site survey | Site details, work description |
| Service visit | Date, crew, work summary |
Notice that contact details and addresses repeat. Those become reusable groups.
Process for a service request: received → reviewed → scheduled → completed → invoiced. The office owns the first two stages, the crew the next two, and the office the last.
That single page is a complete operational model. It fits on a whiteboard, and it’s enough to configure a system around.
Modeling workshops that work
If you’re modeling with a group, a few facilitation tips:
- Invite the people who do the work, not only managers. They know the exceptions.
- Write nouns on cards so things can be grouped and re-grouped physically.
- Park disagreements about naming and settle them at the end; arguing early stalls the session.
- Ask “what do we do when…?” for three real recent cases, and check the model handles each.
- Timebox it. Two hours produces a first model; perfection takes forever and isn’t required.
Keeping the model alive
A model is only useful if it stays current:
- Review it when the business changes — a new service line, a new location, a new team.
- Let the system be the source. When the model is implemented in software, the software becomes the living version; the page is a summary.
- Watch for side spreadsheets. A spreadsheet beside the system usually marks something the model is missing.
- Retire what you no longer track so the model reflects the business as it is now.
Frequently asked questions
How detailed should a first model be? Detailed enough to handle last week’s work, and no more.
Is this the same as process mapping? Process mapping covers the steps; business modeling also covers the things and their information. You need both, and they inform each other.
Who should own the model? Someone close to operations. It’s a business artifact, not a technical one.
