The Rules Nobody Wrote Down

“Just let customers book a call.”

It sounds like one of the easiest pieces of software you could build. Put a calendar on the website. Show the available times. Customer picks one. Done.

Then somebody asks which staff member gets the booking.

Whoever is free?

Fine.

What if one person has six calls that day and another has one?

Round robin, then.

What if somebody is on leave next week but forgot to block the calendar?

What if an existing customer should always go back to the person who knows them?

What if a very valuable enquiry comes in and the next person in the round robin is the newest member of the team?

Our calendar has somehow become a qualification system, a workload allocator, a routing engine and a collection of business rules. And we were only trying to book a call.

I have learned to become suspicious whenever somebody puts the word just in front of a software feature. Usually there is a person somewhere who has been quietly making all of these decisions already.

Someone messages them: can you find this customer a time next week? They check who is around. They know who is already overloaded. They remember who spoke to the customer last time. They might even know that this particular customer and this particular colleague should never be put in the same meeting again. Then they book the call.

Nobody thinks of this as sophisticated decision making. They call it scheduling. Once software takes over, the hidden decisions become visible.

Engineers have names for this

The original calendar idea is what software people call the happy path. Everything behaves normally: the customer qualifies, the calendars are accurate, the right staff are available, nobody has made an unusual promise, and the booking goes through. Then reality arrives. Those are the edge cases.

The useful thing about these two terms is that they change how you look at a business process. A process diagram describes the happy path. Much of the real intelligence of an organisation sits around its edges.

Humans handle this mess remarkably well. They look at context, remember history, ask somebody nearby, make small judgement calls and keep moving. A small company might carry these decisions in the heads of two experienced people. A larger one spreads them across policies, Slack messages, spreadsheets and several layers of management. Either way, the written process rarely contains the whole process. This is the clean demo meeting the dirty organisation, and it is old news.

What has changed is how quickly we are wiring software into the places where those judgement calls live.

AI can learn the unofficial version

Traditional software forces somebody to define the allocation rule. Give each qualified enquiry to the available salesperson with the fewest bookings that week. Then every exception has to be coded too, which is why the rule always arrives late and always arrives contested.

An agent has another option. It can look at previous bookings, read the CRM, see the calendars, search Slack, and look at how similar customers were handled before. This is a shipping product rather than a thought experiment: Salesforce’s Slackbot positioning describes AI reading channels, conversation history, files and business applications together, then assigning leads and updating records from that context. ^[1]

This is powerful precisely because the business may never have written the scheduling logic down. The agent can infer it. Suppose it reads the past year and finds that large customers usually go to senior staff, existing customers usually return to the same person, and urgent enquiries usually go to whoever can respond first. It will reproduce that behaviour closely.

There is still a question hiding underneath all of it. Why did we do it that way?

Precedent is useful. It is also sometimes accidental.

Businesses run on precedent constantly. Something happened before, so people use it as guidance for what to do next, and that is often sensible. The experienced person doing the scheduling remembers that a similar customer went to a particular colleague last time and it worked, so this one goes there too.

But history contains reasons the database will never show. That colleague got those customers because someone else was on parental leave. A rule changed in January, and half the historical data comes from before the change. And some of those decisions were simply bad decisions, made on a bad day. They all appear in the record, and once they are there they all look the same. What happened before and what should happen again are different questions.

Now watch what the booking agent does with that. It discovers that high-value enquiries usually go to senior staff, so it starts doing that consistently. It works beautifully. Six months later, senior staff receive nearly all the best opportunities. Junior staff get fewer chances to develop, so they close fewer good deals, so the pattern in the data gets stronger, so the agent routes even more confidently. Nobody designed this policy. Nobody approved it. Nobody can point to the meeting where it was agreed, because there wasn’t one.

The old human scheduler had been balancing several things at once. Revenue mattered, but so did fairness, development, workload, and whether somebody was having a terrible week. Those tradeoffs were never written anywhere. The data only shows the final booking.

