FS-DOC-03Operations
Process Runbook / SOP
SLA Monitoring & Breach Alerting
[YourCompany.com] · Customer Support Department · Prepared by FullSpec · [Today's Date]
This runbook is your day-to-day operating guide for the SLA Monitoring and Breach Alerting automation. It explains what the system does on its own, where your team still needs to act, how to handle things when something goes wrong, and how to keep the process running well over time. FullSpec built, tested, and launched every automated step described here. Your team's only ongoing responsibility is to respond to escalations and keep the underlying data in HubSpot and Zendesk accurate.
01Process overview
Every 15 minutes the automation polls every open ticket in Zendesk, fetches the contracted SLA tier for each client from HubSpot, and calculates exactly how much business-hours time remains before the response or resolution deadline. Tickets are classified as safe, at-risk, or critical. The system then routes graded alerts: a Slack warning to the assigned agent at 75% of the SLA window, a PagerDuty escalation to the on-call support manager at 95%, a timestamped internal note posted directly to the Zendesk ticket, and a breach activity record written to the HubSpot client record if a breach occurs. Every Monday morning a formatted weekly summary is emailed to the support manager via Gmail. The one step that stays with your team is the manager's review and response to a PagerDuty escalation, because that decision requires judgement about the client relationship that the system cannot safely make.
Process name
SLA Monitoring & Breach Alerting
Trigger
Scheduled poll every 15 minutes; fires automatically without any human action
Final output
Graded alerts sent to agents and managers, internal notes posted to tickets, breach records logged in HubSpot, and a weekly Gmail summary delivered every Monday
Agents running
SLA Monitor Agent (polling and classification) and Alert Dispatch Agent (routing and logging)
Tools involved
Zendesk, HubSpot, Slack, PagerDuty, Gmail
Weekly volume
Approximately 200 ticket SLA checks per week
Human checkpoint
Support Manager reviews and responds to PagerDuty escalations for tickets at 95% or in breach
Process owner
[Your name] — Support Manager
Process Runbook / SOPPage 1 of 4
FS-DOC-03Operations
02Step-by-step: what happens and who acts
What you actually need to do: Your team has one human step in this entire process. When the Support Manager receives a PagerDuty escalation alert, they must review the ticket, assess the client relationship context, and decide on the appropriate response action. Everything else listed below runs automatically without any input from your team.
Step
What happens
Who acts
Type
1
The automation platform triggers a scheduled poll every 15 minutes. It retrieves all currently open tickets from Zendesk, collecting each ticket's ID, creation timestamp, assigned agent, and the client identifier attached to the ticket.
SLA Monitor Agent
Automated
2
For every ticket retrieved, the SLA Monitor Agent queries HubSpot using the client identifier to look up the contracted SLA tier, the response window, and the resolution window that applies to that client.
SLA Monitor Agent
Automated
3
The SLA Monitor Agent calculates how many business hours have elapsed since the ticket was created and computes the exact time remaining before the contracted deadline, applying the correct business-hours calendar and timezone for that SLA tier.
SLA Monitor Agent
Automated
4
Each ticket is classified as safe, at-risk, or critical based on the percentage of its SLA window consumed. Tickets below 75% are marked safe. Tickets between 75% and 95% are marked at-risk. Tickets at or above 95% or already in breach are marked critical.
SLA Monitor Agent
Automated
5
When a ticket crosses the 75% threshold, the Alert Dispatch Agent sends a structured Slack warning message to the agent assigned to that ticket. The message includes the ticket number, the client name, the SLA tier, and the exact minutes remaining.
Alert Dispatch Agent
Automated
6
If a ticket reaches 95% of its SLA window without a resolution or a status change, the Alert Dispatch Agent fires a PagerDuty incident to the on-call support manager. The PagerDuty alert routes according to the escalation policy and on-call schedule configured during setup.
Alert Dispatch Agent
Automated
7
The Support Manager receives the PagerDuty escalation, reviews the ticket in Zendesk, considers the client relationship context, and decides on the appropriate action. This may include directly contacting the client, reassigning the ticket, or authorising an SLA exception.
Support Manager
Human
8
After each poll cycle the Alert Dispatch Agent posts a timestamped internal note to every ticket that triggered an alert, recording which alert level was sent, who was notified, and at what SLA percentage. This creates an automatic audit trail with no manual effort.
Alert Dispatch Agent
Automated
9
If a ticket has breached its SLA window, the Alert Dispatch Agent creates a breach activity record on the corresponding HubSpot client record, capturing the ticket ID, SLA tier, the number of minutes overrun, and the exact timestamp of the breach.
Alert Dispatch Agent
Automated
10
Every Monday morning the Alert Dispatch Agent compiles the previous week's breach and near-breach data and sends a formatted summary email to the support manager via Gmail, including breach count, affected clients, and a breakdown by SLA tier.
Alert Dispatch Agent
Automated
Process Runbook / SOPPage 2 of 4
FS-DOC-03Operations
03Handling exceptions
Situation
What the system does
What you do
A ticket has no client identifier, or the identifier does not match any record in HubSpot
The SLA Monitor Agent cannot fetch an SLA tier for that ticket. It flags the ticket as unclassified and posts an internal note in Zendesk stating that the SLA tier lookup failed and the reason. The ticket is excluded from threshold calculations for that cycle.
Open the ticket in Zendesk and confirm the client identifier field is populated correctly. Open the corresponding HubSpot record and verify the client ID matches exactly. Correct whichever record is wrong and the next poll cycle will pick up the ticket normally. Contact support@gofullspec.com if the mismatch persists after correction.
The same ticket appears to trigger duplicate Slack alerts for the same threshold crossing
This can occur if the ticket's status changes and reverts within a single poll window, causing the threshold check to re-evaluate. The system logs each alert sent in the internal Zendesk note, so duplication is visible in the audit trail.
Check the internal note on the ticket to confirm whether multiple alerts were genuinely sent. If they were, note the time and ticket ID and report it to support@gofullspec.com so the deduplication logic can be reviewed. No immediate client action is required.
A client SLA tier is recorded inconsistently across Zendesk and HubSpot, resulting in a classification that does not match the actual contract
The system uses the HubSpot record as the source of truth. If that record is wrong, the time-remaining calculation and alert thresholds will be based on the incorrect tier, and alerts may fire too early or too late.
Update the SLA tier field on the HubSpot client record to match the signed contract. If you are unsure which tier applies, check the original contract document. Do not update the Zendesk field only, as HubSpot is the system of record for tier data.
A PagerDuty escalation fires but the assigned on-call manager does not acknowledge or respond within the escalation window
PagerDuty follows its configured escalation policy. If the primary on-call contact does not acknowledge the alert within the defined timeout period, PagerDuty automatically escalates to the secondary contact defined in the on-call schedule.
Ensure the PagerDuty on-call schedule is always kept current, especially during holidays or planned leave. If no acknowledgement occurs and the escalation chain is exhausted, PagerDuty will mark the incident as unacknowledged. Review the PagerDuty incident log and respond directly. Contact support@gofullspec.com if the escalation policy needs to be updated.
Zendesk is unavailable or returns an error during a scheduled poll
The automation platform detects the failed API call and retries up to three times with a two-minute gap between attempts. If all retries fail, the poll cycle is skipped and an error is logged in the automation platform's error log. No alerts are sent for that cycle. The next scheduled poll at the 15-minute mark will attempt again as normal.
If Zendesk is experiencing an outage, monitor the Zendesk status page and your automation platform's error log. During an extended outage, assign a team member to check the ticket queue manually at 30-minute intervals and escalate any critical tickets by Slack or phone. Once Zendesk recovers, the automation resumes without any action needed from your team.
A ticket that should have received a Slack warning alert was resolved or closed before the alert was delivered, meaning the agent never saw the warning
The Alert Dispatch Agent checks ticket status before sending. If a ticket is already resolved or closed at the point of dispatch, no Slack message is sent and the internal note records the alert as suppressed because the ticket was resolved.
No action is required. This is expected behaviour. If you see a pattern of tickets being closed at the last moment without agents acting on warnings, review whether agents are genuinely resolving tickets promptly or closing them to avoid SLA recording. The HubSpot breach log and weekly Gmail report are the best places to spot this pattern.
Process Runbook / SOPPage 3 of 4
FS-DOC-03Operations
04Who to contact and when
Fill in the rows marked with placeholders once your team is confirmed. The FullSpec rows are fixed. Use this table as the single reference point for anyone on your team who needs to know who to call when something is not working.
Role
Name
How to reach them
Process owner (Support Manager)
[Your name]
[Your email or Slack handle]
Support Lead (day-to-day operations)
[Rep name]
[Rep email or Slack handle]
PagerDuty primary on-call contact
[On-call name]
Via PagerDuty app or [phone number]
PagerDuty secondary on-call contact
[Backup name]
Via PagerDuty app or [phone number]
FullSpec builder (automation build, config changes, and threshold updates)
FullSpec team
support@gofullspec.com
FullSpec support (errors, unexpected behaviour, and integration issues)
FullSpec support
support@gofullspec.com
05Ongoing maintenance
Any time a new client is onboarded or a client's SLA tier changes
Update the SLA tier field on the client's HubSpot record immediately. Confirm the client identifier in Zendesk matches the HubSpot record exactly. If a new tier is being introduced that does not exist in the current configuration, contact FullSpec at support@gofullspec.com before go-live so the threshold and calendar logic can be extended.
Support Lead or Process Owner
Any time alert message wording or the weekly report format needs to change
Contact FullSpec at support@gofullspec.com with the requested wording changes. Do not attempt to edit alert templates directly in Slack or Gmail without FullSpec involvement, as the message structure is tied to data field mappings that need to stay aligned.
Process Owner, actioned by FullSpec
Monthly spot-check (first Monday of each month)
Review the weekly Gmail summary report for the previous four weeks. Check that breach counts are plausible given your ticket volume. Open two or three recent breach records in HubSpot and confirm the data looks correct. If anything looks inconsistent, report it to FullSpec.
Support Manager
Weekly error log review (every Monday, alongside the Gmail summary)
Check the automation platform's error log for any failed poll cycles, skipped alerts, or API errors from the previous seven days. A small number of transient errors is normal. More than three consecutive failed cycles for the same tool warrants a message to support@gofullspec.com.
Support Lead
Any time a team member joins, leaves, or changes role
Update the PagerDuty on-call schedule and escalation policy to reflect the change. Update the contact table in this document. If the outgoing person held Zendesk or HubSpot admin credentials used by the integration, notify FullSpec at support@gofullspec.com so API access can be reviewed and rotated if needed.
Process Owner, actioned with FullSpec
Quarterly volume review (every three months)
Compare the current weekly ticket volume against the baseline of approximately 200 checks per week used to scope this build. If volume has grown significantly, review whether the 15-minute poll cadence is still sufficient and whether PagerDuty escalation thresholds need recalibrating. Contact FullSpec to discuss any adjustments.
Support Manager, reviewed with FullSpec
The most common maintenance issue for this process is a mismatch between the client identifier stored on a Zendesk ticket and the corresponding HubSpot record. This typically happens when a new client is onboarded and the identifiers are entered slightly differently in each tool, or when a client record is merged or renamed in HubSpot without updating the Zendesk tickets. When this mismatch exists, the SLA tier lookup fails silently and the ticket receives no alerts. Check HubSpot client ID consistency whenever you onboard a new client, and run a spot-check any time you notice a client's tickets are not appearing in breach reports as expected.
Process Runbook / SOPPage 4 of 4