A few years ago, I sat in a meeting where legal was trying to explain, again, why a contract review that should have taken three days had taken three weeks. Nobody could point to where it had stalled. It wasn’t sitting on any one desk long enough to look like a bottleneck. Still, it had passed through six inboxes, two WhatsApp threads, and one printed copy that someone had annotated by hand and then lost. It would be a stretch to say somebody was being lazy. There was simply no system holding the work.
At the same time, on the other side of our building, our IT service desk was closing tickets within hours, with service level agreements (SLAs), escalation paths, and a knowledge base with answers to almost all concerns. If you had read Charles Dickens’ masterpiece, our company could be seen as A Tale of Two Cities: the same company, two completely different experiences of getting help.
This gap is what pushed us to extend our IT service management (ITSM) practice, built on internal deployment of Jira Service Management and Confluence, into legal and operations. It’s Enterprise Service Management (ESM) in its most literal sense: not a rebrand of IT’s ITSM toolset, but a genuine transplant of IT’s discipline into departments that have never had it. This cross-departmental approach directly mirrors the ITIL 4 principle of value co-creation, demonstrating that service management isn’t just an IT asset but an organizational capability.
Here’s how we executed the transition, including where it nearly went wrong.
Step 1: Stop Calling It a Ticketing System
The single biggest adoption killer is language. Lawyers and operations staff do not think of themselves as ticket-raisers, and if you introduce a queue by saying “now you’ll log a ticket for that,” you might have to start from square one again the next time.
Reframe it as a service catalog, a clear list of services your legal team already provides. The list of things people already ask legal for, every week, informally: NDA review, contract drafting, employment agreement generation, IP assignment checks, and policy sign-off. And even if it is operations, it is the same: onboarding a new hire, provisioning a vendor, issuing hardware, and renewing a license. None of this is new work. You’re not asking anyone to do anything they don’t already do.
Before building a single workflow, we mapped every recurring legal and ops request from the previous quarter’s email traffic. That list became our service catalog, almost word-for-word.
Step 2: Build the Legal Request Taxonomy First
It’s tempting to open your IT service desk software and start building forms immediately. Resist it. The taxonomy work, deciding what counts as a distinct request type, what information each one needs up front, and who owns it, is the part that determines whether the system feels helpful or a whole new headache.
For a legal function, a workable starting taxonomy usually splits into three distinct families:
- Drafting Requests – creating new contracts, amendments, NDAs, or employment paperwork.
- Review and Advisory – handling vendor-terms reviews, policy questions, and risk flags.
- Compliance and Administration – managing signature routing, statutory filings, and renewal tracking.
Each family needs its own intake form. A drafting request should ask for counterparty details, jurisdiction, commercial terms, and urgency up front, the exact questions a lawyer would ask anyway on a discovery call. If the form does that, the lawyer would first “thank their stars” and then start with a clear brief instead of a blank inbox message that says “Can you look at this?”
Operations taxonomy tends to split around people, assets, and vendors. While onboarding/offboarding, hardware issuance, and third-party engagement setup are the three that generate the most volume in most mid-sized companies.
Step 3: Set SLAs That Reflect What Matters to Legal
This is the most critical point. Someone copies IT’s SLA tiers: four hours for urgent, one business day for standard, straight across. Well, bad news: Legal will quietly stop using the system within a month because it can’t hit those numbers on a market-standard NDA, let alone a negotiated Master Services Agreement (MSA).
Legal and ops SLAs need to be built from actual historical turnarounds. We pulled twelve weeks of contract-drafting turnaround data before setting a single target. A first-draft NDA landed comfortably inside two business days; a commission or reseller agreement with schedules and exhibits needed five. That honest framing cut average NDA turnaround from nine days to under three once the system went live. Because the numbers reflected reality, the lawyers trusted them. If you really want the team to use the SLA, they have to believe it reflects the trajectory of their work.
Crucially, configure a distinct “clock paused” status for when the ball is in the requester’s court, such as waiting for counterparty comments, a signature, or missing commercial terms. Without it, your turnaround metrics quietly blame legal for delays they didn’t cause, which is the fastest way to permanently lose their buy-in.
Step 4: Automate the Routing, Not the Judgment
ITSM’s real value in legal and ops isn’t speed on the drafting itself; that still requires human judgment and expertise. The value lies in removing the invisible administrative tax: who approves this, who needs to be copied, where the signed version gets filed, and what happens automatically once a contract is executed.
Workflow automation works best with the boring, repeatable parts: routing a vendor contract above a certain value automatically to a second executive approver, auto-generating a renewal reminder 90 days before a contract’s term ends, or triggering an IT asset ticket automatically the moment an offboarding request is approved, so access revocation isn’t a manual follow-up someone forgets on a Friday afternoon.
Resist the temptation to automate approval decisions themselves. Just one wrong approval can lead to a nightmare compliance issue. Keep the judgment human.
Step 5: Turn Your Templates Into an Actual Knowledge Base
Every legal team has a folder somewhere, usually on a shared drive, usually with three versions of the same NDA template, only one of which is current; that is an ungoverned knowledge repository. Extending ITSM here means doing what IT already does with its knowledge articles: enforcing version control, clear ownership, and strict review dates.
We moved our contract templates, clause libraries, and standard playbooks into Confluence. We linked them directly from the relevant request type in the service catalog. When an internal stakeholder raises a drafting request, the current template is closer than a Slack message asking “Does anyone have the latest NDA?”
We locked template edits to the legal team while making them read-only for everyone else, preventing accidental overwrites while keeping everyone on the current version. Each page carries an owner and a next-review date, applying the same discipline IT brings to an infrastructure runbook.
Step 6: Report on Outcomes Leadership Actually Cares About
IT dashboards track ticket volume and resolution time because these are the metrics IT leadership needs. Legal and ops leadership need entirely different numbers to justify the system’s existence: average contract cycle time by type, percentage of requests that breach SLA and why, volume of recurring request types (which tells you what to template next), and end-to-end vendor onboarding time.
Resist the urge to report on how many times legal said “no” to a request; that metric optimizes for pleasing requesters, not for managing risk, one of the key tasks lawyers do
Shifting these metrics to true business outcomes supports the ITIL practice of continual improvement. Most of the time, the report that actually changes minds internally isn’t a ticket-volume chart. It could be a simple before-and-after comparison of average NDA turnaround, down from roughly nine days to under three once the intake form and template library were in place. That single number can do more magic than any dashboard of raised-and-closed counts.
Step 7: Manage the Change Carefully
Lawyers and operations staff aren’t resistant to structure; most of them are drowning precisely because there isn’t any. What they resist is a system that feels like it was copied from someone else’s workflow and imposed on theirs.
Involve the actual requesters in designing the intake forms, not just the department heads. Run a pilot with a single request type before rolling out the full catalog. We started with NDA requests alone for six weeks before adding drafting and compliance request types. This gave us a working, credible example to point to when the more skeptical parts of the business asked whether this was worth their time.
The Key Pitfalls to Watch For
- Copying IT’s SLA tiers wholesale, rather than deriving them from legal and ops’ own historical baseline data.
- Automating approval decisions instead of just the background routing and notifications around those decisions.
- Launching the full service catalog at once. Pilot a single high-volume request type first, one success story is worth more than five simultaneous rollouts.
- Treating the system as a one-way portal for demanding things from legal, rather than a tool that protects legal’s time and gives requesters visibility without follow-up emails.
- Letting the knowledge base go stale – an out-of-date contract template causes far more corporate risk than having no template at all.
ESM in Legal
Extending ITSM into legal and operations removes the invisible administrative tasks that were already bureaucratic. And this time, legal reflects the IT service desk mindset that IT has refined for two decades: catalog what you offer, set honest expectations, automate the plumbing, and keep the judgment human. The only real work is placing IT’s vocabulary into a language legal and ops teams recognize as their own.
Legal ESM FAQs
ESM, as described in the article, is a genuine transplant of IT’s discipline into departments that have never had it, not a rebrand of IT’s ITSM toolset. Extending ITSM into legal and operations mirrors the ITIL 4 and ITIL (Version 5) principle of value co-creation, showing that service management is an organizational capability rather than something that belongs only to IT.
Language is the single biggest adoption killer. Lawyers and operations staff don’t think of themselves as ticket-raisers, so introducing the system as a queue for logging tickets risks losing buy-in immediately. Reframing the same system as a service catalog, a clear list of services legal already provides like NDA review, contract drafting, and policy sign-off, presents it as formalizing existing work rather than adding new work.
Not by copying IT’s SLA tiers wholesale. Legal and ops SLAs need to be built from actual historical turnaround data, since a market-standard NDA and a negotiated Master Services Agreement don’t move at the same speed. In the article’s own rollout, pulling twelve weeks of contract-drafting turnaround data before setting targets cut average NDA turnaround from nine days to under three, because the numbers reflected reality and lawyers trusted them.
Automate the routing, not the judgment. Repeatable administrative tasks, like routing a vendor contract above a certain value to a second approver, generating renewal reminders, or triggering an IT asset ticket on offboarding approval, are good automation candidates. Approval decisions themselves should stay human, since a single wrong automated approval can create a compliance issue.
The article lists several: copying IT’s SLA tiers instead of deriving them from legal’s own historical data, automating approval decisions rather than just the routing around them, launching a full service catalog at once instead of piloting one request type, treating the system as a one-way portal for demanding things from legal, and letting the knowledge base go stale, since an outdated contract template creates more risk than having no template at all.
Testimony Akinkumi
Testimony Akinkumi is the Compliance Lead at Onpoint International, where he bridges legal strategy with IT Service Management (ITSM). Testimony specializes in driving seamless digital transformation through law and technology