“A decision contains less information than the process that produced it.”

You can see the outcome. You cannot always see why somebody chose it. Once an agent repeats the outcome consistently, an informal tendency hardens into something that behaves exactly like policy — without the agent making a single identifiable mistake. Its prediction might be excellent. It learned what the organisation usually did, while nobody asked whether usually was still what the organisation wanted.

Rule, precedent, exception

The answer here is to point AI at these decisions harder, not to keep it away from them.

An agent that can read thousands of previous bookings will surface things the company has never noticed. Why does one person receive so many more premium enquiries than anyone else? Why do so many customers bypass the qualification process entirely? Why does everybody ask the same person whenever this particular exception appears? Process mining has asked those questions for years; what is new is that you can now ask them in a sentence, of your own messy history, without a project. So before telling the agent to reproduce the pattern, have it expose the pattern. Then ask what the pattern represents.

Those three are nearly identical in historical data, and they should not produce the same behaviour tomorrow. That distinction matters for a booking system. It matters much more when agents start touching pricing, complaints, approvals, hiring and payments.

I should be honest about the weak point in my own advice. The sort is cheap now and dear later — once an agent has been routing confidently for two quarters, its behaviour is the baseline everyone plans around. But “expose the pattern before you automate it” is easy to write and easy to skip, and the review step I am recommending has no natural owner and no deadline. The same agent that surfaces the pattern is the one waiting to act on it, and the gap between those two things is where a busy company saves an afternoon.

So take the smaller and more durable version instead. Rigid software used to hit a missing rule and stop, which forced somebody to answer the question; a capable agent works around it and carries on, and the friction that used to say the business itself has never decided goes quiet. It is the same mechanism as AI executing the wrong idea for much longer, pointed at your operating procedure instead of your roadmap. Somebody’s name goes against the patterns you automate, before they are automated.

Johnny’s verdict

• Start with the boring processes, and hunt for the phrases that mark their edges. “It depends.” “We usually…” “Except when…” “Ask the person who knows.” Those four tell you where the real business logic lives, and none of them are in the process document.
• Let AI do the archaeology. Have it search the history and show you patterns nobody could see at this scale. Worth doing even if you automate nothing afterwards.
• Sort before you automate. Rule, precedent, or exception. If you cannot trace a pattern back to a decision somebody made on purpose, it is not policy yet, however consistent it looks.
• Treat the instruction file as production code, with a name against it. If a sentence in a context document decides how enquiries get routed, it deserves the review, the version history and the owner you would give an if statement doing the same job — and somebody to ask, in six months, why the system behaves this way.

The opportunity here is bigger than automating the company you already have. AI gives an organisation a genuinely new way to inspect the strange accumulation of decisions, habits and workarounds it has built up over years, and to decide which of them are still worth keeping.

Because an agent can learn how your company behaves surprisingly quickly. Someone still has to decide how your company should behave.

You are helping me work out which of my business's habits deserve to become rules before an agent starts acting on them. Start with what you already hold: search our past chats and your memory of me for processes we have discussed — how work gets allocated, who handles the awkward cases, anything I have called "it depends" or "ask the person who knows". If you cannot reach our history, ask me to walk one routine process end to end, including the last three times it went off-script.

Apply these rules:
1. Separate the happy path from the edges. The real logic sits in decisions that only surface when something is unusual.
2. Sort each pattern into rule (consciously decided), precedent (simply done before) or exception (the normal rule deliberately did not apply).
3. A pattern you cannot trace to a decision is not policy, however consistent it looks.
4. Say what an agent would learn from the history alone, and what that hardens into after six months.

Deliver a table of my patterns with the sort, the likely origin, and the one that would do most damage automated tomorrow.

If you can browse the web, read the full essay first — it carries the complete argument and sources: https://thejop.com/essays/the-rules-nobody-wrote-down/

Prompt from "The Rules Nobody Wrote Down" — Johnny Opinion Press, thejop.com