The short version
Before adding a single new tool or workflow, I run the same audit: list every repeating manual task in the GTM motion, estimate the weekly hours it costs, and score it on two axes: how rules-based it is (can a clear “if this, then that” describe it?) and how much judgment it genuinely requires.
Anything high on rules and low on judgment (data entry, routing, reminder follow-ups, basic enrichment) is an automation candidate on day one. Anything high on judgment (qualifying ambiguous accounts, handling objections, negotiating terms) stays human, possibly assisted by AI, but never fully automated. Skipping this audit is how teams end up automating the wrong things and wondering why results didn’t improve.
Capturing the task inventory honestly
Self-reported task lists miss most of the work, because people do not notice habits. Shadow each role for half a day, or ask reps to screen-record one typical Monday and narrate it. Log every step as a single line: trigger, action, tool, minutes. Typical finds include copying contacts between tabs, rewriting the same follow-up, and building a weekly report by hand.
Group the lines into tasks and estimate weekly frequency. Multiply minutes by frequency by number of people doing it. A three-minute task done 40 times a week by six reps is 12 hours, which dwarfs the one dramatic task that annoys everybody once a month. Rank by the total, not by the annoyance.
Scoring rules and judgment
Score rules-based from 1 to 5: could you write the logic as if-then statements without exceptions? Score judgment from 1 to 5: how often does the right answer depend on context you cannot encode? Lead routing by territory scores high on rules and low on judgment. Deciding whether to chase a stalled deal scores the reverse.
Use a simple priority formula: weekly hours multiplied by rules score, divided by judgment score. Build the top three. Tasks scoring high on both axes, like drafting a first email, get a different treatment: automate the draft, keep a person on the decision. That middle quadrant is where assisted workflows beat both full manual and full automation.
Proving payback after launch
Set a payback target before building: build hours plus monthly tool cost, divided by monthly hours saved at a loaded hourly rate. If the answer exceeds your threshold, such as four weeks, simplify the design or skip it. Record the baseline time per task now, because you cannot prove savings against a memory.
Review at day 30 with two numbers: hours actually saved and error rate. A workflow that saves time but introduces bad data is a net loss. Retire any automation nobody opens or relies on. Maintaining automations carries a cost, and a short list of reliable flows in n8n or HubSpot beats a sprawl of half-used ones.
Worked example (illustrative)
A hypothetical team of five reps audits its week and finds six repeating tasks. Only the top three by score are automated.
What changed: About 22 hours of team admin time per week was recovered, so the build paid back in under two weeks. The three skipped tasks were judgment-heavy and stayed human.
Do it: the steps
Tick them off as you go. Your progress stays on this device.
Traps to avoid
- ×
Starting with the tool you want to try. The audit decides the tool, not the other way round.
- ×
Automating a broken step. If the manual process produces inconsistent output, fix the definition first; otherwise you only generate inconsistency faster.
- ×
Estimating hours saved without measuring a baseline. Savings claims without before-and-after timing do not survive a budget review.
What to track
- Hours saved per week
- baseline minutes per task minus post-automation minutes, multiplied by weekly frequency
- Payback period
- build hours at loaded rate plus tool cost, divided by monthly savings; under four weeks is my target
- Automation error rate
- failed or corrected runs divided by total runs; keep below a few percent
Benchmarks are typical planning ranges, not guarantees. Calibrate to your own data.
Questions people ask
What if a task is rules-based but only happens rarely?
Leave it manual and document it as a checklist. Low-frequency tasks rarely repay build and maintenance time. A one-page playbook gives you consistency at near-zero cost, and you can revisit automation if the frequency grows.
Who should run the audit?
Someone close to the work but not owning it, such as RevOps or an external consultant, working with the reps. Managers tend to describe the process as designed, whereas the audit needs the process as performed. Share the results back with the team so they see their time being returned.