on repeatable work · worth roughly $107,250–$185,250 a year
You reported 39 hours a week across seven kinds of work, with reporting and status updates the largest single block at 10 hours, followed by customer follow-up at 8 and invoicing and billing prep at 6. At a spread-team rate of $55–$95 an hour over 50 weeks, that time is worth roughly $107,250 to $185,250 a year. That is an estimate built on self-reported hours and standard rates, not a measured cost and not a savings figure.
You want to grow without adding headcount and you named a number you could point to as the finish line. A goal with a measurable target attached is what makes it possible to tell later whether anything worked. That scores strong.
Named, not inspected. Whether the real logic lives in the systems you named or in a spreadsheet beside them is only visible by opening them.
Seven work types with hours attached, led by reporting at 10 hours a week, describe work that recurs on a rhythm rather than one-off jobs. That is the shape automation can hold. A questionnaire caps this at 4; a 5 would need documented procedures, and only a walkthrough can confirm those exist.
Structure can be described; values can’t. Whether the fields you rely on are actually populated is a question for the tables, not a questionnaire.
Naming a system is not testing it. Credentials, write scopes, and API availability have to be tested one at a time.
You tried something before and it didn't stick, and the work is spread across everyone rather than owned by anyone. A tool that worked and lapsed anyway is a specific finding, not a neutral one: the constraint is attention, not capability. Anything built here has to run without daily human upkeep, or it will lapse the same way.
Single points of failure — the one person qualified to do a thing, with no backup — are invisible from any set of taps.
It is the largest reported block at 10 hours a week, and it is downstream work — it pulls from systems that already hold the data rather than creating anything new. That makes it the least disruptive place to prove something can run unattended. Given the lapsed attempt, the test that matters is not whether it works in week one but whether it still runs in week eight with nobody tending it. Pick the single recurring report that costs the most time and build that one first.
You indicated systems of record across CRM, accounting, job management, scheduling, payroll, and inventory, but no products were named. Without names there is nothing to sort; every one of them is unknown until tested.
Four areas stay unscored on purpose, because a questionnaire cannot see them. Systems of record were named by category but not inspected, so whether the real logic lives in those systems or in a spreadsheet beside them is unknown — and you already reported that your systems disagree with each other, which makes that question sharper. Data readiness is unknown because structure can be described and values cannot; you also reported no way to measure cycle time today. Stack access is unknown because credentials, write scopes, and API availability have to be tested one at a time. Risk and oversight is unknown because single points of failure — the one person qualified to do a thing, with no backup — do not show up in any set of answers.
A scoping conversation is the next step. The goal is defined, the work is repeatable, and there is a clear first target in reporting. What the conversation has to settle is which systems those six categories actually contain, which of them will grant write access, and how the build stays running without someone remembering to check it. That last point is the one your history says to take seriously. None of the four unscored areas were tested here, and any plan has to be revised once they are.
Route · Build