support dashboard chat #3041
support dashboard chat #3041
Conversation
vladvelici
commented
Dec 18, 2025
vladvelici
commented
- dashboard support chat draft 1
- support chat update
- support chat
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the ✨ Finishing touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
vladvelici
force-pushed
the
support-dashboard-chat
branch
from
a727ed8 to
9748d2a
Compare
m-hulbert
left a comment
m-hulbert
left a comment
There was a problem hiding this comment.
Thanks Vlad.
I've dropped some high-level feedback on this. I think we need to look at the order and flow of information, as well as the prominence we give to certain features over patterns and recommendations.
|
|
||
| This guide covers both sides of a support chat system with Ably, with particular attention to the architectural patterns that make agent dashboards work at scale. | ||
|
|
||
| <div class="mb-6"> |
There was a problem hiding this comment.
We shouldn't need to wrap these in particular classes. Were they made be design or by you?
| meta_keywords: "support chat, help desk, customer support, agent dashboard, Ably Chat, chat SDK, realtime messaging, AI support, chatbot, dependability" | ||
| --- | ||
|
|
||
| Building support chat is unlike other chat applications. The customer-facing widget requires reliable messaging, presence detection, typing indicators, and seamless reconnection. Ably Chat handles all of these challenges for you. The agent dashboard presents a different class of complexity: managing multiple concurrent conversations, discovering new tickets in realtime, coordinating between agents, and integrating automation and AI. |
There was a problem hiding this comment.
I think we should lay out that we're discussing 2 different aspects here - the customer-facing component and a separate dashbaord for agents.
|
|
||
|  | ||
|
|
||
| Delivering chat messages in realtime is key to a smooth support experience. Ably's [serverless architecture](/docs/platform/architecture) eliminates the need for you to manage websocket servers. It automatically scales to handle millions of concurrent connections without provisioning or maintenance. Ably routinely handles 600 billion messages every month globally, across 2 billion devices with median delivery [latencies](/docs/platform/architecture/latency#message-delivery-latency) under 6.5ms even during peak traffic. Ably also handles all of the edge-cases around delivery, failover, and scaling. |
There was a problem hiding this comment.
I think we should stick to the 37ms latency headline from that page for consistency.
|
|
||
| Delivering chat messages in realtime is key to a smooth support experience. Ably's [serverless architecture](/docs/platform/architecture) eliminates the need for you to manage websocket servers. It automatically scales to handle millions of concurrent connections without provisioning or maintenance. Ably routinely handles 600 billion messages every month globally, across 2 billion devices with median delivery [latencies](/docs/platform/architecture/latency#message-delivery-latency) under 6.5ms even during peak traffic. Ably also handles all of the edge-cases around delivery, failover, and scaling. | ||
|
|
||
| ## Scale without limits |
There was a problem hiding this comment.
We switch between 'conversations', 'tickets' and 'rooms' here. I think we need to use 1 term between 'conversations' and 'tickets' and then show that map of 1:1 to a chat room for the recommended architecture pattern.
There was a problem hiding this comment.
I see we cover this in the next section. Maybe swap the order around?
|
|
||
| Ably uses [consistent hashing](/docs/platform/architecture/platform-scalability) to evenly distribute the management of chat rooms across instances, enabling the number of rooms to grow without limit and without causing load spikes. Whether you're managing 100 support conversations or 100,000 simultaneous tickets, the architecture remains the same. | ||
|
|
||
| Ably routinely handles 600 billion messages every month globally, across 2 billion devices. Your support chat benefits from this same infrastructure, ensuring that peak support hours or viral incidents don't overwhelm your system. |
There was a problem hiding this comment.
These stats are repeated from the final paragraph in the previous section.
|
|
||
| Components handle message display with history loading, editing and deletion, reactions, typing indicators, and presence. [Providers](/docs/chat/react-ui-kit/providers) manage themes, avatars, and chat settings. See the [getting started guide](/docs/chat/getting-started/react-ui-kit) for setup details. | ||
|
|
||
| ## Assigning tickets to agents |
There was a problem hiding this comment.
These details are more important than the chat feature above IMO.
|
|
||
| ### Shared inbox queue | ||
|
|
||
| If you don't assign tickets to agents on the server, you can use a shared inbox channel, for example `support:inbox`. This Pub/Sub channel is subscribed to by all agents. When a new ticket is created, publish it to this channel: |
There was a problem hiding this comment.
I think we need some pros/cons or when you'd use one approach over the other.
|
|
||
| Instead of using a channel per agent, use a channel per team or department, for example `support:sales` or `support:engineering`. Follow the same pattern as the server-side ticket assignment to decide which channel to use for each ticket, then apply the shared inbox queue pattern for tickets that reach a team or department. | ||
|
|
||
| ## Agent dashboard <a id="agent-dashboard"/> |
There was a problem hiding this comment.
We have a H2 for 'architecture' further up, but then we're opening this section talking about architecture. Should we have architectural decisions together?
|
|
||
| Each attachment maintains a subscription with new messages, typing indicators, and presence updates. Keeping attachments focused reduces client-side memory, network traffic, and cost. Attach to rooms when agents start working on the relevant ticket and detach when the ticket is resolved, paused, or reassigned. | ||
|
|
||
| ### Agent presence and availability <a id="agent-presence"/> |
There was a problem hiding this comment.
Agent presence was covered in the previous section, so we're repeating slightly different info here.
There was a problem hiding this comment.
I should make it clearer it's two presence sets I'm discussing.
- presence for a ticket (users see agent, agent sees user)
- presence for colleagues - agent sees other agents online (like a mini-slack in the agent dashboard)
|
|
||
| **Room-level presence** shows the customer that their agent is present. When an agent opens a ticket room, they enter presence with their role and name, providing reassurance that help has arrived. Agents can also see if customers are still active. | ||
|
|
||
| ### Push notifications for agents <a id="push-notifications"/> |
There was a problem hiding this comment.
Nothing says agents can't have apps on a tablet, phone, or native apps on laptops. But probably web push, yes.
