A phased approach, with proof up front.
Every project runs in four phases, with a working prototype on your own documents before anything is built further. That puts the feasibility question at the front of the process instead of the end.
Four phases, in this order
-
01
Analysis
I walk through your process as it actually runs today — not as it is written down. Who does what, in which order, and where does it regularly get stuck? The real bottleneck often turns out to sit somewhere other than expected.
- A conversation at your pace, at your office or remotely
- We work out together what each task costs per month
- You get on paper what can be automated — and what cannot
- Including what is technically not possible
-
02
Prototype
We pick one opportunity and I build a working part of it — on your own documents, with your own messy edge cases. Not on a tidy demo set, where everything works.
- You supply a representative set of documents or data
- I build the part where the risk sits, not the easy part
- You see with your own eyes what comes out, mistakes included
- If it disappoints, it stops here — without a big loss
-
03
Automate
The prototype becomes a workflow that runs every day: connected to your packages, scheduled at the right moment, with the checkpoints exactly where you want them.
- Integration with your accounting package or document platform
- You decide where the workflow has to stop and put something to you
- Alerts on errors, so that silence means it ran well
- Your staff get an explanation of what they will see
-
04
Optimise
Every exception you correct is information. A supplier whose invoice is always read wrongly, a payment that never matches automatically — those are not faults but clues.
- I watch which cases ask for your intervention too often
- The workflow is adjusted so that group gets smaller
- If your package or process changes, the workflow follows
- Once there is nothing left to gain, we leave it be
No account manager, straight to the developer
The person who has the conversation with you is the person who builds it. That does not just remove a link in the communication — it also means that during that first conversation, someone who knows what is technically feasible is already thinking along.
From the first conversation until after going live. You never have to explain again what you already told someone.
Some integrations do not exist, some documents are too messy. You would rather hear that beforehand.
Everything runs on secure European servers, or inside your own environment if you prefer.
The workflow hangs off your existing packages. If the collaboration ends, your bookkeeping stays where it was.
About the process
How long before a workflow runs?
For a defined workflow, typically a few weeks between the first conversation and going live — of which the prototype is usually ready within one to two weeks. Integrations with slow or undocumented systems take longer; I would rather say so beforehand than afterwards.
What does it cost?
That depends on the scope of the workflow and how accessible your systems are. After the free scan you get a concrete proposal with a fixed price per workflow, so you know in advance where you stand.
How much of my time does it cost?
A few hours spread over the project: the conversation, some sample documents, and feedback on the prototype. Not days.
What happens once the workflow is running?
I keep following the exceptions and adjust the workflow where it asks for your intervention too often. If your package or process changes, the workflow follows.
Who do I work with?
With me, from the first conversation until after going live. No account manager, no project lead — the person who has the conversation is the person who builds it.
Where does your time actually go?
We walk through your processes together, at your pace. You will know what can be automated in your firm, what it would save, and what is better left as it is. No strings attached.