The business map should learn the work

At 7:14 a.m., a restaurant account texts that the walk-in cooler behind the line is warm again. The CRM turns the message into a clean label: “urgent service call.”

On the dispatch board, that label looks useful. Morning dispatch sees a food-risk job, an existing account, and a route gap before lunch. So far, the AI has done what it was asked to do. From a messy text, it made the request short enough to act on.

By 10:30 a.m., the owner is untangling three facts the label hid. Earlier, the night dispatcher had already promised the customer that no truck would roll until the old invoice was cleared. Billing still shows the account on hold. Last month’s senior-tech note says this location needs owner approval before another emergency visit because the last two calls ended in disputed charges.

Nothing about “urgent service call” is false. That cooler may be urgent. Still, the label is not enough to become a rule.

That is the problem with AI memory in a service business. Software can invent a tidy name before the business has proved what the name should control. Once that name becomes part of the business map, the software starts treating it as reusable truth. Reports count it. Dispatch rules route on it. Billing checks may get skipped because the call now looks like a normal emergency. Later, a new office manager inherits the label without inheriting the judgment behind it.

In software, that business map is often called an ontology. Plainly, it is the named map the system uses to decide what kind of thing a call, customer, invoice, job, exception, or approval is. Ontology sounds technical. Operationally, the risk is not technical. Bad maps tell good software to do the wrong work.

Owner-led companies need a stricter habit. Before an AI-generated business label becomes a rule, the owner should be able to show three things: where it appears in the real work, what proof confirms it, and which similar situations should be handled differently.

The outside sources below are not here as authority decoration. Each gives an owner a practical test for whether an AI label deserves to become a rule.

Start with the work itself. Nicolini, Gherardi, and Yanow’s Knowing in Organizations is an organizational-studies book about how people know through practice, not only through stored instructions or individual expertise. It matters here because it treats knowing as something carried by recurring activity, tools, notes, roles, and shared routines. That fits a small service company better than the idea that knowledge sits only in one person’s head.

In the cooler call, the customer message is only one piece. Around it are a call timestamp, prior promise, invoice state, route slot, asset history, food-risk fact, disputed-charge note, and owner approval rule. Together, those pieces tell the business what the situation is. Any label that cannot point back to those traces has not learned the work. It has learned a phrase.

Next comes proof. GreggU’s Complementing Intuition with Systematic Study is a short organizational behavior lesson for managers who trust experience but still need evidence before acting. Its point is simple: instinct helps, but managers make better decisions when they look for relationships, causes, effects, and evidence. Evidence-based management adds the same discipline in plainer terms. Ask the question, look for the best available evidence, then apply it to the decision.

For the owner, the question is not “Do we like the label urgent service call?” Instead, ask, “When should an urgent request override a billing hold, and when should it wait for owner approval?” Proof might include recent urgent calls, how many had unpaid balances, which ones produced repeat disputes, what happened when a tech rolled anyway, and which customer promises were already made. From there, the evidence may show a better rule. Or it may show that the old label should stay as a note, not a dispatch instruction.

Then test for difference. Stanford GSB’s Precedents Thinking is a management article about solving a hard decision by comparing it with useful examples from elsewhere, then borrowing only what fits. It matters to a service owner because a new AI rule often needs close comparisons before it should change dispatch, billing, or customer promises.

Other industries already separate urgent need from permission to act. Healthcare has authorization. Construction has change orders. Restaurants have manager comps. Banking has overrides. Warranty work separates customer pain from claim responsibility. None of those examples should be copied whole into a small HVAC, plumbing, fire protection, pest control, or appliance repair company. Their value is in the close cases that need different treatment.

With that comparison, the owner can make a sharper rule. For an account in good standing, a warm walk-in may route as emergency food-risk work. With a billing hold, the same warm walk-in may become owner-review work. Under warranty, it may require parts proof before dispatch. After two disputed visits, it may need a phone call from the owner before the office promises arrival.

Those are not vocabulary choices. They are operating differences. Each version changes who can act, what record must be checked, what the customer can be promised, and what the next operator sees.

This is the standard a service-business owner should expect from AI tools that claim to remember CRM, dispatch, and billing context. Software can suggest labels. Messy notes can be clustered. Repeated phrases can be surfaced. But a phrase should not quietly become a rule until the owner can inspect the work, the proof, and the close cases.

Slowing the business down with academic review is not the point. Preventing a clean label from becoming hidden policy is. When “urgent service call” means food risk, say that. When it means route first, say that. When it still loses to billing hold or owner approval, say that too.

A useful business map learns what changes in the work. Useful memory does not mistake new vocabulary for better memory.

---

Source evidence used in this note: the three linked sources above, plus Stanford GSB’s companion executive education article on precedents thinking. Reviewed 2026-06-05.