Area: mobieusHelp (audit p7) · Surface: mobieusHelp (helpdesk) — SLA watcher / SLA plans · Dimension: feature-improvement · Severity: major
Zendesk and Help Scout pause the SLA clock the moment a ticket goes to 'pending/waiting on customer' and resume it when the customer replies, so agents aren't penalised for the customer's response time. mobieusHelp exposes the exact setting (pause_on_statuses) so an admin reasonably believes the clock pauses on pending — but the watcher counts straight business time from creation regardless. Result: SLA breaches and the dashboard's sla_on_track_pct are systematically wrong, over-reporting breaches for any ticket that legitimately waited on the customer. A half-built, silently-ignored setting is worse than no setting.
Evidence
SLA plans store pause_on_statuses_json (2026-06-01-helpdesk-phase2-sla.sql:31-32) and the admin UI writes it (AdminSlaController.php:131,169) + SlaPlan model encodes/decodes it. But SlaWatcher never reads it: `grep -rn 'pause_on_statuses' src/` shows only the model + admin controller, never the watcher. SlaWatcher::ACTIVE_STATUSES includes 'pending' and 'on_hold' (SlaWatcher.php:35) and recompute calls SlaClock::elapsedBusinessMinutes($start, $now, $bh) from ticket creation (SlaWatcher.php:117) with no subtraction of paused intervals. SlaClock's own header confirms: 'Pause-on-pending (subtracting paused intervals) is deferred to Phase 2.x and lives in the watcher, not here.' — but the watcher never implemented it.
Suggested fix. In SlaWatcher::recomputeOne, load the plan's pause_on_statuses, sum the business-minutes the ticket has spent in those statuses (derive intervals from helpdesk_thread_entries status_changed system events), and subtract from frElapsed/resElapsed before comparing to due times. Or recompute due dates forward each time the ticket leaves a paused status.
Filed by the automated tenant-app audit and adversarially evidence-verified. Status: verified. Open — not yet actioned.
Patrick Bass
@mobieus