MAKIN 
Different vocabulary, identical bottleneck.
One tracks filings and the other tracks consignments, but in both the critical knowledge sits with two or three long-serving people. Nothing is written down because everyone competent already knows it, and that works right up until volume doubles or somebody resigns.
The exception is the process.
Both businesses described a standard workflow, then spent most of the day on exceptions: the client who files late, the load that gets split. Systems designed only for the standard case push all real work back into WhatsApp, which is where it was already living.
Write down the decision, not the task.
Documenting steps is easy and low value. What matters is the judgement: how you decide which filing gets priority, which load gets rerouted. Capture the rule and the system can hold it; leave it implicit and you have automated the easy half.
Start where the handover hurts.
In both cases the highest-value change was the same — making one person’s output legible to the next person without a phone call. That is unglamorous and it is what actually moves capacity.
The holiday test for hidden knowledge
First find out where the dependency sits. Imagine your most experienced person on leave during the busiest stretch of the month and ask what stops. In a CA firm it might be the senior who knows which clients will send everything at the last minute and which notices need a partner’s eye. In a logistics business it might be whoever knows which transporter will take a short-notice load and which customer accepts a split delivery. Ask the team:
- Who gets phoned when something unusual happens, and who does the phoning?
- Which requests go to a personal WhatsApp rather than a group or a system?
- Which decisions wait until a particular person is back?
- What does a new joiner get wrong in their first weeks?
- Which spreadsheet or file exists on only one laptop?
Keep a register of exceptions
If the exception is the process, the artefact to build before any flowchart is a register of exceptions. Go through recent WhatsApp threads, emails and call notes and list each case that left the standard route. For every entry, record what triggered it, who noticed, who decided and what they did.
Then group the entries. A CA firm’s register might cluster around missing documents, late client replies, purchase data that does not match what suppliers have filed, and departmental notices. A logistics operator’s might cluster around vehicle changes, split or merged loads, refused deliveries and paperwork that does not match the consignment. Each cluster becomes a path the new system handles on purpose, instead of a gap that sends people back to their phones.
A fixed shape for writing down a judgement
Capturing a decision is harder than capturing a task, because the person making it rarely thinks of it as a rule. Ask them to talk through the last few times they made the call. Filing priority might come out as: returns with a statutory due date come before advisory work, and within those, clients whose data is complete go first. Load rerouting might come out as: a delayed vehicle triggers a reroute only when the next drop has a committed delivery slot.
Neither rule is clever. Both can be followed by someone new, argued with in a review and later encoded, which is the point. Write every rule in the same shape, so the next person can apply it and a system can eventually hold it:
- Trigger: the event that makes a decision necessary
- Inputs: the facts the person checks before deciding
- Rule: the order of priority, stated plainly enough to disagree with
- Exceptions: when the rule is deliberately broken, and why
- Override: who may set the rule aside, and where that is recorded
- Escalation: what happens if nobody decides in time
What a handover record must carry
Making one person’s output legible to the next is mostly about what travels with the work. A message that says ‘done, see file’ will produce a phone call. A record that carries its own context makes the call unnecessary. Whether that record is a job card, a ticket or a row in a shared sheet matters less than whether it has the same fields every time, filled in before the work moves on:
- Status, in the words the next person uses
- What is waiting on whom, inside or outside the business
- The next action and when it is due
- A link to the supporting documents, not a description of where they might be
- Anything about this client or consignment that changes the normal route
Where Tally and GST automation fit
Some knowledge that lives in one head is really data that lives on one machine. If the books sit in a Tally copy on a single desktop, the person at that desk becomes the route for every question about them. Tally on Cloud Migration, which starts at ₹7,000, keeps the same Tally the team already knows but makes it reachable from anywhere and backed up nightly, so questions can go to the data instead of the person.
The other half is re-typing. When dispatch details are keyed again into invoices, and invoices keyed again into returns, each hop is a place where one person’s judgement quietly corrects errors nobody else sees. GST & E-Invoice Automation (from ₹30,000) generates GSTR filings, e-invoices and e-way bills from your own data, and Tally Integration & Automation (from ₹12,000) posts vouchers from your other systems into Tally. Automating either hop means writing those silent corrections down as rules anyone can read. The full set is on the Tally and GST automation page.
Mistakes that put the work back in someone’s head
Getting knowledge out of one head is ongoing work, and the effort can undo itself if the new route is harder than the old one. Watch for these patterns, because each can end with the real work drifting back into WhatsApp while the new system records only the easy half:
- Asking the expert to document everything in their spare time, so it never happens
- Building a system that cannot record an override, so overrides happen off the system
- Closing the group chat before the new route can carry what the chat carried
- Letting the exception register lapse once the first version is live
- Automating a rule nobody has agreed on, which freezes one person’s habit into software