You don't need a consultant to tell you whether an automation project is worth doing. You need twenty minutes, a legal pad, and a willingness to write down numbers you'd rather estimate.
Here's the exact worksheet we use internally. Run it yourself. If it doesn't clear, don't call us — don't call anyone. That's the whole point.
Step 1: Pick one workflow. Be specific.
Not "our operations." Not "the leasing process." One workflow, with a beginning and an end, that a specific person does on a repeating schedule.
Assembling the closing packet. Coding vendor invoices. Re-entering property data into the third-party listing sites. Building the Monday production report.
If you can't name the person who does it and the trigger that starts it, you haven't picked a workflow. You've picked a department, and departments cannot be automated.
Step 2: Count the volume. Actually count.
How many times does this happen per month? Not your guess — go look. Pull the count from your system, or have someone tally it for two weeks and double it.
This step kills more projects than any other, and it kills them for free. The thing you feel like you do constantly may turn out to happen eleven times a month. Better to learn that now, on a legal pad, than in month three of a build.
Step 3: Time it. Then add 30%.
How long does one instance actually take, from the moment the person starts to the moment it's fully done and out of their head?
Sit with them and time three of them. Do not accept a self-report on the first pass — people systematically underestimate recurring tasks, because they're measuring the part they're aware of and forgetting the switching cost, the interruption, the second look, and the ten minutes they spent finding the file.
Take the observed average and add 30% for the mess you didn't see. That's your true per-instance time.
Step 4: Get the loaded rate right.
Not their salary. Their fully burdened annual cost — salary, payroll taxes, benefits, software seats, the space they occupy — divided by about 2,000 working hours.
A coordinator at a $58,000 salary is probably costing you $72,000 all-in, which is $36 an hour. A licensed professional at $110,000 is closer to $135,000 all-in, or $67 an hour. Your own time, if you're the owner, is worth whatever your business generates per hour of your attention, and you should be honest about how high that number is, because you are almost certainly the most expensive person doing manual work in your company.
Step 5: Multiply. That's your labor number.
Instances per month × minutes each ÷ 60 × loaded rate × 12 = annual labor cost.
Write it down. This is the floor, not the answer.
Step 6: Add the consequence cost.
This is where the real money usually is, and it's the step everyone skips because it requires thinking rather than arithmetic.
How often does this workflow go wrong? What happened the last three times? Write down the actual costs: the late fee, the re-do, the client who was unhappy, the deal that slipped, the discount you gave to make it right, the hours somebody spent fixing it.
Then ask: what is the delay costing? If this workflow is a bottleneck, and things wait on it, what's the value of them not waiting? Faster invoicing means faster cash. Faster lead response means more deals. Faster diligence means more parcels reviewed.
Consequence cost is frequently larger than labor cost. On invoice coding, on lead response, on anything with a deadline — it's not close.
Labor cost + consequence cost = the annual value of the problem. Call it P.
Step 7: Estimate the build honestly.
Get a real quote, or estimate high. Then add the ongoing cost — the API usage, the software, the maintenance, the internal time to supervise it. Assume 15–25% of the build cost annually as run cost, and if a vendor tells you it's zero, they are not being straight with you.
Build cost + first-year run cost = C.
Step 8: The ratio.
P ÷ C.
If it's above 2, build it. You'll clear a strong return in year one and the second year is nearly pure return, because the build cost doesn't repeat.
If it's between 1 and 2, be careful. It may still be right if the workflow is growing, or if the consequence costs are understated (they usually are), or if it's a foundation for the next three projects. But go in with your eyes open, and don't let anyone talk you into optimism.
If it's below 1, don't build it. Not this year, not with a smaller scope, not "just to get started." Go find a workflow with better economics, because there is one, and you'll find it faster than you'll make this one work.
The discount nobody applies
One honest adjustment before you commit: you will not recover 100% of the labor.
Some of the reclaimed time refills with other work. Some tasks retain a human review step. Some exceptions still land on someone's desk. Assume you capture 60–75% of the labor number, model it that way, and see if the ratio still clears.
If it clears at 65% recovery, it's a real project. If it only clears at 100% recovery, it was never a project — it was a hope.
Why we're giving this away
Because the reason most owners get burned on automation isn't that they were sold something bad. It's that they were sold something unmeasured, and they had no framework to push back with.
Now you do. Run it on your top three workflows this week. Two will fail the test, which will save you real money and a year of frustration.
And the one that passes — that one is worth building, and you'll know exactly why, and you'll know exactly what to expect when it ships. That's a much better position to negotiate from than enthusiasm.