Before automating anything, I write down who does the work, what comes in, what goes out, where it goes wrong, and what a mistake costs. A distributor's photo-based ordering shows why that order matters.
Anderson Silveira · October 2, 2026
A lubricant distributor sells to repair shops, fleets, gas stations, and factories. Orders came in the way they do at almost every small B2B operation: someone writes the order on paper, snaps a photo, and sends it on WhatsApp. On the other end, a person reads it, retypes everything, checks inventory from memory, and replies.
Faced with that, the first idea is to put an AI to work reading the photo. The idea is right. But it answers one part of the process, and the process has others.
Before deciding where the AI goes, I map the work as it’s done today. Five questions: who does it, what comes in, what goes out, where it goes wrong, and what a mistake costs. This article walks through the five on the photo order, then on two other processes.
The process, the way it was
- 01Write it down
The buyer writes the order on paper, in the words used at the counter.
- 02Snap a photo
Takes the picture and sends it on WhatsApp.
- 03Read and retype
On the other end, someone reads the handwriting and types it all over again.
- 04Check inventory
From memory. The balance lives in the head of whoever picks the order.
- 05Reply
By message, in the same conversation.
Who does it
The common mistake is mapping only the person who complains. In the photo order, the work passes through four points:
- The buyer, in the repair shop’s yard, phone in hand.
- The back office, which reads the photo and retypes it.
- The picker, who keeps the stock balance in their head.
- The customer company, which doesn’t show up in the flow and should own the order.
For the back office, every order is duplicated work. For the buyer, there’s no history: repeating last month’s order means digging up the old photo in the chat. For the customer company, the order belongs to whoever sent the message. If the buyer goes on vacation, the history goes with them.
That list changed the design. Instead of one screen trying to serve everyone, the system got two: the buyer’s portal, built for the phone, and the store’s dashboard, built for the computer at the counter.
What comes in
The input isn’t “a photo.” It’s a note with a vocabulary of its own.
The handwriting is rushed. “Balde” (bucket) means 20 liters. “Tb” means a drum. “Cx 24” is a case of 24 bottles. Viscosity can be written several different ways, and the quantity is sometimes a loose number at the end of the line.
Whoever retypes also interprets. That’s the most important finding from this question. The manual work wasn’t just typing. It was translating the counter’s language into the catalog’s.
An automation that only transcribes the photo removes the typing and leaves the hard part right where it was. That’s why the reading matches each line against the catalog and understands those abbreviations.
What goes out
The output of the manual process was a reply on WhatsApp. The output the operation needs is different: an order the store can pick, with a reference number, a stage, and a notification.
The rule that came out of this: the photo order ends exactly where the catalog order ends. Same reference number, same pickup rules, same notification. The only difference is the origin tag and the original photo attached, so the picker can check it.
If the automation creates an output different from the one the team already uses, it creates a second process to maintain.
Where it goes wrong
| Where | The error | Why it happens |
|---|---|---|
| Reading the note | Wrong product or packaging | Rushed handwriting, abbreviations, a loose quantity at the end of the line |
| Inventory | Balance that doesn’t add up | The number lives in the picker’s head, with no record of when it changed |
| History | Old order nobody can find | The photo is lost in the chat |
| Ownership | History that walks out the door | The order belongs to whoever sent the message, not the company |
Only the first row is an AI problem. The other three are record-keeping problems.
The stock balance stopped being a field someone edits. It became a ledger: every receipt, order deduction, adjustment, and reversal is recorded with date, quantity, balance after the movement, and who did it.
Without the map, I would have automated the reading and left three errors in place.
What a mistake costs
This question decides the AI’s role.
This distributor’s customers don’t buy a single bottle. They buy a load, and its weight is how they decide which vehicle to send. Getting the packaging wrong on a 200-liter drum is not a cheap mistake.
When the mistake is expensive, the machine doesn’t decide alone. The rule became: the AI proposes, a human confirms.
On the review screen, the photo sits at the top, with zoom, and each line shows what was written on paper next to what the system understood. A doubtful line appears as a suggestion, with an editable quantity and the options to accept, swap, or ignore. A line the system didn’t recognize is never guessed: it’s flagged in red, and the continue button only unlocks when no line is left undecided.
The cost of a mistake is what sets how much review an automation needs.
The same map on two other processes
A sales proposal built during the call. At a digital products platform, the salesperson worked out the savings math with the customer waiting. Who does it: each salesperson, their own way. What comes in: revenue, average ticket, active students, sales model. Where it goes wrong: in the calculation, in public. What it costs: one wrong number in front of the customer sinks the credibility of the entire proposal. The map separated what is a rule, what is a scenario, and what is a negotiation. The decision was to take the rule out of people’s heads and put it in a managed table. The sales calculator came out of that.
Collecting rent on small studio apartments. The landlord collected on the fly: a manual reminder from a personal WhatsApp, a Pix transfer checked against the bank statement, no history. In Kitnets, the decision I consider the most important was to make the automation optional. The landlord can simply record what was received, with partial payments, reversals, and receipts. Anyone who wants to automate issues Pix or boleto (a Brazilian bank slip) through the system, and the payment is matched automatically. Pausing a tenant’s billing remains a human decision.
In all three cases, the technology came after the map. And in none of them was the answer “automate everything.”
The map on one page
What I take away
The AI was the easiest part to decide and the one that most needed a limit. Reading the photo is the feature that gets attention. The value is in what surrounds it: showing the original text next to the suggestion, keeping a doubtful line from slipping through, and making the photo order end where the catalog order ends.
A note on the current state, because it’s part of the method. The photo order is built and tested, and it stayed switched off in production at the client’s request until the real reading is activated. Turning it on means flipping a switch, with no changes to the screens. The rest of the system, which came out of the other rows of the map, is already in use on the client’s server. The case shows the screens.
Checklist before automating
- Is every person the work passes through on the list?
- Was the input examined in the real material, with the abbreviations and the handwriting of the people who do it?
- Is the automation’s output the same one the team already uses to keep the work moving?
- Was each point of error sorted into reading problems and record-keeping problems?
- Was the cost of a mistake used to decide where a person confirms?
- Is it clear what stays manual, on purpose?
What does your team do by hand every day? Start with the five questions.