Why redesign a whole process instead of automating tasks?
Because the hours rarely sit in one task. Take a scope document. Someone reads the enquiry, digs out a similar past job, copies its scope, edits the deliverables, checks the fee assumptions, sends it to a partner, waits, makes changes and issues it. Speed up any single step and the others still take as long. The waiting and the rework are where the day goes.
Automating one task inside that chain tends to move the bottleneck rather than remove it. Redesigning the whole job lets you ask a better question at each step: does this step need to exist at all, or is it only there because information was in the wrong place?
What does end to end actually mean?
It means the rebuild starts where the work starts and stops where the work leaves the firm. Using the scope document as the example:
| Step | Today | Rebuilt |
|---|---|---|
| Enquiry arrives | Read and summarised by hand | Key facts extracted into a structured record |
| Find a precedent | Search folders, ask colleagues | Closest past scopes surfaced from your own files |
| Draft the scope | Copy an old one and edit | Drafted from your current template and the record |
| Partner review | Emailed, waits in an inbox | Sent with changes highlighted, approved in one place |
| Issue | Reformatted and sent | Issued in house format once approved |
Every row still has a person accountable for it. What changes is how much of their time each row takes. The same thinking applies to scope documents, client onboarding, fee estimating and most of the jobs in the processes section.
How do you choose which process to redesign?
Three tests. The job must repeat often enough that saving time on it adds up across a year. It must follow a pattern, even an unwritten one, so it can be described as rules and templates. And it must currently depend on an expensive person doing assembly rather than judgement. A process that passes all three is worth rebuilding. A process that fails the second test, where every instance is genuinely different, usually is not.
The process priority scorer lets you compare candidates side by side, and how to choose a process to automate walks through the trade-offs.
What stays with your people?
Judgement, and sign-off. A redesigned process removes the gathering, copying, reformatting and chasing. It does not remove the decisions that make your firm worth instructing. Where a step needs professional judgement, the rebuilt process prepares everything the person needs to make it quickly, then waits for them. Anything that goes to a client is approved by a named person first.
This matters in regulated work. Whether your firm answers to the SRA, ICAEW, RICS or the FCA, the accountable person stays accountable. The process is designed so their review is easier to do properly, not so it can be skipped.
How is the redesign carried out?
Week one is spent with the people who run the job, recording what really happens rather than what the procedure manual says. That is where the redesign decisions are made: which steps go, which are merged, where the checks belong. Weeks two and three build the new version on your own documents and templates and run it on live work. Week four trains the team and switches the old way off. Thirty days of support follow while it settles. If it is not live in 30 days, you do not pay.
Does redesigning a process mean new software?
Usually not. The rebuilt process runs in the tools your team already uses, so nobody has a new platform to learn. That is a deliberate design constraint: a process that only works if everyone changes their habits and their software at once rarely survives its first busy month.