Home/Services/Enterprise Service DeskEngagement type · Build

Enterprise Service Desk

Take one team off the shared inbox, without buying another tool. HR, Legal, or Facilities on the Atlassian platform you already run, with request types they recognize and a queue their department head can read.

01 · Overview

Your HR team is already running a service desk. So is Legal.

They take requests, they chase approvals, they answer the same questions repeatedly, and they do all of it in a mailbox, a chat channel, and a spreadsheet that one person maintains.

I build that team a real front door on the Atlassian platform you already run: request types they recognize, approvals that happen on time, response targets you agree together, and a view of the queue their department head can actually read. Each department after the first is the same architecture, delivered faster.

02 · When it fits

A good fit when someone has been asked to justify a tool.

A renewal quote has landed. Something departmental is up for renewal and somebody has been asked whether it is still worth it.

The requests live in a mailbox. A shared inbox, a chat channel, and a spreadsheet, held together by one person who is now the single point of failure.

A department has asked to buy its own system. They are right that they need one. They may not need a new one.

A migration just landed. Jira Service Management came with the move, the platform owner has been asked what else it can do, and the budget is still open.

03 · Where it works

Where this works, department by department.

The order matters more than the list. Each department inherits the intake pattern, approval model, and reporting shape from the one before it, so the sequence decides how much work the second rollout takes.

Start here

HR

The most common first expansion beyond IT. The request types are well understood, the work connects directly to joiners and leavers, and the approval chains are the clearest, which is where a governed desk earns its keep immediately.

Strongest second

Legal

Legal intake has no dominant incumbent, which is unusual. The contract lifecycle tools your legal team may already use solve a different problem, and this sits alongside them rather than against them.

Once the pattern is set

Facilities, finance, and operational teams

Work well once the first department has settled the intake pattern, approval model, and calendar.

Also proven

Marketing

Campaign and creative request intake with briefs, priorities, and agreed turnaround. I have built this. The desk gives marketing one front door and the reporting to defend their capacity.

04 · One build, then repeats

The first department pays for the architecture.

The intake pattern, the approval model, the calendar, the reporting shape. Every department after that is the same architecture applied to a different catalog, which is why the second one takes half as long.

First department4–5 weeksPays for the architecture: intake pattern, approval model, calendar, reporting shape.
Second department2–3 weeksSame architecture, different catalog.
Third department2–3 weeksSame architecture, different catalog.

Timings assume the first build is complete and the platform decisions it settled still hold.

05 · You receive

What each department receives.

A request catalog in their language

Written the way the department describes its own work, not the way IT would categorize it.

Intake forms that ask the right questions

The information needed to start work, captured in fields that can be reported on rather than buried in free text.

Their own portal

Organized around what their colleagues come to them for, reachable from where those people already work.

Queues, assignment, and triage

Requests reach the right person without someone sorting a mailbox every morning.

Staged approvals

The approval chain the department actually uses, running on the request types that need it.

Response and resolution targets

Agreed with the department rather than imposed on it, on a business calendar that reflects how they work.

A reporting view for the department head

What came in, what is open, what is late, and what keeps coming back.

Handover and a written runbook

So the department can add a request type next quarter without a project.

06 · Scope

One department, one project, one agreed catalog.

Each engagement covers one business function in one company-managed service project, with an agreed number of request types and an agreed set of reportable fields.

Narrowing the catalog is part of the work. Most teams arrive with a list of everything they have ever been asked to do, and the useful version is considerably shorter.

Knowledge base articles, migration of historical requests, custom approval logic beyond what the platform does natively, and integrations to HR or contract systems are each scoped separately.

07 · Delivery

Design it with them, not just for them.

I work with the department, not only with IT. The people who answer these requests know which ones are painful, which approvals get skipped, and which questions arrive every week. That is the design input, and a desk built without it gets abandoned quietly.

IT stays in the room throughout, because the platform decisions we make for the first department set the pattern for every one after it.

08 · Questions

Only for the people who will work the queue. The colleagues raising requests do not need a license, and neither do the approvers, which in HR and Legal is usually most of the people involved. We establish the real number of agents early, because it is often much smaller than expected.

Partly, and the limits are worth knowing before you scope anything. Separate projects and issue-level security handle confidentiality between teams. A Jira site administrator, however, retains broad access by design. If your requirement is that HR records are invisible to IT administrators, the honest answer is a separate instance, and we should establish that on the first call rather than in week three.

Yes, and it affects your subscription. Separately branded help centers per team are a higher edition feature, which is a meaningful change in per-seat cost. It is a reasonable thing to want and a bad thing to discover late, so we check it early.

Then the question is whether it is serving them. Sometimes the answer is yes and I will tell you so. Where the tool is doing intake and approvals that Jira Service Management already does, the renewal date is a good moment to decide.

Two to three weeks once the first is running, assuming the platform decisions still hold. The constraint is rarely the build. It is getting the department to agree its own catalog.

No, but it helps. A working desk in IT gives the next department something real to look at, and it means the platform questions are already settled. If IT is still running on email, we should probably start there.

Give the next team a front door, on the platform you already run.