MAKIN 
Count the work before changing it.
For one week, everyone logs tasks taking over ten minutes, with a rough duration and which tools were involved. It feels bureaucratic and it is the only reliable way to find the truth. Memory systematically underweights the small repeated task and overweights the dramatic one.
Sort by frequency times friction.
A two-hour monthly task is worth less than a six-minute task performed forty times a week. Multiply duration by frequency and the list reorders itself, usually away from whatever everyone assumed was the problem.
Look for the tool boundaries.
Highlight every task that names two systems. Those lines are where automation pays, because the work is pure translation with no judgement in it. Tasks inside a single tool are usually better fixed by configuration than by code.
Automate one, then re-audit.
Removing the top item changes the ranking, and often reveals that the second item only existed to support the first. Re-running the count after each change stops you building automation for work that no longer needs doing.
The worksheet, column by column
The worksheet is a single shared sheet with one row per task, filled in by the person who does the work. Keep it to the eight columns below. Every extra column is another reason to stop logging halfway through the week, and an audit people abandon tells you nothing.
At the end, add one calculated column: times multiplied by minutes, which gives each row’s weekly load. Sort by it only once the week has closed, so nobody adjusts their logging to push a favourite task up or down the list. The columns people fill in are these.
- Task: a verb and an object, such as “copy IndiaMART enquiry into the lead sheet”, not a category like “sales admin”.
- Owner: who did it, so you can check the row with them later.
- Trigger: what started it — an email, a WhatsApp message, a form, a time of day, a colleague asking.
- Times this week: a tally kept as it happens, not an estimate.
- Minutes each: a rough duration for a single occurrence.
- Systems touched: every tool or document involved, in order, from where the data arrives to where it ends up.
- Judgement: none, some or a lot. Could a new joiner do it correctly from written rules?
- Cost of a mistake: what goes wrong downstream if this is done badly, in plain words.
Running the logging week
Pick an ordinary week. Month-end close, a festival rush or a trade-fair week inflates some tasks and hides others, and the list will describe an exception rather than your business. Tell people the log is about the work, not about them; if staff suspect a productivity review, the sheet tends to fill up with whatever looks busiest.
- Log at the end of each day, never from memory on Friday.
- Log a short task that repeats all day as one row with a running tally; together its occurrences can clear the ten-minute bar that no single one would.
- Log the exceptions too: the order that needed a phone call, the invoice that did not match.
- Keep the sheet somewhere people already work, such as Google Sheets, rather than in a new tool.
Reading the top of the list
Weekly load shows where the time goes. It does not show what is safe to automate. Rows heavy with judgement are not dead ends, but they usually suit assistance rather than automation: the system prepares a draft, a match or a suggestion, and a person approves it. Mark those separately so they do not crowd out the clean candidates.
For the remaining rows, read the top of the list against the judgement and cost-of-mistake columns and the tool boundaries you highlighted. The strongest first candidates share four traits, and a row that has all four is usually the right one to start with.
- A high weekly load built from many repeats rather than a few long sessions.
- A boundary between two systems, with a person acting as the bridge.
- No judgement, or judgement that can be written down as a rule.
- A predictable input: the same form, the same email layout, the same PDF template.
What not to automate first
Some rows score well and still make poor first projects. The usual pattern is automating a symptom: work that exists only because something upstream is broken or undocumented. Fix or write down the upstream cause first, then read the row again before deciding anything.
- Tasks whose rules live in one person’s head and change when they are on leave.
- Tasks with no clear owner, because nobody will notice when the automation stops.
- Anything that moves money without a human approval step.
- Workarounds for a report or export that could simply be configured properly.
Turning the top row into a brief
The chosen row becomes a one-page brief before anything is built. Write the trigger, the input and its format, each system the data passes through, the output, and every exception logged during the week. Then name who is told when the automation meets a case it cannot handle; a fallback designed up front is simpler than one added after something goes wrong.
The brief also shows what kind of help fits. IndiaMART enquiries retyped into a sheet match the IndiaMART Lead Autopilot from ₹10,000; PDFs retyped into a system match Document & Data-Entry Automation from ₹16,000; one painful process spread across several tools fits a Workflow Automation Sprint from ₹14,000, delivered in up to 7 days. The full set is on the automation packages and prices page.
The re-audit, and when to stop
Once the first automation has settled, run the same log for another week and compare the sheets row by row. The automated task should be gone. Look for what moved with it: checks people added because they do not yet trust the output, and rows further down that shrank because they only existed to feed the first.
Stop when the top of the list is mostly judgement, exceptions or rare tasks. That remaining work is what you employ people for, and the audit has done its job. Keep the sheet, though, and re-run it whenever the business adds a channel or a tool, because each one creates new boundaries.