Reference · built on requestOperator by FibricCustomer support

Breach Watch

Watches next-reply and resolution timers against who is on shift. Proposes a reassignment or priority change before a target is missed.

Request accessPricing ↗

About

A service target is missed one ticket at a time, usually by an agent who has too many or has gone home. Breach Watch reads the running timers on open tickets, the target each priority carries, and the shifts published for the day. It looks for tickets whose remaining time is shorter than the queue in front of them, or whose assignee is off shift before the target lands.

For each one it proposes a move: a different agent, a different group, or a higher priority. A lead approves in the help desk or from a message in Slack or Teams. The change is applied once, and the record shows the timer, the target, the load that decided it, and who approved.

This is a reference listing. It documents what Fibric would read from Breach Watch and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • SLA targets per priority in Zendesk policies: first_reply_time, next_reply_time, periodic_update_time, and total_resolution_time, in business or calendar hours
  • Ticket metric events through the Zendesk incremental export: activate, pause, fulfill, and breach, per metric
  • Running counters per ticket: reply_time_in_minutes and requester_wait_time_in_minutes, in calendar and business minutes
  • Open, pending, and on-hold tickets per assignee and per group, so load is counted before a move is proposed
  • Published shifts in When I Work or Deputy: start_time, end_time, and whether the shift is open
  • Conversations and their queue in Kustomer, when Kustomer is the help desk

Proposed actions

  • Target capability: propose reassigning a ticket to a named agent on shift with capacity, before its next-reply target is missed
  • Target capability: propose raising the priority so the ticket picks up a shorter target and moves in the view
  • Target capability: propose moving a ticket to another group when the owning group has no one on shift
  • Target capability: propose a message to the lead in Slack or Microsoft Teams listing the tickets nearest breach
  • Target capability: propose a holding reply to the customer when no reassignment can land in time

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Move the ticket before the timer runs out

    A Zendesk ticket has minutes left on next_reply_time and its assignee holds the deepest queue. The operator proposes a named agent with room, and the lead approves from Slack. The ticket is reassigned once.

    With Zendesk, Slack

  • Cover the gap after a shift ends

    When I Work shows the assignee's shift ended before the resolution target lands. The operator proposes reassignment to an agent on the next published shift, with the reason recorded on the ticket.

    With When I Work, Zendesk

  • Raise priority when the group is empty

    Nobody in the owning group is on shift in Deputy. The operator proposes raising the priority and moving the ticket to the group that is staffed, for a lead to approve in Microsoft Teams.

    With Deputy, Microsoft Teams

  • Watch Kustomer queues the same way

    For a Kustomer help desk, the operator reads the queue and SLA state on each conversation and proposes the same moves, with the approval message posted to Slack.

    With Kustomer, Slack

Requirements

  • A help desk with SLA policies and metric events: Zendesk, or Kustomer with SLA policies configured
  • A scheduling connector with published shifts: When I Work or Deputy
  • A messaging connector for the lead's approval channel: Slack or Microsoft Teams
  • Agreed load limits per agent, so capacity means something the operator can count
Authentication
Runs on the credentials of the help desk, scheduling, and messaging connectors you attach. It holds none of its own and moves no ticket unapproved.

Limits

  • Zendesk sets targets per priority value. A ticket with no priority has no target and is not watched until one is set
  • Metric events arrive through an incremental export. A breach already recorded is reported, not prevented
  • Slack allows about one message per second per channel, so proposals are batched into one message, not one each
  • It reads shifts as published. An agent who left early without a schedule change still counts as on shift

Access and pricing

Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Breach Watch ↗

Questions and answers

What does a lead approve before a ticket moves?
One move per ticket: a named agent, a group, or a priority, with the remaining time and the load that decided it. The lead can pick a different agent or decline. Approval applies the change once. Nothing moves before that.
What record is left after a move?
An internal note on the ticket: the metric watched, the target, the time remaining when proposed, the assignee before and after, who approved, and when. In Zendesk the change also appears in the ticket's own audit trail.
Does it reassign tickets on its own?
No. Every reassignment and priority change is a proposal. A person approves it, in the help desk or from the message in Slack or Teams. If nobody approves, the ticket stays where it was and the missed target is recorded as such.
Ask about Breach Watch

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy