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 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?
There was a problem hiding this comment.
It just looks better wrapped as it adds some margin at the bottom. Otherwise there is no vertical whitespace between image and text.
I'm happy to follow whatever style we should follow but simply putting the picture without any wrapping seems to give a poor result.
I made the mockup myself, I had feedback on another guide to produce these. Happy to get them changed with design-provided ones everywhere.
| 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?
There was a problem hiding this comment.
swapped sections (initially, then removed the standalone scale section since it wasn't adding value - moved any bits of useful content in the 'why ably' section
|
|
||
| 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.
There was a problem hiding this comment.
merged paragraphs
|
|
||
| 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.
There was a problem hiding this comment.
The guide flow is (top-level sections):
- customer-facing widget, includes how a ticket is created and the chat features,
- ticket allocation,
- agent dashboard.
Do you think it should be different?
|
|
||
| ### 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.
There was a problem hiding this comment.
I'm not quite sure what to add in a pros/cons list for those, as this choice is about how their system works, not how they use Ably.
I think it really depends on the application and how people want it to work. The two suggestions here differ technically but they are just two ways to handle agent-ticket allocation - to show we support both use cases.
|
|
||
| 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?
There was a problem hiding this comment.
Doesn't talk about architecture much? It uses the word but says little else than just setting the context.
|
|
||
| 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.
vladvelici
force-pushed
the
support-dashboard-chat
branch
from
4f3e02d to
ab1e56d
Compare
|
I've address all comments that I could, left questions for some. Did a few cycles of AI reviews as well so moved some sections around. @m-hulbert When re-reviewing, would you please be able to go through the old comments and mark as resolved those that you think are now ok? |
vladvelici
force-pushed
the
support-dashboard-chat
branch
from
ab1e56d to
2785b71
Compare
vladvelici
force-pushed
the
support-dashboard-chat
branch
from
2785b71 to
2db1b92
Compare
