Services
Automating what your operation repeats
Verttical starts by measuring what a process costs to run today — in hours, in errors and in delay — and automates only the parts where that number justifies the build. Some processes come out of that measurement cheaper to leave alone, and saying so is part of the work.
Start a conversationStart with the cost of the process, not the tool
Most automation projects begin with a tool someone liked and then look for a process to point it at. That order is backwards, and it is why so many of them end as an unused licence.
The useful starting number is what one run of the process costs: how many people touch it, how long each touch takes, how often it has to be redone, and what the delay costs downstream. Once that number exists, the decision to build, integrate or leave alone stops being a matter of taste.
How automation gets scoped
Four steps. The first two produce a number, and the number decides whether the last two happen at all.
01
Map the process as it actually runs
Not the documented version — the real one, including the spreadsheet somebody keeps on the side and the message thread where exceptions get resolved. Those two are usually where the cost hides.
02
Put a cost on it
Volume times handling time, plus rework, plus what the delay costs the step after it. This is the number the whole decision rests on, and it is worth measuring rather than estimating.
03
Build or integrate
Custom software where the process is specific to how the operation works, integration of existing tools where it is not. Buying beats building more often than a software company likes to admit, and the measurement makes it obvious which case this is.
04
Verify against the original number
The same measurement, run again after the system is live. Automation that nobody measured afterwards has a habit of moving work rather than removing it.
Automate, integrate, or leave alone
A rough decision frame by how often a process runs and how much each run differs from the last. It is not a rule, but it puts most processes in the right bucket before any measurement.
| Frequency | Variability between runs | Usually the right answer |
|---|---|---|
| Daily or more | Low | Automate end to end |
| Daily or more | High | Automate the repeatable steps, keep judgement human |
| Weekly | Low | Integrate existing tools before building |
| Weekly | High | Measure first — often not worth a build |
| Monthly or less | Any | Leave alone, or fix the inputs instead |
What usually goes wrong
The most common failure is automating a broken process. A system that executes a bad workflow faster produces bad outcomes faster, and it also freezes the workflow: changing it now means changing software. Fixing the process first is cheaper every time.
The second is ignoring exceptions. A process that works for 80% of cases and has no path for the other 20% pushes those cases into email, where they become invisible. Exception handling is not a phase two; it is part of the definition of done.
The third is nobody owning the result. An automated process still needs a person who notices when it stops producing what it should, and that role has to exist before the system ships, not after the first incident.
Questions we get asked
- How do you decide which processes are worth automating?
- By measuring what one run costs today — people involved, handling time, rework rate and the cost of delay downstream — and comparing it against the cost of building. Processes that run monthly or less rarely justify a build, no matter how annoying they are.
- What is the difference between business process automation and custom software?
- Process automation removes manual steps from a workflow that already exists, often by connecting tools that are already in place. Custom software builds the system the workflow runs on. Many engagements need both, and the measurement in the first stage says which one leads.
- Should we fix the process before automating it?
- Yes. Automating a broken process makes it produce bad outcomes faster and freezes it in software, so changing it later becomes a development project. Fixing first is cheaper in every case we have seen.
- What happens to the exceptions a process cannot handle?
- They need an explicit path, decided before the system ships. A process automated for the common 80% with no route for the rest pushes those cases into email and messages, where they stop being visible to anyone measuring the result.
- Do you use off-the-shelf automation tools or build from scratch?
- Both, decided by whether the process is specific to the operation. Where an existing tool fits, integrating it beats building — a software company that never recommends buying is not measuring.
- How do you know the automation worked?
- By running the same cost measurement again once the system is live. Without that second measurement, automation frequently moves work to a different team rather than removing it, and nobody notices.
Start by measuring one process
Pick the process that costs the most to run today. The discovery stage puts a number on it, and the number decides the rest. We reply within one business day.
Start a conversationRelated services
- AI implementation
Agents, model integration and retrieval over your own data, with the evaluation and monitoring that keep them working after launch.
- Custom software development
Systems built for how one operation works, not configured from a template — including the cases where buying beats building.
Last reviewed 2026-08-14