CX Pulse: a push-driven Genesys Cloud presence wallboard, team by team

Every contact centre morning starts the same way. The phones open at nine, the forecast says thirty agents, and the team leader wants to know – right now – who is logged in, who is On Queue, who is still in Meeting from the stand-up and who has quietly sat in Break for forty minutes. They do not want a report about yesterday. They want line-of-sight of the floor, organised the way they think about it: by team, by Genesys group, by routing queue.

That was the brief for CX Pulse. It is a wallboard, not a reporting tool: one dot per agent, clustered by state, with a gauge for the overall shape of the floor, a strip of KPI tiles, a card for each group or queue and a ticker of state changes as they happen. Its design principle is simple – the moment an agent goes Available, joins the queue, steps away or misses an offered interaction, the board should change, pushed by Genesys rather than polled for.

The first insight came from the Genesys data model itself. What a supervisor calls an agent’s “status” is really three independent things. There is the system presence – the primary category such as Available, Away, Busy, Meal, Meeting or Training. There is the organisation presence – the secondary status your administrators define, such as “Comfort Break” or “Customer Calls”, which sits under a primary. And there is the routing status, which describes the agent’s relationship with ACD and is set by the platform, not by the agent.

Genesys reports these separately, so CX Pulse tracks them separately and derives a display state on every change. A routing status of Not Responding becomes Ineligible – the system removed the agent from routing after a missed offer. Idle, Interacting or Communicating becomes On Queue. Off Queue, or no routing status at all, falls back to the system presence. That fallback matters: when an agent leaves the queue, the board reverts them to their real presence instead of leaving them visually stuck On Queue, and a presence change while on queue updates the label without knocking them out of On Queue.

Secondary statuses need one more step. Live events reference presence definitions by ID, so at boot the app caches the organisation’s full set of presence definitions – label and primary for each – and resolves every event through it. A custom secondary keeps its own name in the agent tooltip and still lands in the right family on the gauge. Along the way we also found that the primary enum arrives in different spellings depending on the surface, so a normaliser folds them into one key set before anything is classified.

A wallboard is only as good as its starting picture, so CX Pulse boots from the Genesys Cloud Platform API before it streams anything. A radar splash narrates each step: the organisation profile from /api/v2/organizations/me, the presence definitions from /api/v2/presencedefinitions, the full agent roster with current state from /api/v2/users?expand=presence,routingStatus (paged 100 at a time), then groups and their members, and finally the routing queue list.

Group membership resolves in parallel batches of eight, and a group whose member fetch fails is logged, counted and surfaced in the status bar rather than silently lost. Queue membership is deliberately lazy: /api/v2/routing/queues/{id}/members runs only the first time a supervisor shows that queue, then it is cached for the session, so boot cost stays at one listing even in an organisation with hundreds of queues. Every list call pages 100 at a time and, on a 429, waits for Retry-After plus jitter before retrying.

After boot, CX Pulse creates a notification channel with POST /api/v2/notifications/channels and the browser opens its WebSocket directly to Genesys. Each watched agent costs two topics, v2.users.{id}.presence and v2.users.{id}.routingStatus. Genesys limits a connection to 1,000 topics, so a single channel can stream 500 agents – and that budget shaped the whole user experience.

Every group and queue starts hidden, which means zero subscriptions. Showing a team pushes its members onto the channel; hiding it takes them off. Each toggle issues a PUT that replaces the entire topic list, so the subscription set is always an exact union of what is on screen and can never creep past the cap. An agent who appears in both a group card and a queue card still costs only two topics. Hiding everything issues a DELETE that clears the subscriptions. The status bar shows the budget in plain sight, for example “412 / 1000 subscriptions”.

Two details keep the stream trustworthy. After each successful PUT, the app re-fetches presence for the just-subscribed users over REST, in chunks of 50, so a change that happened between roster load and subscription activation is not silently lost. And the channel lifecycle is handled for the user: the client answers Genesys heartbeats, renews pre-emptively when v2.system.socket_closing warns that the channel is about to expire, and after an unexpected close creates a fresh channel rather than retrying a stale one.

The sidebar gauge is a 270° instrument arc covering every agent in visible groups and queues, with stacked segments for Available, On Queue, Away and Busy and the unfilled remainder showing the offline share. Above the content pane, nine KPI tiles – Online, Available, On Queue, Ineligible, Away/Break, Meal, Meeting, Training and Overdue – classify each logged-in agent exactly once from the derived display state. Hover over any tile and it lists precisely which agents it is counting, with their time in state.

There are two deliberate “overdue” rules. On group cards, an agent held in an Away or Busy family state for more than 15 minutes gets a highlighted ring – “glance at this person now”. The KPI Overdue tile uses a separate 61-minute rule across all non-productive states, the classic “forgot to log off” check. Same word, different jobs, both explained in the user guide so nobody has to guess.

Along the bottom, a newsroom-style ticker records each meaningful transition as a chip – agent name, arrow, new state – with recent changes only and per-agent de-duplication of repeated frames. Hover pauses it and shows the exact wall-clock time the change arrived; click a chip and the grid scrolls to that agent’s dot. If the agent is in a hidden team, the relevant sidebar rows flash instead, a quiet hint to show that group.

Genesys Cloud already gives supervisors strong tools here, and CX Pulse is designed to sit alongside them. The Agents Status Summary and Detail views show agent statuses in real time for current date ranges, with Duration, Timeline and Log In – Log Out displays, primary statuses broken down by secondary statuses, filtering, grouping and export. From the Detail view, a supervisor with the right permissions can change an agent’s status or log them off. Performance dashboards add Metric, Chart, Web Content and Agent Status widgets that refresh in near real time.

What CX Pulse adds is a particular shape of view: a dedicated wallboard, organised by Genesys group or routing queue, where every pushed event moves a dot, flashes a card and lands in a ticker, and where Not Responding is counted apart from On Queue. It is also intentionally narrow. It is read-only by construction – it never changes an agent’s state – and it keeps no history: there is no export, because the data is a moving target. For history, analysis and agent control, the native views remain the right place.

Security was part of the design from the first workshop, not a later hardening pass. CX Pulse signs in with an OAuth client-credentials grant whose role needs only view access to users, groups, routing queues and presence definitions. The only POST, PUT or DELETE calls it makes manage its own notification channel. Credentials stay on the server side of the app, the browser holds only an opaque session, and presence data is displayed and then superseded by the next event – nothing about your agents is stored anywhere.

CX Pulse went through the same QVCCS lifecycle we apply to client work: requirements captured as supervisor user stories, a design reviewed by design authority, a build peer-reviewed against the Senior Platform Practice Lead’s engineering standards, and testing that deliberately included the failure paths – channel expiry, missing presence definitions, a 403 on queues, a group whose members will not load. Behind it sits the bench: Solution Architects, Senior Developers, Systems Integration Testers and Support Engineers who live in the Genesys Cloud APIs every day.