Queue monitoring and distribution audit

These screens help you understand why requests stay in the queue, whether automatic distribution is behaving as expected, and where bottlenecks are (priorities, skill groups, operator quotas). Below is what each page shows and how to enable access.

When you need it

  • Many requests remain in the queue and clients wait too long for a reply.
  • You need to verify that topics and skill groups are set up so requests can actually reach operators.
  • You want same-day distribution statistics, anomalies, or an explanation of why a specific operator is not receiving new requests.

Access to the pages

1. Role permissions

In addition to general access to the operator panel, the role has two separate permissions:

Permission name in the role listPurpose
Queue StatusOpen the queue monitoring page and load its data.
Distribution AuditOpen the distribution audit page and operator diagnostics.

How to enable:

  1. Open Settings → Users → Roles (/settings-page/roles).
  2. Edit the relevant role.
  3. In the permissions table, find the rows Queue Status and Distribution Audit (or the localized labels shown in your language).
  4. Turn on the main access checkbox for that row (route / module access column).
  5. Save the role and ensure users who need access have this role assigned.

More on roles: Configure roles and permissions.

2. Menu items and UI limits

  • In the Operator panel module, the menu may list Queue Monitoring and Distribution Audit.
  • By default, these items are shown only to users with the root administrator flag in the system. Other users might not see them in the menu even if their role includes the permissions above.
  • If non-root users must use these screens, agree the approach with your platform administrator (instance policy and extra settings may apply).

3. Direct URLs

After signing in, you can open:

  • queue monitoring: /operator_panel/queue_status
  • distribution audit: /operator_panel/distribution_audit

If you see an access denied message, check the role permissions above and the user account.

Queue monitoring page

On-screen title: «Моніторинг черги» in Ukrainian locales, or equivalent in your language.

Purpose: a single view of the queue of requests waiting for distribution: how many there are, how long they wait, and whether there are priority conflicts or skill-group gaps.

What you typically see:

  • Summary figures: requests in the queue and how many need attention (e.g. long wait, priority issues).
  • A health score for the queue.
  • Charts: waiting-time distribution, breakdown by channel, and topics with queued requests.
  • Lists for deeper checks:
    • priority inversion — requests whose stored topic weight is out of date so they may never surface until weights are aligned;
    • oldest in queue (e.g. over 24 hours);
    • highest priority next (e.g. top items due for distribution);
    • skill group coverage — operators online and topic mapping.
  • Refresh and automatic refresh controls.
  • A weight sync action (sometimes labeled «Sync») — fixes mismatches between request and topic weights; read the confirmation dialog carefully because it changes queue-related data.

Tooltips in the UI explain individual metrics.

Distribution audit page

The header may show Distribution Audit; the subtitle usually states that the view covers distribution audit for roughly the last 24 hours.

Purpose: see how the system decided on distribution: how many attempts, how many successful connections, how many skips, whether anomalies exist, and how long cycles took.

What you typically see:

  • Summary KPIs for the last 24 hours (on-screen labels): Decisions, Distributed, Skipped, Anomalies, Avg. duration (milliseconds). Tooltips explain each metric.
  • An anomalies table when records exist: time, type, request, operator.
  • Operator diagnostics: select an operator and run the check; you get a summary, limits and load, available quota, queue matches, queue size, per-channel caps when applicable, skill groups, and sample lists. This answers «why is this operator not getting new dialogs?»
  • Distribution history (sessions) — a table with filters (operator, request id, time range, event type), pagination, and expandable rows for a step-by-step timeline (decisions, connects, skips, candidates).

Use Refresh in the header for an immediate reload; some data also refreshes automatically on a short interval.

Step-by-step guide for supervisors: How to use the distribution audit screen.