SLA design and milestone dates
How to define a useful GTM service level, capture the dates that explain waiting time, and keep overdue work visible without confusing it with failure.
On this page
An SLA is a promise about elapsed business time. It is useful only when the system can show when the clock started, when it paused, and what event stopped it.
Specify the clock
| Field | Example |
|---|---|
| Start event | decision.final_outcome = route-to-seller |
| Target event | seller_accepted_at is present |
| Clock | Business hours, local to the assigned team |
| Pause | Waiting for a customer reply, if policy allows |
| Overdue | Target event absent after the allowed time |
| Escalation | Owner's manager after one business hour overdue |
Avoid “within four hours” without saying whether weekends count or which timezone owns the clock.
Capture the milestone chain
decision_at → workflow_started_at → owner_assigned_at → accepted_at → completed_atAdd suppressed_at, expired_at, and failed_at when those states apply. Dates should describe events, not current labels. A status of working cannot tell you how long the record waited before ownership.
Overdue handling
Overdue work needs a visible state and a bounded escalation. Escalate once, then set the next owner. Repeated alerts do not improve service. If the workflow cannot find an owner, send it to an operations queue and preserve the original due time.
Platform notes
Salesforce Flow can write milestone timestamps as part of record automation; Salesforce reports can then group by those fields. HubSpot workflows can set date properties and create tasks, while the exact available SLA and reporting features vary by subscription. Keep the event model in your field dictionary and verify the current platform behavior before configuring it. The Salesforce Flow overview and HubSpot workflow guide are the starting points.
Treat pauses as events
If the clock can pause, define the permitted pause reasons and record paused_at, resumed_at, and accumulated paused time. Do not infer pauses later from a changing status field. Waiting on the customer may pause one service promise while waiting on an internal owner should keep another clock running.
Report the eligible population, not only the average response time. Show the number due, completed in time, completed late, still open, paused, and excluded. Pair the median with a high percentile so a small group of abandoned records is not hidden by many fast completions.
Review before launch
Use historical records to test the proposed threshold. Confirm business hours, time zone, holidays, ownership changes, reopen behavior, and what happens when the due date passes. Give managers a view of work approaching the threshold, not only work already late. The best SLA control helps someone act before the promise is missed.
Related: Status and milestone-date modeling, Workflow states and job history, and GTM metric dictionary template.
Related guides
FAQ
- What makes a GTM SLA useful?
- A useful SLA names the start event, business clock, owner, target event, pause rules, and escalation path. A single average response time is a metric; it is not an operating contract.
- Is an overdue item a failed workflow?
- No. Overdue means the target time passed without the target event. Failure means the system could not execute. Keep both states so the team can separate capacity or ownership problems from technical problems.
Get the next guide
New guides and the occasional note on GTM tooling. Don't worry, I won't drop you into a three-month nurture.