A multi-brand service desk is one team, several brands or customers and one ticketing tool. The tool was designed for one company. So every day the staff do the work it won’t: check which customer a request belongs to, ask for the details the form missed, find the team that owns the fix and keep two customers apart.
That desk has to solve two problems at once. It has to share people and process, because that’s where the saving is. And it has to keep customer context, visibility and service promises apart, because that’s where the risk is.
This guide covers the boundaries to draw first, the steps AI makes routine, and the KPIs that show whether the shared desk is improving. It draws on a service desk layer we built on top of Jira Service Management for a group running several consumer brands.
Why service desk tools assume one company
Enterprise service desk products grew out of internal IT. One company, one help centre, one set of employees raising requests. Serving outside customers came later. And serving several unrelated customer groups from one desk came later still.
The assumptions show up in specific places:
- One portal identity. The help centre carries one name and one logo. A customer of brand A signs into a portal that looks like brand B.
- Visibility by organisation. Jira Service Management groups customers into organisations, and a request shared with an organisation is visible to all its members. Good for a company, risky when an organisation is a customer with staff who change.
- Notifications per project. Customer notifications are switched on per project and sent from the tool’s domain. Per-brand sender names and templates need work outside the tool.
- Search across the site. A staff search finds every ticket the searcher can see. A customer-facing search has to be scoped to one customer, including attachments and suggested titles.
- One SLA clock. Goals and calendars exist, and each customer’s contract needs its own.
Licensing can add a hard constraint. A group running regulated brands under separate licences may be required to run separate desks. So the question is how to bridge two desks without merging their records. A layer on top of the tool is the practical answer.
The walls between brands run through the portal, search and notifications. They stop at the queue, because the saving of a shared desk comes from sharing the people and the process.
Boundaries a multi-brand service desk needs first
A shared team does not imply a shared customer view. Write down what is shared and what is separate before you add any assistant, because the assistant inherits whatever the tool leaks.
| Layer | Shared across brands | Separate per brand or customer |
|---|---|---|
| Customer portal | Design, general help content | Requests, attachments, membership, notifications, sender identity |
| Staff queue | Workload view for authorised staff, the triage process | Which staff may open or change each customer’s records |
| Knowledge search | Approved general procedures | Resolved cases, customer-specific incidents, restricted documents |
| Delivery teams | Technical detail needed to do the work | Customer identity and unrelated source material |
| Reporting | Team capacity and throughput | SLA attainment, reopen rate and ageing, per customer |
Access follows a verified account and an approved membership. A brand name typed into a form is context. It’s never proof that the person belongs to that brand.
Atlassian’s own guidance on customer permissions and request sharing covers restricted versus open portals and what customers can share. Read it, configure it, then test it with synthetic accounts across two brands. Check search, direct links, attachments, notifications and a revoked membership. And a clean queue proves nothing about separation.
Where the delay sits
Before you automate the queue, follow twenty recent requests from submission to close. Record where staff waited, asked again or moved the work. Separate hands-on effort from elapsed time, because they need different fixes.
Two requests can show the same first-response time and very different service. One got an automated acknowledgement and sat unowned for six hours. The other reached a specialist in ten minutes and waited two days for the customer to answer a question. So the first is a routing problem, and the second is an intake problem.
Define the starting measures before you change anything:
- Time to correct owner. From submission to acceptance by the team that will do the work.
- Avoidable reassignment. Requests moved because the first routing decision was wrong, divided by all reviewed requests.
- Clarification rounds. Exchanges needed before work can start.
- Ageing work. Open requests grouped by age, priority, customer and the reason they are waiting.
- Review effort. Staff minutes spent accepting, editing or rejecting suggestions.
Keep request categories visible in every one of these. A software defect, an access request and a planned change should not share one handling-time target. And a change in the mix moves the average without changing the service.
What AI makes routine in a multi-brand service desk
The coordination work in a shared desk was always possible to do well. But it was too expensive to do on every ticket, so it was done on the loud ones. Language models change that cost. Four steps that were occasional become routine.
| Step | Before | With a model in the loop | Who decides |
|---|---|---|---|
| Duplicate and related-case check | Searched by a senior agent when a ticket looked familiar | Every new request is compared with resolved cases in the same customer’s scope, with a named candidate and a reason | A reviewer links, separates or asks |
| Classification and priority | Set by the customer, then corrected by staff | A suggested type and priority from the customer’s own request vocabulary and the agreed priority matrix | A reviewer accepts, edits or rejects |
| Missing detail | Asked for in the first reply, a day later | Bounded clarifying questions at intake, and a draft the customer can edit before submitting | The customer, before submission |
| Summaries and updates | Written by hand when the ticket changed teams | A summary of the history for the next team, and a draft status update for the customer | The agent who sends it |
The pattern is the same in each row. The model proposes, with evidence a person can inspect. The person decides. Nothing writes to the customer’s record or changes a status without that decision, and every suggestion records the model, the prompt version and the evidence it used.
Use fixed rules wherever the rule is already clear. A request from a customer whose contract names a P1 response time gets that priority from the contract, never from a model’s reading of the tone. The model earns its place on the ambiguous middle.
Duplicates across brands without losing a request
Two tickets with similar wording can describe different work. They may belong to different customers, need different permissions or carry separate service commitments. So a duplicate suggestion is a review decision, and the reviewer needs to see the candidate rather than a similarity score.
Whatever the reviewer chooses, each customer keeps their own request, their own update and their own service clock. Linking the work never merges the customers.
| Candidate relationship | Useful action | What to preserve |
|---|---|---|
| Same issue, same requested outcome, same customer | Link to the existing request or merge | Who tells the customer, and which SLA clock continues |
| Similar symptom, different customer | Reuse the diagnosis, keep the requests separate | Each customer’s visibility and update |
| One incident affecting several customers | Coordinate one technical fix | A separate request, update and service obligation per customer |
| Uncertain match | Ask for clarification or keep the work separate | No premature closure |
The retrieval behind the suggestion obeys the same access rules as the portal. It searches resolved cases within the customer’s own scope, and a request from another customer never appears as a candidate, a suggested title or a line in a summary.
Staff with broader rights can see more. Even then, the summary that goes to a delivery team carries the minimum: the symptom, the steps tried and the evidence, without the customer’s identity where the work doesn’t need it.
And for customer intake the check runs before submission. If a customer’s own open request matches, the portal shows it with a link, and the customer confirms that the new work is different or goes to the existing request. Resolved guidance never blocks a submission.
SLAs and KPIs per customer
A service-level agreement needs a clock. Decide when it starts, what pauses it, when it stops and which working calendar applies. Then write those four answers into the contract and the tool in the same words.
First response and resolution are separate commitments. An automated acknowledgement satisfies neither when the contract asks for a meaningful reply from a person. So measure first meaningful response, defined as a reply that answers or asks a specific question.
Calendars differ by customer and by region. Jira Service Management’s SLA calendars carry working days, time slots, a time zone and holidays per calendar, and each goal can use a different one. A brand with 24-hour cover and a brand with office hours need different calendars. And their attainment figures can’t be compared without them.
Both brands waited the same 26 hours. Only the brand with office-hours cover is inside its target, so comparing their attainment without their calendars says nothing.
Make waiting states visible instead of using them to hide delay. A pause for customer information records what is needed and who owns the next step. Waiting on an internal team is a different state, and it usually shouldn’t pause the customer’s clock at all.
| KPI | Definition | Why it matters in a shared desk |
|---|---|---|
| SLA attainment per customer | Requests that met their goal / requests with that goal, on the customer’s calendar | One team, several contracts. A blended figure hides the customer you are failing |
| Time to first response | Submission to first meaningful reply, on the customer’s calendar | Automated acknowledgements make the raw figure meaningless |
| Time to correct owner | Submission to acceptance by the responsible team | Routing quality, which triage automation is meant to improve |
| Reopen rate | Requests reopened within 14 days of closure / closed requests | Catches closures that satisfied the queue rather than the customer |
| Agent hours per ticket | Hands-on staff time / closed requests, by category | The number the shared desk exists to lower |
| Suggestion accuracy | Accepted without edit / all reviewed suggestions, with a sampled check of accepted ones | Acceptance alone measures trust, which can be misplaced |
A worked example, with assumptions. A desk closes 600 requests a month across three brands and spends 1.5 agent hours per ticket, so 900 hours. Assume intake and triage automation cut clarification rounds by half and avoidable reassignment by a third, and that those two account for 20 minutes of the 1.5 hours.
The desk then saves around 60 hours a month before review time is subtracted. That’s the order of saving to expect from triage alone. The larger gain comes from fewer reopens and better ownership, and it takes a quarter to show.
The smallest change that closes the gap
Three routes exist, and they cost very different amounts to run.
- Configure the tool. Organisations, portal groups, request-type permissions, per-customer SLA goals and calendars. Cheapest, and it keeps one system to operate. Test it with synthetic accounts before deciding it is enough.
- Integrate. When a customer request must create technical work in another project or another instance and carry status back, an integration under a service account does that without exposing the internal workspace. This is also how two licensed desks get bridged.
- Build a customer layer. When customers need their own login, their own domain and notifications from their own brand, and the tool cannot provide it, a portal on top of the desk is the honest answer. Budget for accounts, invitations, recovery, notifications, accessibility and support. The request form is the small part.
We took the third route for the group described above. Their brands needed separate customer identities, and their two desks couldn’t be merged for licensing reasons. The staff stayed in Jira Service Management.
The customers got a portal that knows which brand they belong to, and an integration creates the linked developer work behind it. The triage suggestions, duplicate checks and drafts described here run in that layer, and every one of them ends in a person’s decision.
That is the shape of the work our process automation service delivers. The same review-before-action pattern runs the HR reporting and reminders we built elsewhere.
Proving it on one service journey
Pick one request type, one customer group and a named service owner. Capture the baseline from the measures above, then run a bounded pilot with the ordinary manual route still open.
The pilot review has four checks:
- Separation. Two synthetic customers with different memberships. Search, direct links, attachments, notifications and a revoked membership. Each one either passes or blocks the rollout.
- Real status. Follow completed requests through the customer view and the delivery team’s system. A status shown to the customer must match the record behind it, and a retry must not create duplicate work.
- Effort. Total staff time before and after, including review of suggestions and handling of exceptions. But if intake time fell and reassignment rose, fix routing before expanding.
- Customer effect. Reopen rate and status-chasing contacts for the pilot group against the baseline.
Expand when ownership improved, avoidable exchanges fell and no boundary check failed. The number of tickets the assistant touched is activity. The numbers above are the outcome, and they’re what a service manager can take to the customer.
Frequently asked questions
Do we need a separate service desk for every brand?
Usually not. One desk can hold separate customer organisations, request types and SLAs, and the staff can work one queue. Licensing can force a split, as it does for regulated brands that hold separate licences. In that case a layer on top of the desks bridges them.
Can AI close duplicate tickets automatically?
We don't let it. Similar wording is not the same request, and two customers may hold separate service commitments for one underlying incident. AI proposes a candidate with a reason. A person links or separates, and each customer still gets their own update.
Why does Jira Service Management struggle with several brands?
It handles them, with work. Organisations, portal groups and request-type permissions keep customers apart, and SLA calendars can differ per customer. The gaps are the customer portal, which carries one identity, and notifications, which are configured per project rather than per brand.
Which KPIs show whether triage automation is working?
Time to correct owner, avoidable reassignments, clarification rounds, SLA attainment per customer, reopen rate and agent hours per ticket. Track accepted, edited and rejected suggestions separately, and review a sample of accepted ones for rushed approvals.
Should we replace our ticketing system?
Test configuration first, then an integration. A dedicated customer experience is justified when a measured gap in privacy, identity or notifications cannot be closed inside the tool. Budget for accounts, invitations, recovery and support, because the form is the small part.