Questions10 / 10
What gets asked about hard processes.
If yours isn’t here, put it in the form — we answer in writing, within 24 hours, and without a discovery call first. Most questions get a straight yes or no rather than a proposal.
We already have Make and n8n. Why would we need you?
If your process fits them, keep them — we will tell you so, and we use those tools ourselves for the simple half of a landscape. We are for what happens after: millions of operations a day, a system with no connector in any marketplace, a case that has to wait four days for an approval and resume correctly, a decision an auditor will ask you to explain, and an exception rate that decides whether the automation replaces a team or just annoys it.
Another team said this process cannot be automated. Is that true?
Usually it means the process is expensive rather than impossible, and the previous team priced it as if the happy path were the whole job. That distinction is exactly what the pilot settles: two to four weeks on your real systems and real cases, a fixed fee, and a measured answer — straight-through rate, exception profile, throughput and cost per operation. Twelve years in, the question is almost never whether it can be done — it is what it costs to build and what it costs to keep running. You get both numbers in weeks rather than after a year.
Our core system is twenty years old and has no API.
That is the normal case, not the exception. In order of preference we use an internal or undocumented interface, direct database work under agreed constraints, file and protocol-level exchange, and controlled UI automation only where nothing else exists — with the fragile paths isolated behind an adapter so a system upgrade is a contained repair rather than a rebuild. We also tell you plainly when an integration is going to be brittle, and what it will cost to keep running.
What happens to the exceptions — and to the people?
Exceptions get a designed home: a taxonomy built from your real history, confidence thresholds that route uncertain cases to a person, and an operator console that makes reviewing them fast instead of a return to manual work. On people, we agree the target operating model with you before the build — how many roles the system carries, what the remaining human work is, and what happens to the team. That is your decision to make, and we would rather you make it openly at the start than discover it at go-live.
Can it really run millions of operations a day?
Yes, and the throughput number on its own is the easy part. What takes engineering is holding it at a cost per operation that keeps the automation worth having, while month-end peaks at eight times average load and one upstream system rate-limits you. Both figures are measured during the pilot and fixed in the SLA before the build starts.
We have an RPA farm nobody can maintain. Will you take it over?
Often, yes — a good share of our work starts as someone else's automation estate. We audit it for a fixed fee and come back with one of three answers: stabilise it, keep the process model and rebuild the execution layer, or replace. We will tell you which even when the honest answer is that the existing work is worth keeping and you need less from us than you thought.
How do we prove to an auditor what the system did?
Every case carries a per-step audit trail: the input it saw, the policy version in force, the decision and its reason, the actions taken in each target system, and who approved what. Policies are versioned like code, so “why was this decided that way in March” is a query rather than an investigation. Reconciliation against the target systems runs continuously, not at year-end.
How fast can we start?
A written feasibility assessment within three days of the brief, and the paid pilot itself usually starts within two weeks. Emergency work on a broken production automation is scheduled faster when we have the capacity — say so in the form and we will tell you honestly.