Procedure AI
How a verticalisation is built
There is always a project — even with whoever promises you a thousand ready-made agents. What changes is how much it costs, who can do it and what you hold when it is finished.
Six steps, and the first one already tells you whether the case holds
It is not a methodology with a name: it is the way we have worked for thirty years, with one new piece at the end.
- 1
We watch the process with the people who run it
Half a day with the people who do it every day, not with whoever documented it. The real process almost always has two or three exceptions the manual does not mention: those are the ones that decide whether automation works.
half a day - 2
We write the procedure
The checks to run before touching anything, the actions in order, what to do when a step fails, where approval is needed and whose. The work here is not technical: it is deciding where the machine stops.
days - 3
A technician reads it and approves it
This is what makes everything else safe: no script runs unless a human being has read it in full. The approval is recorded with a name and a date.
an hour - 4
Pilot on real cases
The procedure runs on a few cases and a few machines, with the outcome watched. If the success rate drops below the agreed threshold, it stops by itself instead of propagating the error.
a week - 5
We widen it
Time window, pilot group by percentage, maximum attempts: the same machinery we use to roll software out to hundreds of computers overnight.
at your pace - 6
It evolves
A reorganisation, a new business application, one more site: the procedure is updated. It is the part that never ends, and the reason we don't sell a closed package.
always
Who brings what
You
- The person who really knows the process, for half a day.
- Access to the systems involved, with a service account on limited permissions.
- The name of whoever approves, for every point where approval is needed.
Us
- The analysis, the writing of the procedure, the technical approval.
- The infrastructure: agent, queues, consent, privilege elevation, logging.
- The pilot, the running, and the evolution when the process changes.
What stays yours
- The written procedure, readable by any sysadmin.
- The record of who approved it and when.
- All of it even if one day you change supplier: it is not configuration inside somebody else's platform.
How long it takes, honestly. A procedure on a system that exposes an interface is written and tested in days. On a closed business application the long part is not the writing: it is working out which door you come in through, and sometimes that is half the project. Which of the two you are is clear in the first half hour, before you have spent anything.
“But the big platforms have a thousand ready-made agents”
True, and they handle the textbook case. Your HR department does not have the textbook case: it has its own approval rules, its own systems, exceptions layered over ten years. So the project arrives there too. The real question is not who avoids it: it is how much it costs, who can do it, and what you hold when it is finished.
| Big platforms | Procedure AI | |
|---|---|---|
| Who does it | a certified partner, at platform consultancy rates | us, together with whoever in the company knows the process |
| With what | the platform's internal tooling and its data model | ordinary scripts, in the language your sysadmin reads |
| What remains | configuration inside the platform | the written procedure, plus who approved it and when |
| If you change supplier | it stays there | it is yours and you take it with you |
| How you pay | per person working in the system | per workstation served, plus the procedures at a fixed price |
One detail that decides the timescales. People able to configure the big platforms are few and expensive; people who can write the script that resets a password or checks a folder are in almost every company. It means one more procedure does not become a negotiation: it becomes half a day.
Three things worth knowing first
The first procedure in a department costs more than the next ones
Not because of the code: because of the time it takes to understand the process as it really is. From the second one on, the same team knows your systems, who approves what and where the exceptions are — and it shows in the timescales.
Often the biggest gain comes before the automation
Writing a process so a machine can run it forces you to say what happens in every case: steps that are no longer needed and approvals nobody really looks at come to the surface. It regularly happens that the process comes out of the project shorter than it went in.
If it isn't worth it we say so in the first half hour
When a process does not meet the four criteria, automating it produces a system that fails silently. It happens rarely, and usually the answer is not “no”: it is “let’s fix the process first”.