Requests arrive everywhere. The work gets done by whoever notices.
When requests arrive by email, chat, and hallway conversation, nothing is deliberately ignored, but nobody can say what is outstanding, who owns it, or how long any of it has been sitting.
I build an IT service desk in Jira Service Management: an agreed request catalog, portal, queues, approvals, response targets, and reporting. Built, tested, and handed over with documentation. Scope and fee agreed before work starts.
A good fit whether you are starting from nothing or starting over.
Requests arrive everywhere. Email, chat, phone, and desk visits. Your team is responsive but the work is invisible until someone complains.
You have outgrown a basic tool. The ticketing system you started with cannot handle approvals, routing, or the reporting your leadership now asks for.
Jira Service Management is already there, but underbuilt. It arrived with a migration or an earlier project and nobody has had time to make it work the way your team operates.
Something has a date on it. A renewal on your current tool, an audit that needs evidence of a controlled process, or a commitment you have made about response times.
The desk, in one line.
Requests enter through a form that asks for what your team needs to start. They land in a queue with an owner and a response target. Approvals happen where they are required, work happens where it belongs, and the outcome is recorded.
What the core build includes.
A request catalog people can navigate
An agreed set of request types, written in the language your organization uses rather than the language IT uses.
Forms that collect the right information
The fields your team needs before work can start, mapped so they can be reported on rather than buried in a text box.
A portal your organization will use
Branded, organized by what people need, and reachable from where they already work.
Queues, routing, and assignment
Work reaches the right person or team without someone triaging every item by hand.
Approvals where they belong
Agreed approval steps on the request types that need them, and none on the ones that do not.
Response and resolution targets
Agreed targets on a real business calendar, so a Friday evening request is not measured against a Saturday clock.
Reporting for the person accountable
One view that answers what came in, what is open, what is late, and where the time is going.
Handover you can operate
A working session with your administrators and written documentation covering how the desk is configured and how to change it.
Add-ons, scoped separately.
The core build is a working service desk. These extend it. Each is scoped and quoted on its own, and each can be added later without rebuilding what is already there.
Change management
Change request types, risk assessment, approval paths, and a change calendar. This is usually the first thing an auditor asks about after the desk itself.
Asset management
An Assets schema covering the hardware, software, and services your team supports, connected to the tickets and the people they relate to. Object allowances and subscription requirements are confirmed during scoping rather than assumed.
Incident management with on-call
Severity definitions, a major incident process, on-call schedules, alerting, and escalation. If your team is currently on Opsgenie, this is also your migration path off it.
Knowledge base and self-service
A Confluence-backed article library connected to the portal, so common requests can be answered without a ticket. Confluence licensing for the people writing articles is a separate cost and is identified before the work is scoped.
Start with a defined catalog and a defined set of teams.
The core project covers one service project for IT, an agreed number of request types, and an agreed set of reportable fields. Narrowing the catalog is part of the work, not a concession. A desk with sixty request types nobody can find serves people worse than a desk with twelve they can.
We agree which teams work the queue, which approvals are required, what your response targets should be, and what the reporting needs to answer. Where a request depends on another team or an outside supplier, that boundary is made explicit rather than assumed.
Historical ticket migration, additional departments, and the add-ons above are scoped separately.
Map it. Build it. Test it. Hand it over.
Map the requests. I start with the requests your team already receives, including the ones that never became tickets.
Agree and build. We agree the target design, then I build and configure it.
Test the awkward cases. Scenarios run with the people who will work the queue: a request with missing information, an approver on vacation, a target about to breach.
Launch and hand over. Launch includes your administrators, not just your agents. You should be able to add a request type after I leave without calling me.
Once IT’s desk is running, the same approach works for HR, Legal, and Facilities. See the Enterprise Service Desk.
No. If you are already on Atlassian, we confirm which subscription you hold and what it includes. If you are not, licensing is a separate cost from the consulting work and we identify it before the scope is agreed.
Usually not. The work moves from designing a catalog to untangling an existing one, and that comes with conversations about replacing configuration someone else built. It is scoped the same way and priced on the same basis.
Only the people working the queue need an agent license. The people submitting requests do not, and neither do approvers. This is often the difference between what a buyer expects to pay and what they actually pay, so we establish the real agent count early.
Sometimes, and it is scoped separately. It is worth asking what you actually need: an archive you can search is often more useful, and considerably cheaper, than migrating years of closed tickets into a new system.
No. The core build is designed so change management, assets, incident management, and knowledge base can be added afterward without rework. Deciding later usually produces a better result, because by then your team knows how they work.
Worth a conversation, and not part of a fixed-fee scope right now. Atlassian’s AI billing model is changing, and I am not going to commit to a fixed fee for something whose running cost I cannot predict for you.
Give your team one place to receive work, and a way to account for it.