Skip to main content

Huddle

When an agent picks up a high-risk ticket, the right help is usually a few people who have solved something similar before. Huddle is the one-click way to get those people into the same room. A Microsoft Teams channel spins up for the ticket, pre-loaded with the relevant experts and the ticket information to set the context.

The point is to start the swarm in seconds instead of asking around in side chats.

When it fires​

Huddle is available on tickets that match tenant-configured criteria. Typical triggers:

  • The ticket is flagged by High Risk Tickets
  • Priority is set to Urgent or Critical
  • Category, subcategory, or domain matches a configured list

The tenant decides how the criteria combine and whether each match opens Huddle by default. Two modes are available:

  • One-click - the agent sees a Start Huddle button on the ticket and decides whether to use it. Most tenants start here.
  • Auto - Huddle fires automatically when a matching ticket is picked up. Used for tenants whose SLAs require an immediate response on certain ticket categories.

Switch between modes per tenant on the Configuration page.

How experts get picked​

The audience added to the Teams channel comes from two AI-driven signals that run in parallel and produce a combined candidate list.

Embedding-based similarity​

The agent compares the open ticket's text to recently resolved tickets and surfaces the people who resolved the structurally similar cases as candidates. This means an agent working a "shared mailbox not receiving" ticket is connected to the engineers who closed three similar shared-mailbox tickets last month, even if the symptom phrasing is different and the categories are not the same.

This signal is the same engine that drives Similar Tickets. The Huddle use of it picks resolvers rather than past resolutions.

Admin-configured expert pools​

Admins map expert pools to ticket category, subcategory, and domain on the Configuration page. When a ticket matches one of those mappings, the pool members join the candidate list alongside the similarity-derived candidates.

Use this when a specific category should always involve a specific person regardless of past-ticket history: the database team for any Database subcategory ticket, the security lead for any incident tagged Security, and so on.

What lands in the channel​

A new Microsoft Teams channel opens with the following pre-populated:

  • Agent who started the Huddle, as the channel owner
  • Audience - the combined expert candidates from both signals, added as members
  • Originating ticket pinned to the channel's first message, with status, priority, and the open SLA timer
  • Ticket Context - the ticket details, the recent activity on it, and (if the ticket is part of an active cluster) the other linked incidents, the cluster summary, and any pre-populated RCA template so the responders see what's already known

After the channel is up, the agent and experts use it like any other Teams channel. The ticket stays as the system of record; the Huddle channel is the workspace for the conversation around it.

Auto-summarisation back to the ticket​

Every 30 minutes, the conversation in the Huddle channel is auto-summarised and posted back as a note on the originating ticket. The summary captures who said what, what was tried, what worked, and any open questions, so the ticket stays current without anyone needing to manually transcribe the discussion.

The summary cadence is fixed at 30 minutes today. Agents can still post their own notes on the ticket at any time; the auto-summary is additive, not a replacement for explicit resolution notes.

What Huddle does not do​

  • It does not transfer ownership of the ticket. The agent who started Huddle stays the assignee.
  • It does not auto-close the channel when the ticket is resolved. The agent decides when the channel is done with its job.