If you look at the diagram I published at the start of this series, there's a box on the left that isn't technology at all.
Your triage and risk rules. Your playbooks by matter type. Your precedents and knowledge management. Your delegated authority. Your house style.
Every other box can be bought, configured or implemented. This one has to come from you - and in most legal teams, it exists only in the heads of a handful of experienced people.
No platform will generate these for you, and nobody can sell them to you off the shelf, because the substance has to come from your team.
That's the part I'd argue matters most, and it's the part most consistently overlooked.
Why it gets skipped
Partly because it's not urgent. Nothing breaks today because the triage rules aren't written down.
Partly because it feels like documentation rather than work, and documentation is what you do when there's spare time, which there isn't.
And partly because the people who could write it are the people whose judgement is currently substituting for it. They can make the call in ten seconds. Writing down how they make it takes considerably longer, and produces something that feels less nuanced than what they do instinctively.
So it doesn't get written, and the team keeps running on a set of unwritten conventions that mostly work - until someone leaves, or the team grows, or the business asks why two similar requests got two different answers.
What each of these actually is
- Triage and risk rules. What the business can self-serve. What comes to legal. What escalates, and to whom. This is the highest-value one because it determines where the team's time goes and because it's what the business most needs to understand. If the business can't predict what legal will want to see, it either over-refers or goes around you.
- Playbooks by matter type. How each type of matter is actually run. The standard workflow, acceptable fallback positions, who approves what. This is what makes a matter reproducible rather than dependent on who picks it up.
- Precedents and knowledge management. Which template for which situation, which optional clauses in which circumstances, and - the part almost everyone is missing - what advice we've already given or received on this issue. Most in-house teams re-research things they've already resolved, because the prior advice is in someone's sent items.
- Delegated authority. Who signs at what value, with which sign-offs. Usually this exists somewhere in a policy document that hasn't been read since it was written, or is implemented manually and inconsistently. It needs to be operational, not archival.
- House style. How advice is structured, how documents are meant to look. This sounds trivial. It isn't. It's what makes output from four different lawyers look like output from one team, and it's what makes automation and AI-drafted material recognisable as yours. It also stops some of the most expensive people in the organisation from spending hours fixing document formatting.
Why this is worth more now than it was two years ago
Here's why this is more than just a nice-to-have.
Written rules used to be for training new joiners and settling arguments. Now they're the input to everything else you're building.
An intake form can't triage without triage rules. A workflow can't route for approval without delegated authority. A template can't offer the right optional clauses without a view on which clauses suit which situation. And an AI agent that's meant to help the business self-serve can only be as good as the guidance it's been given - an agent trained on nothing will confidently invent your policy.
The rules are what turn a set of Microsoft 365 capabilities into your legal operating system rather than a generic one. They're the difference between a system that works the way your team works and a system your team has to work around.
And they solve the key-person problem
In most in-house teams, a significant amount of institutional knowledge sits with two or three people. If one of them leaves, a meaningful part of how the team operates leaves with them - not the legal knowledge, which is replaceable, but the accumulated judgement about how this organisation does things, which isn't.
Writing the rules down converts that from personal knowledge into an organisational asset. It also frees those people from having to be consulted on every routine question.
How to do it without stopping everything
Don't write a manual. Manuals don't get read, don't get updated, and take months.
- Start with triage. What the business self-serves, what comes to legal, what escalates. This is the rule with the highest immediate value and should be the shortest to write. Start with the most common situations – you can adapt based on actual experience and need.
- Then do one playbook, for your highest-volume matter type. The same matter type you built the intake form for. Write down how that matter is actually run today - not how it should ideally be run. You can improve it once it's visible.
- Keep it where the work is. In SharePoint, not in a system nobody opens. If it's not where people already are, they won't use it.
- Set a review date. These rules are only useful while they're current. A rule that's two years out of date is worse than no rule, because someone will follow it.
The order matters
If you're building the operating system I've described in this series, the temptation is to do the technology first - intake, matter sites, the Power App - and write the rules afterwards, once you can see how it all works.
I'd do at least some of it in parallel. The rules determine what the technology should do and help you choose the right technology and configure it properly. Build the intake form before you've decided your triage rules, and you'll build the wrong form, then have to unpick it, perhaps using another form technology that works how you need.
You don't need all of the rules to start. But you need the triage rules alongside intake, and the playbook before you automate the workflow. That sequencing is worth getting right.
If you'd like to talk through what this would look like for your team, I'm always happy to talk it through.
This post is part of a series on building an in-house legal operating system on the Microsoft 365 you already have. You can see the earlier posts here:
You probably don't need a whole new legal operations platform
One front door: legal intake and the matter register
Maximising AI Potential: The Importance of Information Architecture
