# Run every support shift from a live Dixa queue war room

> See every queue, who is waiting, and who is actually online right now, then claim, transfer, tag, and note without ever leaving the board.

- Workflow type: app
- Services: Dixa, Slack Bot
- Categories: Customer Support, Operations
- Published: 2026-08-21

## What it does

- Shows every support queue side by side with the conversations waiting in each one, each row colored by how long it has been sitting and linked straight to the conversation.
- Puts a live staffing panel next to the board so you can see which queues are busy and short handed at a glance, instead of guessing.
- Lets a lead claim a conversation for a specific agent, move it to a better queue, tag it, or leave a routing note straight from the row.
- Adds a Triage the backlog button that hands the oldest waiting conversations to an assistant, which summarizes each one, recommends an owner, writes that back onto the conversation, and posts a shift handover to Slack.

## What you'll need

- A Dixa account with administrator access, since only admins can create the key this app needs
- Your queues and teams already set up in Dixa
- A Slack workspace, if you want the shift handover summary posted to a channel
- A shared screen or second monitor is ideal, since the board is built to stay open all shift

## Prompt

Build me a live queue war room app for Dixa that my support leads open at the start of every shift and keep on a second screen all day. It is an operational surface, not a report: the whole point is that it reads live conversation and presence data rather than Dixa's delayed analytics layer, so please do not build any view on top of the analytics endpoints.

The main board is a queue-by-queue view. Use Dixa List queues to get every queue, and Get queue availability for each one to show whether it is currently available on its supported channels. Under each queue, list the conversations currently waiting in it, found with Dixa Search conversations with filters scoped to that queue and to conversations that are still open and unassigned. Each row should show the customer, the channel it arrived on, a short preview or subject, and how long it has been waiting. Where it is useful, enrich a row with Dixa Get the position of the conversation in its current queue so a lead can see it is fifth in line rather than just old. Every row links out to that conversation in the Dixa web app so the lead can open it in a new tab, using the conversation id, which is an integer.

Color every row by how long it has been waiting: healthy, warning, and critical. The two thresholds that separate those bands must be configurable in a settings panel rather than hardcoded, because a chat queue and an email queue have completely different expectations. Sort each queue's rows oldest first, and show a count and the oldest wait time in each queue's header so a lead can scan headers alone and know where the fire is.

Next to the board, add a staffing panel that answers "do we have people for this?". Pull Dixa List agent presence for the whole organization, and Dixa List teams plus List team presence to break availability down by team. Use Dixa List queue members to tie queues to the agents assigned to them, so each queue can show how many of its members are actually online right now. Call out understaffed queues clearly, meaning a queue with a meaningful backlog and few or no available members. That side by side reading of backlog against staffing is the core of the app.

A lead has to be able to act from any row without leaving the app. Give each row: Claim conversation to assign it to a specific agent, with the agent picker populated from Dixa List agents and biased toward agents who are currently available; Transfer conversation to move it to a better queue, with the queue picker from List queues; Tag conversation to label it, with the tag picker from Dixa List tags so only active tags are offered; and Add internal note to leave routing context for whoever picks it up. After any of these succeed, refresh the affected queue so the board reflects reality immediately.

Add a "Triage the backlog" button that kicks off a background agent. The agent takes the oldest waiting conversations across the queues currently in view, reads each one with Dixa List messages, and writes a one-line summary of what the customer actually needs plus a recommended owner or a recommended queue, with a short reason. It posts each recommendation back onto its conversation using Dixa Add internal note so the context travels with the ticket, and it finishes by sending a shift handover summary to the support channel with the Slack Bot Send a Message operation, covering the state of each queue, the worst-aged conversations, and the routing recommendations it made. Show the agent's progress and its finished recommendations inside the app, on the matching rows, so the lead can read them on the board without going to Slack.

Two pieces of per-user behavior matter. Each lead can filter the board down to just the queues they own, and that filter is remembered for that specific user across sessions, so opening the app at the start of a shift lands them on their own queues without any setup. Aging thresholds, the refresh interval, how many conversations the triage agent looks at, and the Slack channel for handovers are shared settings for the whole team, editable in the app.

Design it for a wall or a second monitor: dense, high contrast, readable from a few feet away, with the aging colors doing the heavy lifting. It should auto-refresh on the configured interval and show when it last updated, with a manual refresh available. Dixa allows roughly ten requests per second, so batch and stagger the per-queue lookups rather than firing everything at once, and keep the board usable if one queue's fetch fails.

## How to customize

- Change the aging thresholds that decide when a waiting conversation turns from healthy to warning to critical
- Filter the board down to just the queues each lead owns, and the app remembers that choice per person
- Pick which Slack channel receives the shift handover summary and how often the board refreshes itself

## FAQ

### Does this replace Dixa's own reporting?

It sits alongside it. Dixa's reporting can lag well behind what is actually happening, which pushes a lot of teams into manual ticket counting. This board reads your live queues, conversations, and agent availability instead of waiting on the analytics layer to catch up.

### Can two leads use it at the same time with different queues?

Yes. Each person picks the queues they own and the app remembers that choice for them, so your view does not change when a colleague changes theirs.

### Do the actions I take here show up in Dixa?

Yes. Claiming, transferring, tagging, and internal notes are written straight into Dixa and appear for your agents immediately, exactly as if you had done them in the Dixa interface.

### What does the Triage the backlog button actually do?

It reads through the oldest waiting conversations, writes a one line summary and a suggested owner or queue for each, posts those recommendations onto the conversations as internal notes, and sends a handover summary to your support channel.

### How current is the information on the board?

It refreshes on the interval you set, so what you see reflects the queues and agent availability as they stand right now rather than a report built hours ago.

### Do our agents need to change how they work?

No. Agents keep working in Dixa as usual. The board is for the lead watching the whole floor, and anything the lead does from it lands on the conversation in Dixa.

Use this prompt in General Input: https://www.generalinput.com/prompts/run-every-support-shift-from-a-live-dixa-queue-war-room