Multi-Tenant Contact-Center SaaS Platform

Client Context

A multi-tenant contact-center SaaS platform providing real-time adherence (RTA) — the live view of whether each agent is present, active, idle, or offline — that supervisors rely on to manage service levels, staffing, and coaching. As the platform scaled across multiple tenants, its original presence mechanism could no longer deliver the accuracy and efficiency operations teams needed.

The Problem

• Latency and inaccuracy: a 60-second HTTP heartbeat meant an agent who lost power or disconnected could still appear "present" for up to a minute — supervisors making real-time decisions on stale data
• Backend overhead that scaled the wrong way: fixed-interval polling generated constant request volume regardless of whether anything changed, multiplying across tenants as the fleet grew
• Multi-tenant isolation: any presence transport had to guarantee a device could only ever publish and receive on its own tenant's and its own device's topics, with credentials that could never reach another tenant's data
• Connectivity constraints: the solution could not require customers to open unusual firewall ports or install heavyweight agents

What We Delivered

• Event-driven presence transport on AWS IoT Core using MQTT, replacing fixed-interval HTTP polling with change-triggered messaging plus a guaranteed low-frequency heartbeat backstop
• MQTT-over-TLS on port 443 with ALPN so connections traverse standard corporate firewalls without special egress rules, terminating on a custom AWS IoT Core domain
• AWS IoT Core custom authorizer (Lambda) validating each device's HMAC token and returning an IoT policy scoped to that device's own topics only — isolation enforced at the connection-policy level, not in application code
• MQTT Last Will and Testament (LWT) registered at connect, so a hard disconnect (power loss, crash, network drop) automatically flips the agent offline within seconds
• IoT Core topic rules routing messages to Lambda, deriving device identity from the MQTT topic path (never the payload) and writing presence to a DynamoDB table the live RTA grid reads; telemetry forwarded to the existing SQS pipeline
• Safe, server-controlled rollout via feature flag with automatic HTTP fallback — deployed shadow-first, then phased shadow → feature-flag → pilot → default → retire polling. Infrastructure codified in AWS CDK

Solution & Architecture

Measured Outcomes

Why This Matters

Real-time adherence is only as good as the freshness of its data. By moving from fixed-interval polling to an event-driven MQTT transport on AWS IoT Core, presence became accurate to within seconds instead of up to a minute — a capability polling structurally could not provide — while removing the always-on request floor and enforcing strict per-tenant isolation at the transport layer. It is a clear example of treating connectivity as an engineering discipline: a fully managed broker, security enforced by design, and a shadow-first rollout that reached production with zero disruption. (Cost and latency figures are modeled from a 60-second polling interval and public AWS rates; actual results scale with fleet size.)