Where the line gets drawn first
Every strategy session ends with a sort. Each step goes into one of two piles, the steps a rule can describe and the steps that need a person, and the build follows the first pile. It stays away from the second. The sort is made at a table with the people who do the work, on the cases they can remember that afternoon. That's the part worth being plain about, because memory of a process is mostly memory of the times it went wrong.
When someone says a step depends, we ask on what. Sometimes the answer comes out as a condition straight away, the order is over a certain value or the customer already has an account, and then it was a rule the whole time, one the team had been applying without ever saying so. More often the answer is that they'd have to see the case, which is fair for a person to say about work they've done for years and never had to describe. We don't argue with it in the session. The step goes to the judgment pile and a person keeps it.
The judgment pile gets drawn from the hardest cases anyone can recall. Hard cases stick. A team that handled a year of enquiries remembers the handful that went badly, so the sort in the session leans towards leaving things with a person. In the first month that is the right way to lean. Hours left with a person can be recovered at the next review. A wrong decision made by a rule reaches the customer before anyone in the building has seen it.
What a month of cases shows
Once the automation is running, every case it hands over lands in one place. The person reads the record with the enquiry or the quote attached and decides what to do, and the record stays where it was. After a month there is a pile of them, sitting in a queue or a CRM view, and nobody has read it as a pile. Each case was read once, by someone busy.
We read it together, with the person who handled the cases, and we read it in one sitting. For each record we ask the same thing, what the person looked at before deciding. The answers repeat quickly. A quote went to a person because the job was outside the usual area, because the customer wanted it started this month, because the address had been turned down before, or because the form came in without a phone number. One at a time, spread over a month, each of those sounded like judgment. When the same reasons come up in a row on a Tuesday afternoon they are conditions, and a condition is something a rule can carry.
Not every reason repeats, and the ones that don't are the real judgment. What the sitting produces is a shorter list of those, and a written rule for everything else, in the words of the person who used to decide. The rule usually has more conditions than anyone offered in the session, because there they were describing a habit from memory, and here they are explaining a decision they can see in front of them. Those are different questions and they get different answers.
It moves the other way as well
A rule agreed in the session can also turn out to have been a judgment call written down too early. The acknowledgement that goes out to every enquiry was written for the enquiry the team had in mind, a request for a quote from someone who found the website. It reads badly when the same form is used by a supplier chasing an invoice or a customer with a complaint. Nobody thought of those in the session, because the session was about the enquiries the team wanted more of. The rule handled them anyway, in the wrong tone.
These cases are harder to find than the ones a person handled, because a rule that decides leaves no note of the decision it got wrong. The person sees only what came to them. So the review reads a sample of what the automation handled alone, picked at random from the month so that nobody's memory chooses it. The person who used to do the work says which ones they'd have done differently. Where the answer is more than one or two, the step goes back to a person, or the rule gets a condition that sends that kind of case out.
A step moving back is an ordinary result of the review. The hours it returned were real for the month it ran, and the case it mishandled was the price of finding where the line sat. The failure is finding that case at day ninety when day thirty would have shown it. By then the rule has met it again, and every one of those times reached a customer.
Why the review has a date on it
The sort in the strategy session is made from memory, by people who haven't yet seen the automation run. A second sort made on a month of cases is better, and a third made on a quarter is better again, so the line is something we go back to at a time agreed before the build starts. The first review sits at day thirty, alongside the five numbers, because the team is already in the room and the person can still remember what they were thinking. After that, once a quarter is usually enough.
Putting a date on it changes what happens in the session. When the team knows the line will be looked at again in a month, they stop arguing to get a step across it now. The ones who were nervous about handing a decision to a rule agree to try it, because trying it for a month is a smaller thing than agreeing to it for good. The judgment pile gets smaller at every review. Nobody has to be right the first time.
The review is short and it has a shape. The person who does the work sits in it, along with the person named in the handover as the owner of the automation, and those are often two different people. On the table are the cases the automation handed over and a sample of the ones it handled alone. Both get read against the rule as it is written. The output is a change to the rule or to where a step sits, and a line in the handover note with what changed and the date. Nothing else gets decided in it.
