Key takeaways
- The matter is the container every other part of the practice attaches to. Get it wrong and every later system sits on sand.
- The test of a working matter container: a competent stranger opens one matter and understands its complete state in ten minutes, without asking anyone.
- Most firms unknowingly run three competing matter definitions - one for billing, one for conflicts, one for how work is actually organised.
- Define the minimum required fields before choosing software. Software choice is downstream of the definition, not a substitute for it.
- Retrofit five recently closed matters into the new container before rolling it out. What breaks in the retrofit is what would have broken in production.
The real problem is definitional, not technological
Ask five people in a firm what a matter is and you will typically get three answers. Billing treats it as a unit of invoicing. Conflicts treats it as a unit of adverse-party checking. The lawyers treat it as 'the thing I am working on for this client', which may be one engagement, several engagements bundled, or a subset of one engagement that happens to be in front of them.
None of these are wrong in isolation. The problem is that they coexist without anyone noticing, so when the practice tries to attach anything to 'the matter' - a deadline, a document, an action, a responsible person - it attaches to a different thing depending on who is doing the attaching. This is the actual cause of the symptom every firm recognises: information about a matter existing in four places, none of them complete.
Buying a matter management system without resolving the definition simply gives you a fifth place. This is why so many firms have practice management software they describe, accurately, as 'a place we put things after the fact'.
The diagnostic question
If the handling lawyer went on leave tomorrow, could a colleague open the matter and know exactly what happens next, without a handover call? If the answer is no, the container is not real yet.
Step one: write the one-sentence definition
Complete this sentence for your practice: 'A matter is ______ - the unit we open, track, close, and bill against.' Then test it against the awkward cases, because the awkward cases are where the definition either holds or reveals itself as three definitions in a coat.
- A client with three unrelated engagements running simultaneously - three matters, or one?
- A single transaction that spawns a dispute - does the dispute open a new matter or continue the existing one?
- Advisory work with no defined endpoint - is that a matter, a retainer, or something else in your system?
- A matter that closes and reopens eight months later - same matter, or a new one linked to the old?
- Work done for an existing client at no charge - does it get a matter, and if not, where does its state live?
Step two: define the minimum required fields
Every matter must carry a small set of fields from the moment it opens, without exception. The discipline is in keeping this list short enough that it is always completed and long enough that the matter is legible. Optional fields are where matter management goes to die - if a field is optional, assume it will be empty on the matters where it would have mattered most.
| Field | Why it is mandatory | Common failure if omitted |
|---|---|---|
| Matter type | Determines which action library and price apply. | No way to select a playbook or quote a fee; every matter is bespoke by default. |
| Owner | One named person accountable for the matter's state. | Shared ownership becomes no ownership; state goes stale silently. |
| Current status | A stranger's fastest route to understanding where things stand. | State has to be reconstructed from email, which is the original problem. |
| Next action and next date | Converts the matter from a record into a live object. | Matters go quiet without anyone noticing until a client chases. |
| Parties and roles | Conflicts, correspondence, and context in one place. | Repeated re-derivation of who is who from documents. |
| Key dates | Deadlines belong to the matter, not to a personal calendar. | Deadline risk becomes person-dependent and invisible. |
| Fee basis and scope | Makes the commercial position legible mid-matter, not just at billing. | Scope disputes discovered at invoice time rather than at trigger time. |
Step three: retrofit five closed matters before you roll out
This is the step firms skip and then regret. Before the new container touches a live matter, take five recently closed matters and reconstruct them inside it. You are not doing data entry for its own sake; you are stress-testing the definition against reality that has already happened.
What you learn is specific and useful. You discover fields you thought were obvious that nobody can populate. You discover matter types that do not fit the list. You discover that two of the five were actually three matters bundled together, which tells you something important about your definition. Fixing those problems on closed matters costs an afternoon. Discovering them on live matters costs a quarter.
Step four: only now, choose software
With a written definition, a required-field list, and a retrofit behind you, software selection becomes a straightforward evaluation rather than a hopeful search for a system that will impose order on your behalf. You are looking for something that can hold your definition, not something that will supply one.
The practical criteria are narrower than most vendor comparisons suggest. Can it enforce your required fields at creation? Can deadlines attach to the matter rather than to a user? Can an action library or checklist attach to a matter type? Can you get your data out cleanly if you leave? Everything else is preference.
It is entirely legitimate for the answer to be a system you already own, configured properly for the first time. A large proportion of matter management failures are configuration failures rather than product failures, and replacing a badly configured system with a differently badly configured one is a well-travelled and expensive road.
- Enforces required fields at matter creation, not as an optional afterthought.
- Attaches deadlines to the matter, visible to anyone with access, not to an individual's calendar.
- Supports matter types with distinct checklists or action sequences attached.
- Exposes a clean export or API so the practice is not hostage to the vendor.
- Lets a stranger with access answer 'where does this stand' without opening email.
What a working matter container makes possible
Once the container is real, a series of things that previously required heroics become ordinary. Cover during absence stops requiring a handover call. Onboarding a new hire stops requiring a senior lawyer's narration. Client status updates stop being a research exercise.
More importantly for anything AI-related, the container is what makes automation addressable. An intake agent can populate a matter because there is a defined shape to populate. A drafting agent knows which matter its output belongs to. A monitoring agent can flag matters that have not moved because 'moved' is now a defined property rather than a feeling. None of that is possible against a folder structure and an inbox.
Frequently asked
What is the difference between matter management and practice management software?
Practice management is usually the broader suite - billing, accounting, documents, CRM. Matter management is specifically the container that holds a single piece of legal work and its complete state. Many firms own practice management software and still have no working matter management, because the software was adopted without a definition of what a matter is.
How do I know if my matter management is actually working?
Apply the ten-minute stranger test: a competent colleague who has never touched the matter opens it and understands its complete state - what it is, where it stands, what happens next, who owns it - within ten minutes and without asking anyone. If that test passes on a randomly selected matter on a random day, it works. If it passes only on matters you would choose to show someone, it does not.
Should a small law firm use a spreadsheet for matter management?
As a starting container, a well-designed spreadsheet with enforced columns is genuinely better than a badly configured practice management system, and it is a legitimate way to prove your definition before spending money. Its limits appear when you need deadline automation, document association at volume, or multiple concurrent editors - at which point you migrate a definition that already works, which is a much easier migration.
How many matter types should a practice have?
Few enough that each has a real action library behind it, which usually means three to eight for most independent practices. A long list of types with no distinct process attached to them is just a tagging scheme. If two types share the same sequence of actions and the same price, they are one type.
Do I need to migrate historical matters into a new system?
Generally no, beyond the five you retrofit as a stress test. Migrating years of historical matters is expensive, slow, and rarely changes anything operationally. Run new matters in the new container from a fixed date, keep the old store readable for reference, and let the historical set age out naturally.