One record per matter: the stage it’s in, who owns it now, what happens next. When it moves, the workflow drafts the update the client is owed and a person approves it. Internally we call it the case-state orchestrator.
A client matter, a shipment exception, a production task, or an account issue changes hands several times. Email says one thing, the tracker says another, and the next owner finds out when somebody asks. The cost sits in the chasing, the duplicate updates, and the transitions nobody noticed.
One record per matter, carrying the stage it’s in, who owns it right now, what has to happen next, and when it last moved. That record lives in a system you already have: the CRM, the practice or project tracker, or the job system. One of those is the source, named up front, and the workflow reads and writes that one. We are not adding a new place for your team to check.
This fits case work with a lifecycle you can draw: professional-services matters, logistics exceptions, B2B service delivery, ecommerce operations, SaaS account work, and media production. If your team can’t agree what each stage means or who owns it, that definition work comes first and it comes before any build.
For a datacenter fiber and cabling company we built the back office that does this: a CRM holding every lead, job, and follow-up in one system instead of an inbox and somebody’s memory, plus an owner’s portal he runs himself. See the client build.
A new matter, an event, a message, a date, or a system change starts the path.
The source record, the prior stage, ownership, required fields, and your transition rules get verified.
The next owner, the task, the status note, and the supporting context get assembled together.
A person decides exceptions, commitments, client messages, and any transition that costs something to undo.
The approved stage, owner, reason, and next action get recorded on the source record.
Conflicting state, missing data, and transitions your rules don’t allow stop with the context attached.
Drafting is rule-driven, and you write the rules. These are the four triggers we start from, and what a person writes instead. The four categories behind that split are the same on every workflow we build.
The matter moves to a new stage on the source record, so the workflow drafts the update that stage owes the client.
A committed date passes or gets changed, so it drafts the factual note saying what moved and what the record now says is next.
A document or message arrives that changes the answer, so it drafts a summary for the owner to read before anyone replies.
A matter sits past the quiet period your team agreed to, so it drafts the check-in instead of letting the silence run.
This workflow’s rule: scope, price, a legal position, and anything a client could act on financially get authored by a person rather than edited out of a draft. The workflow assembles the facts and stops there. It drafts the note that a committed date moved, because that is a fact on the record. A person writes what the slip means for the engagement.
People approve promises, scope changes, money decisions, and client-facing updates.
A person resolves conflicting information, unusual matters, and every override of a rule.
Your team owns what each stage means, which transitions are legal, who owns what, and when a matter is closed.
Current stages, legal transitions, owners, dependencies, and the places it usually breaks.
Representative matters, status histories, real handoff messages, and a handful of exceptions.
The systems that create events and hold state, plus one person on your side who can approve the rules.
We haven’t published a measured client result for this workflow. For a real one you need the same matter definitions before and after, enough history to see normal and unusual work, and every human override kept.
Matters per stage, handoff count, waiting time between stages, and minutes spent chasing status.
Wrong routes, illegal transitions, missing owners, reopened matters, and duplicate updates.
Approvals, overrides, exceptions, and blocked transitions, each with its reason attached.
These assumptions show the arithmetic. They are not a client result and not a delivery promise.
400 matters move each month. Triage, handoff, and status entry take 9 minutes each today. 75% follow a stable path that could remove 6 of those minutes.
400 × 9 minutes = 60 current hours. 400 × 75% × 6 minutes = 1,800 minutes, or 30 hours of modeled monthly capacity.
Exceptions and consequential moves still take people time, and reviewing drafted updates is part of that time. What it’s worth depends on your matter mix, your data quality, what the tools cost to run, and whether anyone uses the freed hours.
How this gets bought, scoped, and priced is on the services and pricing page. If you can name the transition that causes the most chasing, describe it in the free written assessment and we’ll reply by email with where we’d start.
Start with one matter type, its owners, and the handoff people keep chasing.