An SLA, or service level agreement, is a promise about time. "We'll fix potholes within three business days." It sounds simple until you try to calculate it.
What if the report came in at 4:55 p.m. on a Friday? What about the Monday holiday? What about the night the clocks change? Get these wrong and your reports show crews as "late" when they weren't working, and residents get due dates the city never agreed to.
Two clocks: acknowledge and resolve
Each request type in Sentra 311 has two targets:
- Acknowledge. How quickly someone should look at it. This counts business hours. "Acknowledge within 8 business hours."
- Resolve. How quickly it should be fixed. This can be in hours or business days. "Resolve within 3 business days."
A request filed Friday at 4:55 p.m. with an 8-business-hour acknowledge target is due Monday afternoon, not Saturday morning.
Business days end at closing time
When the target is in business days, the request is due at the end of the last business day, at closing time. "Three business days" from Tuesday morning means Friday at closing, not Friday at 9 a.m. That matches how crews actually plan their week.
Your hours, your holidays, your time zone
Each city sets its business hours and its holiday list in the portal. All due dates use the city's time zone, including daylight saving time changes. The SLA calculation is one shared piece of code used everywhere, from the queue to reports to resident-facing due dates, so the numbers always agree.
On hold pauses the clock
Sometimes work has to wait: a part is on order, or a contractor needs to come out. Putting a request on hold, with a reason, pauses the clock. When it comes off hold, the remaining time picks up where it left off. Requests on hold don't count as past due.
What staff see
The queue shows time left on each request: "5 days left," "Due today," "Overdue 8 hrs." Past-due requests are highlighted and counted in the summary at the top of the queue. Staff can filter by SLA state, and sort so the most urgent work comes first.
Escalations
An SLA is only useful if someone notices when it's missed. Escalation rules send a notice when a request breaks its SLA. Rules can be set by department and notify a specific person, such as the public works supervisor. Each escalation is logged, so the same request doesn't send the same notice twice.
Escalations should be rare. If they're constant, the target is probably wrong, and the reports will show it.
Reporting on SLAs
Reports show the share of requests closed within their SLA, by department, request type or district, in calendar time or business time. The department dashboard shows SLA met for the period, how many requests are past SLA right now, and the trend over twelve weeks.
Priority and SLAs
Each request has a priority: urgent, high, normal or low. Priority affects sort order in the queue and is shown as a colored chip with a word, so color is never the only signal. Urgent requests are marked in the queue so dispatchers can see them at a glance.
Targets are set per request type, so "missing stop sign" and "faded crosswalk" can have very different due dates even though both are traffic signs.
Checking a due date
Every request shows its due date and the time left in the queue and on the request page. If a due date ever looks wrong, check the request type's targets and the city's business hours and holidays in the portal; those three settings explain every due date the system calculates.
Setting targets you can meet
A few suggestions from cities that do this well:
- Start with what you do today. Look at how long requests take now and set targets slightly better, not wildly better.
- Use business days for repairs, hours for safety. A missing stop sign needs a target in hours. A faded crosswalk can be in business days.
- Keep the acknowledge target short. Residents care most about knowing someone saw it.
- Review quarterly. If a type is always late, look at staffing or the target. If it's always early, tighten it.
An SLA isn't a stick. It's a shared agreement between the city, its crews and its residents about what "on time" means, calculated the same way every time.