XLAs & dispatch

With the desk structured, your next job is flow: work reaching the right technician, and the clock starting on the right tickets. This lesson covers the four settings that govern it — XLA timers, auto-dispatch profiles, available-for-dispatch, and business hours and closures — and how they reinforce each other.

​

XLA, not SLA — and why the difference matters

Your PSA already has SLAs. An SLA is a contractual promise in the agreement you sold: first response in 30 minutes, resolution in 8 hours. It exists to be measured after the fact, for billing and for the renewal conversation, and it is satisfied or breached as a matter of record. Thread tracks an XLA — an Experience Level Agreement. Same clocks, different question. An SLA asks “did we meet the contract?” An XLA asks “what did this actually feel like for the customer?” That is not a word game, because the two can disagree: An SLA that reads green while the customer is frustrated is the failure mode Thread is built to close. So the timers here measure the experience: they stop on a real human reply rather than an auto-ack, they pause while Triage Agent is still working the conversation, and they respect your closures — so the number is one you can act on rather than defend. Both still matter. Keep your SLAs in the PSA as the contract. Run the desk on XLAs, because that is the clock your team can see while the work is still in flight.

​

Set your XLA timers and response expectations

XLA timers and response settings define the promises your desk makes: how fast a new request gets a first response, and how fast it gets resolved. Thread tracks these live, surfaces them on tickets and Views, and rolls attainment into analytics — so an XLA isn’t a spreadsheet you reconcile after the fact, it’s a clock your team can see ticking. As the manager, you own the targets. A few principles keep them useful:

• Set thresholds you can actually hit. An XLA you breach constantly stops being a signal and becomes noise the desk learns to ignore.
• Differentiate by priority. A P1 outage and a routine password reset shouldn’t share a response target.
• Make the timer visible in the work. Build a Breaching soon View (from the previous lesson) so techs act before the clock trips, not after.

​

Put the XLA to work in Views and Flows

A timer nobody sees is a report. These are the two places an XLA changes what happens on the desk: Views — make risk the thing people open. Where Experience Level Agreements are enabled you can sort a View by XLA risk and slice View Insights by it, so “what’s tightening?” is a board rather than a question. Two worth building:

• Breaching soon — everything with a timer about to trip, across the team. This is the View a dispatcher works from, not a report they read.
• Needs response — last sender is the contact, sorted by XLA risk, so the tickets where silence is compounding sit at the top.

Flows — act on the clock without anyone watching. Flows fire on ticket events and can then run any action: reassign, change priority or board, post an internal note, page an on-call technician, or hand the ticket to a Super Magic Agent to work unattended. Point them at the tickets your XLA View surfaces and the escalation stops depending on somebody noticing.

​

Route work automatically with dispatch profiles

Manual dispatch doesn’t scale, and it breaks the moment the dispatcher is at lunch. Auto-dispatch profiles let Thread assign incoming work for you, based on rules you define — so new tickets land on the right team or technician without anyone playing traffic cop. A dispatch profile ties together the pieces you set up earlier: Point profiles at teams, not individuals, wherever you can. Routing to a pod means the work still flows when someone’s on PTO, and your reporting stays clean because load balances within the group.

​

Keep the routing pool accurate with available-for-dispatch

Auto-dispatch is only as good as its picture of who’s actually available. Available-for-dispatch is the toggle that controls whether a technician is in the pool for new automatic assignments — the real-time answer to “who can take the next ticket right now?” This is what keeps dispatch honest through the day:

• A technician heads into a long on-site or a focus block → they come off dispatch, and new work routes around them.
• Someone wraps their current load and has capacity → they go on, and the pool rebalances.
• Out sick or on PTO → off, so the profile never assigns to an empty seat.

Coach the team to treat their availability like a status they own, and lean on it yourself when you’re balancing load. It’s the difference between a dispatch profile that distributes work fairly and one that keeps piling onto whoever forgot to flip a switch.

​

Ground the clock in business hours and closures

The setting that makes all of the above trustworthy: business hours and custom closures. This defines when your desk is open, which in turn governs when XLA timers run and when work is expected to move. Get three things on the calendar:

​

Next

Work is structured and flowing on time. Now learn to see how it’s actually performing — and to run a QA loop that turns those numbers into coaching.