Ask your General Counsel where legal requests actually live, and brace yourself for the honest answer: an inbox, a couple of Slack threads, a hallway conversation, and a sticky note somebody swears is “basically a system.”

Here's the thing nobody says out loud in the legal department: your legal team is already running a service desk. Contract reviews come in. NDAs get requested. Policy questions land. Vendors need sign-off. Work arrives, work gets done, work goes back out. That's the exact shape of a service operation — it just doesn't have a front door, a queue, or any memory of what happened last Tuesday.

This is Part 1 of a three-part series on running a legal team on Jira Service Management (JSM). We'll start where every good system starts: the front door. Part 2 covers the workflows, approvals, and (yes) SLAs that move work once it's in the building; Part 3 gets into knowledge, Assets, and AI. But none of that matters until intake stops being chaos.

Legal work is service work (whether legal likes it or not)

When a request arrives by email, three things quietly go wrong. First, there's no record — six months later, nobody can prove what was asked, promised, or delivered. Second, there's no triage — a bet-the-company acquisition question and a “can I use this logo?” query sit in the same inbox with the same urgency. Third, there's no shared status, so the business fills the vacuum with the world's least productive message: “any update on that contract?”

Atlassian actually ships a Legal Service Management template for exactly this, with tailored request handling, an approval-ready workflow, a self-service portal, and a knowledge base built in. It's a genuinely strong starting point. But a template is a foundation, not a finished house — and legal has a few requirements most teams don't.

Build request types that match how legal actually gets asked

The single highest-leverage decision you'll make is your request types. These are the options a person picks on the portal, and each one carries its own intake form. Get them right and the first reply from legal is real work. Get them wrong and every request opens with “what are you actually asking me for?”

For most in-house teams, a sensible starting set looks like this:

• Contract review — capture the counterparty, contract value, deadline, business owner, and whether it's on your paper or theirs.
• NDA request — mutual or one-way, counterparty, and purpose.
• New vendor / DPA review — the data-privacy and procurement-adjacent asks.
• Policy or compliance question — the “is this allowed?” bucket.
• IP / trademark request — filings, usage, and brand questions.
• Employment or people-legal matter — often the most sensitive of the bunch.
• Something else for legal — the honest catch-all, because you'll never predict everything.

Each form should ask for what counsel needs to start — not a novel, just enough to skip the first three rounds of email. A contract-review form that captures the deadline and the counterparty up front has already earned its keep.

The portal is legal's front door — treat it like one

Once request types exist, the customer portal becomes a single link you can hand the entire company: this is how you ask legal for something. No more guessing which lawyer to email. And because it's JSM, you control who's allowed through the door — in the project's customer permissions, restrict who can raise requests to your own employees. Legal's portal is not a public help desk.

Confidentiality on day one, not as an afterthought

Here's the objection I hear most: “Legal is too sensitive to live in a shared tool.” It's a fair concern, and it's also the reason so many legal teams stay stuck on email forever. The good news is that JSM handles this well when it's configured deliberately — and “deliberately” is the operative word.

Three controls do the heavy lifting. Request-type restrictions let you decide who can even see and raise certain requests — an internal investigation shouldn't be an option sitting on everyone's portal. Issue security (work item security) adds a layer on top of project access so a specific matter is visible only to named people or roles; even other agents, and even admins who aren't on the list, can't see it. And form restrictions go finer still — the whole team can work a request while a sensitive form, say a settlement figure or an investigation detail, stays locked to specific counsel. Atlassian recently made it easier to set the “who can view” and “who can raise” rules together in one place, a small change that matters a lot for legal, HR, and finance.

One honest caveat: work item security is a company-managed project feature and needs a paid plan, so this isn't a free-tier trick. Worth knowing going in.

The Avaratak Take

The template gets you a room; the configuration makes it legal's room. The two things that separate a service desk lawyers actually use from one they quietly route around are (1) request types that mirror how your business really asks for help, and (2) confidentiality that's real from the first ticket, not bolted on after someone glimpses a settlement number they shouldn't have. Do those two things well and you've solved the problem email never could: legal work that leaves a record, gets triaged, and shows its status without a single “any update?” message.

Don't let “legal is different” become the excuse that keeps your highest-paid team running on an inbox and a sticky note. Legal is different — which is exactly why it deserves a front door built on purpose.

At Avaratak, we stand up JSM for legal teams so it's genuinely fit for legal: confidential by design, mapped to your real intake, and ready to scale. If you're eyeing that inbox and wondering whether there's a better way, let's talk.

Next up in Part 2: routing, approvals, and why “legal SLA” isn't the contradiction it sounds like.