Bill the map
The extra login did not rewrite the process
This week the ticket pays for mapping, triage rules, and a named person on exceptions
You cannot seat your way out of a messy process. The software you already pay for is waiting on a person who will sit with the real path, write how the job actually moves, and change the steps so a tool can take the next one. That person is the work. The login was the easy part, and it is already on the card.
The miss last time was not the model. The miss was that nobody got paid to map a quote, a ticket, or an invoice, then refactor the handoffs. Another account in the same window will not do that job for you.
The seat is not the job
In a shop of twenty, the card already funds a helpdesk, a sheet, a chat tool, and a model that still sits in a tab. Adding one more login feels like motion. It is not. Motion is someone walking the live path with the person who does the job today, then changing the steps.
Vasuman Moza (@vasuman), who puts implementers inside companies that already own their systems, has been saying the blunt version for a year.
@vasumanAI is a services game. You cannot solve for enterprise inefficiency with tool adoption.
Vasuman Moza (@vasuman)
He is talking about large accounts. The same gap shows up on a smaller floor. You do not need a new vendor this week. You need the services work done on the tools you already have. Someone has to go in, understand the process, and refactor it. Until that happens, last quarter's seats were a quieter version of the same pile.
Scope it like a services ticket
When you write a ticket or a work order on Monday, the easy sentence is "put AI on the inbox." That sentence cannot be staffed. It also cannot fail in a way you can see. A services ticket can. It has three lines. If any line is missing, you do not start.
- A map of how this job actually moves today, including the ugly side paths
- Triage rules a person can follow at 4pm without a meeting
- Named owner for when a rule or a model mis-routes a customer
Moza's point lands on that ticket. The implementer is not the person who drops an API key into a settings screen. The implementer is the person who writes those three lines, then sits with the first week of exceptions. In a team this size that person is often the ops lead, or the owner, wearing the implementer hat for five days. If a vendor is already in the conversation, the work order still pays for the map, the rules, and the named miss. It does not pay for a key.
The owner still approves two things before anyone automates. Which process is in. Who owns the miss. If you cannot name both, the process stays parked. That approval is not ceremony. It is the only way a mis-routed customer has a human to call.
Field hygiene belongs on the same ticket. If a record cannot say who closed it, Friday will lie. Clean the fields while you map. Do not treat that as a later cleanup.
Name the miss before the rule fires
You already know who gets the angry email when a ticket goes to the wrong queue. Write that name before any rule fires. The owner names one live process. The ops lead says whether the path is already on paper. If it is not, they sit with the person who does the work and map the real handoffs, including the side doors nobody put in the SOP. Then the implementer, often that same ops lead, writes triage rules a night-shift person could follow. The owner answers who owns a mis-route. Support runs the week on live tickets, not a demo inbox.
Figure 1
Keep the human parts where they belong. The owner picks the process and parks the rest. The person who does the job today walks the map. Someone with authority names the exception owner. If you turn a model on this week, it only runs inside those rails. A mis-route is not a product bug. It is an unsigned exception.
Do not automate a second process until the first one has a named closer on every open item. That is how a team of twenty keeps the week small enough to finish.
Friday on the board
Nobody has a credible figure for how many extra seats it takes before a queue finally moves. Do not borrow a percentage. Count what you can see on your own board.
| Measure | Count |
|---|---|
| Open tickets with no named closer | |
| Live processes with a written map | |
| Exception owners named in the ticket |
If the first row is still a long list, you bought activity, not a refactor. The second row is the services work Moza is pointing at. The third row is what stays human when a rule is wrong. Three cells. No story about a new stack. Just whether the map, the rules, and the person exist.
Write the services ticket by Monday
By Monday you should have one process on paper, not another quote for seats. Do the sequence in order. Skip a step and you are back to buying a login.
- Pick one live process that already hurts: quotes, tickets, or invoices
- Sit with the person who does it and write the real path, including the side doors
- Put triage rules and a named exception owner in the same ticket
- Owner signs which process is in this week and which stays parked
- Leave the extra seat unbought until those lines exist
You can run this on the software you already pay for.
Sources
If one workflow is eating your week, tell me which one. I'll tell you if it's worth deploying — and if it isn't.
Message Mikko on LinkedIn