You don't have a platform problem. You have an operating model problem.

[#1]

🔍 Reading between the tickets

I often work with organisations moving off legacy ITSM tools onto Jira Service Management. The brief is usually cost reduction. Replatform quickly and move on. But as a consultant, I always peek at the service data first. It usually tells me exactly what needs to happen.

Hundreds of reports, queues, forms, SLAs, and fields layered on top. This isn't a candidate for replatforming. It needs to be redesigned.

---

🧩 IT Operating Model

In the last article, we pulled apart the service catalogue, so let's jump into assignment groups or queues. Queues exist to flow work through the organisation. I’ve seen enterprises with a few thousand employees and a queue for every six of them. Something has gone sideways. Routing breaks down, ownership gets ambiguous, and reporting becomes meaningless.

Why too many queues break things: routing logic gets brittle, agents work in silos, SLAs get gamed, and reporting fragments across hundreds of micro-contexts.

Then there are the practical constraints. JSM supports up to 300 queues per work category, per project, but the more relevant limits are human ones: agent cognitive overhead, board performance, and the impossibility of meaningful reporting across hundreds of fragmented views. Those limits hit well before 300.

What a healthy queue model looks like: queues mapped to services and teams, not to every micro-variation of a request. Tie it back to the catalogue: if your catalogue is well-defined, the queues design themselves.

The operating model question: queues are a symptom. The real question is whether your support model is structured around services and the capabilities needed to deliver them, or around org chart inertia. Most enterprises don’t know.

---

🛠️ So how do we address this?

Here's the thing: this isn't a redesign you do in a workshop with sticky notes. It emerges from the assessment work.

After reporting on known demand, you'll start to see clusters. Those clusters will map to the catalogue work. Where they don't, that's a gap worth investigating, and usually the most revealing part of the assessment. That's where the new operating model design starts.

From there, the redesign tends to follow a fairly consistent path:

Start with what the business already knows

Most organisations, especially at enterprise scale, have already defined their business-facing capabilities somewhere: the broad service domains they need to operate. IT Support. Finance. HR. These aren't IT constructs. They're business ones. They become your service domains, and in JSM, they shape your project structure.

Within each domain sit the level 2 capabilities, the specific things the business needs to achieve. Under IT Support, for example, you might find Workplace Productivity: enabling staff to perform their roles with secure, supported devices. The capability describes the purpose. It doesn't describe how you deliver it.

That's where business services come in. A capability like Workplace Productivity might be delivered through a business service called End User Compute. The service is the how, the thing with an owner, a team, a queue, and a set of forms that let people request it. But it doesn't need twelve queues for twelve office locations. That's the difference between designing from the business down and tidying up from the tickets up.

The test for whether something should exist as a distinct business service is straightforward: Does it have a recognisable audience? A clear owner? A measurable outcome? If you can't answer yes to all three, it's probably a request type within a broader service, not a service in its own right.

If your organisation already has an enterprise architecture framework, this plugs straight into it.

Map services to owners, then owners to teams

Who owns the service end-to-end? Not who triages the ticket. Who is accountable for the outcome. The team executes. The owner is answerable. If no one can answer the question, that's the work to do before you touch the queue structure.

This is where Skelton and Pais's Team Topologies framework becomes useful. The reason enterprises end up with one queue per six employees is that their support structure mirrors their org chart rather than their value streams. When you align teams to services rather than to reporting lines, the queue structure simplifies itself. The teams know what they own, and the queues reflect that ownership.

Map teams to queues

Now, and only now, do you design the queues. A small set of well-designed queues per team, rather than one per request variation. Remember, a queue is just a saved JQL filter with a display layer on top. The lever isn't more queues. It's tighter JQL, smarter columns, and disciplined sorting. Suddenly 500 queues becomes 50. Sometimes fewer.

The consolidation conversation is a people problem

This is the uncomfortable bit. Start with the obvious: if a queue has had fewer than ten tickets in the last quarter, or if its work could be absorbed into another team's queue without losing visibility, it's a candidate.

Data builds the case, but it rarely closes it. I've watched a queue survive three reorgs because one manager's entire quarterly report was built on it. That's the real resistance: it's not that people love queues, it's that queues have become load-bearing walls for someone's visibility, headcount justification, or sense of team identity. You don't win that argument with a spreadsheet alone.

What tends to work: executive sponsorship from someone who owns the service outcome, not just the platform. Frame consolidation as a service improvement, not a rationalisation exercise. And make the reporting gains visible before a queue disappears; if the team can already see their work better in a dashboard, the queue just… goes away.

But this isn't a one-off cleanup. Build a quarterly review into your operating rhythm. If a queue can't justify its existence with demand data, it goes.

⚠️ Warning sign to watch for during redesign: Teams who insist they need their own queue to see their work. In JSM, a queue should primarily help agents act, pick up, triage, resolve. It should not be the default answer to every visibility, ownership, or reporting need. If the requirement is “I need to monitor work across teams, services, priorities, or request types,” that is almost always better served by dashboards, Atlassian Analytics, saved filters, or reports, not another queue. When you reach for a queue to solve a visibility problem, you’re creating structural complexity to fix a reporting gap.

What does this look like in practice? Here's the full stack, from domain to dashboard:

Layer	Example	Maps to in JSM
Service Domain	IT Support	Project/Portal
Capability	Workplace Productivity	—
Business Service	End User Compute (EUC)	Service + Owner
Team	EUC Support Team	Team
Queues	L1 Triage, L2 Support, L3 Escalations	Queues
Entry Points	Hardware Request Hardware Repair	Forms / Request Types
Visibility	Ops Dashboards Analytics Dashboards	Not Queues

Services people recognise, teams that own them, queues that reflect how work really flows.

And when the next platform migration comes around, because there's always a next one, you're replatforming a system that makes sense, not just lifting and shifting the complexity.

---

📖 Further Reading

This is my second contribution to the CSX Masters “Beyond ITSM” series. Stay tuned for more.

See also…

• What are Queues? (Atlassian): the platform constraint behind the 300-queue ceiling, and a useful conversation-starter when stakeholders push back on consolidation.

• Team Topologies (Skelton & Pais): the framework underpinning the services-to-teams mapping discussed above.

✨ About the Author

Chrissy Clements is an Atlassian Community Champion and ITIL Master & Ambassador. She also helps organise the Brisbane ACE.

In her day job, she brings 💫 service management sparkles 💫 to Global Alliance Partner, Accenture.