Loading…
Loading…
Deciding what to automate first, what to leave alone, and what each option costs to build and to run — before anyone writes code.
Most of these projects fail on the choice of job rather than the technology. Automate a task that runs twice a month, or one where nobody can say what the right answer looks like, and the budget is gone before a line of code is written.
So I start with the people doing the work — whoever answers the phone, whoever keys in the paperwork — and come back with an ordered list of what is worth automating, what each one costs to build and to run, and what to leave alone.
Book a callWhere your documents live, what shape they arrive in, and whether they are consistent enough to build on. Sometimes the answer is not yet, and the cheaper fix is a different one.
The jobs worth automating, in the order they are worth doing, with the reason each one sits where it does. Short enough to read in one sitting.
Going through your week for the tasks that repeat, take someone off the tools, and fail in a way you can point at.
Which calls the system makes by itself, which ones wait for a person, and what gets written down. In plain language, so it survives someone leaving.
Reading the pricing pages and the contracts so you do not end up on a per-seat bill that grows faster than the crew does.
The dispatcher who has done it the same way for years is who this has to work for. If it does not fit their morning, it sits unopened.
If nothing in your operation repeats often enough to be worth building for, I say so and the work stops there. That answer costs you a few days rather than a quarter.
Whoever sits with your dispatcher is who writes the code and who picks up the phone when it breaks. There is no delivery team to be handed to.
What you run now keeps running while the new thing runs beside it. During that window a wrong answer costs nothing, and the disagreements are the useful part.
APIs change and document formats drift, so an automation is not finished when it ships. You get the monthly number before you commit to the build, not after.
A morning with whoever answers the phone and whoever types the paperwork in. Not a workshop.
The tasks that repeat often enough, and fail clearly enough, to be worth building for.
What each one takes to build, and what it costs to keep running once it is live.
You pick one to build, or none. Either way the shortlist and the costing are yours.
Tell me which part of the week goes wrong most often, and I will tell you whether it is worth building for.
Book a call