Claude Partner Network · Process Redesign
Two weeks on one process. The deliverable is a redesign you can act on whether or not you build anything afterwards.
Pexon redesigns a business process before automating it. Most AI business process automation fails because the rules were never written down, so the model inherits exceptions nobody can state. We document the process, remove the steps that exist only to fix earlier steps, then automate what survives.
The method
The test
What you find
01
Steps that produce the thing the process exists to produce. A supplier invoice gets matched to a purchase order; a customer question gets an answer. These are usually a minority of the steps and almost always the fastest part of the chain.
In the redesign Kept, and this is where automation is worth buying. Everything else on this list is noise you are considering paying to preserve.
02
Steps that exist to fix an earlier step. A second person re-keys a field because the first system truncates it; a reconciliation runs because two systems disagree by design. Nobody designed these in. They accreted, one incident at a time.
In the redesign Deleted by fixing the cause, not automated. Automating a correction step is paying to make a workaround permanent, and it is the single most common way an automation project produces no gain.
03
Steps that are not work at all: a queue, an approval sitting in somebody's inbox, a batch that runs overnight. In a long-running process these frequently account for most of the elapsed time while accounting for almost none of the effort.
In the redesign Attacked first, and usually without any AI. An approval threshold raised or a batch moved to an event is often a bigger win than anything a model does, and it is cheaper.
04
Steps where somebody decides something that is not written down anywhere: whether this exception is acceptable, whether this customer gets the discount, whether this deviation needs escalating. The rule exists, in somebody's head.
In the redesign Written down, which is the hardest and most valuable part of the engagement. Once stated, some become rules a system applies and the rest stay human — but now they stay human deliberately.
On numbers
We do not publish a percentage here, and the omission is deliberate. Every improvement figure on this subject is quoted against somebody else's baseline, which makes it worthless for predicting yours. The reduction you get is measured against the number taken in step six of the method above, in your first two weeks, from your own data. Anyone quoting you a percentage before they have measured that is quoting a brochure.
How we price the two weeksWhen we are the wrong choice
If the process is already documented and the rules are already written, skip this and go straight to the build; you would be paying us to read something you have. If the real problem is that two systems disagree and somebody reconciles them by hand every week, that is an integration project and a model is the wrong tool — the honest answer is usually cheaper and less interesting than the one you came for. And if the process spans three departments that do not currently agree it is one process, the redesign will surface that disagreement in week one and then stall, because the blocker is organisational and no engagement fixes it from outside.
Pexon Group is a Certified partner in Anthropic's Claude Partner Network (Services Track), granted on 1 October 2026. This site is published by PEXON ROMANIA S.R.L., a separate legal entity in the same group, and the party you contract with here.
Because a large share of the steps in a long-running manual process exist to correct an earlier step, and those are the ones that cannot be automated usefully. Automating the whole chain reproduces the correction steps, which means you have paid to make a workaround permanent and faster. The redesign is what tells you which steps were the work and which were the scar tissue.
By watching it and by reading its output, in that order. Interviews give you the official version, which is usually the version from before the last two exceptions were added. The artefacts give you the real one: the tickets, the spreadsheets people keep on the side, the email threads where the decision actually happened. Where the two disagree, the artefacts are right.
It is one of the two places we see the biggest change, and the honest version is unglamorous. The gain is rarely in generating code faster; it is in review, in the archaeology of why a module does what it does, and in the tests nobody wrote. Those are reading problems rather than writing problems, which is what the model is actually better at than a person on a deadline.
Anything where being confidently wrong is expensive and the error would not be visible downstream. The design rule we use is that a step may be automated when a wrong output is either caught by a later step or cheap to reverse. Steps that are neither keep a human, and the useful move is usually to make them smaller rather than to remove them.
The documented redesign of one process is the two-week engagement at €4,900, net of VAT, and it ends with a process you can act on whether or not you build anything. Automating what survives is the pilot engagement from €15,000 and is a separate decision made after you have read the redesign.
That happens, and it is the best outcome available. Some processes exist because a system could not do something in 2014 and now can, and the right answer is a configuration change rather than an agent. We will say so, the engagement ends early, and you have spent two weeks to avoid building something that should not exist.
Next step
Thirty minutes with the architect who would run the engagement. Bring the process everyone complains about — and if the redesign turns out to be a configuration change rather than a build, we will tell you that and the €4,900 has still paid for itself.