Loading page content
Tello Cast
A drop-in chat and support SDK, running inside other companies' apps
- Industry
- Customer support software
- My role
- Front-end engineer — agent console and the real-time layer
- Platforms
- Web, SDK
01
Overview
Most companies bolt support on: a separate portal, a different login, an email address that goes somewhere nobody watches. This platform does the opposite. It gives an organisation the machinery — agents, tickets, chat history, supervisors, broadcast messaging — and then ships an SDK so all of it appears inside their own app and website.
That distribution model is what makes it interesting to build. The product is not a website people visit. It is a component that lives inside other people's software, and it is now running inside large fintech and logistics products where a support outage is not a quiet problem.
I worked on the web side: the console agents and supervisors sit in all day, and the real-time layer underneath it.
02
The challenge
Software that ships inside somebody else's product is held to a standard ordinary software never is.
It runs on their release schedule, not yours. It sits next to their code, so it cannot conflict with their versions or their global state. It has to be small, because the host's bundle size is their problem and your SDK is a line item in it. And when anything goes wrong, the sequence is always the same: the customer blames the host app, the host blames the SDK, and you are explaining yourself to someone whose users are already unhappy.
The console has a different problem. An agent under load is not browsing — they are holding several conversations at once, each with its own history and its own waiting customer. A layout that is merely complete is a layout that costs them seconds per conversation, and those seconds are the whole product.
03
Goals
- 01Keep the console usable when an agent has several live conversations at once
- 02Survive the disconnections that are normal on real networks, without losing messages
- 03Stay small and well-behaved as a guest inside somebody else's app
- 04Give supervisors a view of what is happening without interrupting the people working
04
My role
I built the web front end — the agent and supervisor console — and worked on the real-time layer underneath it: the socket connection, message delivery, presence, and the reconnection behaviour that decides whether a chat feels reliable or not.
Technical breakdownArchitecture, implementation and the decisions underneath the result
Product thinking
The design question for a support console is not what the data model contains, it is what the agent's next action is. Everything else follows from that.
So the layout is organised by conversation rather than by record: what is waiting, what is mine, what needs an answer now. History is present without being asked for, because the first thing an agent does is work out what happened before. And the state of the connection is shown honestly — an agent who cannot tell whether their reply sent will send it twice, and the customer receives it twice.
Architecture
A React console over a persistent WebSocket connection, with OpenTok carrying audio and video where a conversation needs to escalate past text.
The split matters and is the same lesson that shows up in every real-time product: messages and media are different problems. Sockets are excellent at ordered, reliable, small payloads — chat, presence, typing, ticket state. They are the wrong tool for a live stream, which needs a transport that tolerates loss rather than retrying it. Handing media to a specialist stack kept the socket layer simple enough to reason about.
A product that lives inside other products
The console is ours; the surface the customer sees belongs to the host application.
- 01Host appCustomer's own mobile app or websiteChat SDK embedded
↳ Their release cycle, their bundle
- 02TransportWebSocketPresenceMessage deliveryTicket state
- 03MediaOpenTokAudio and video escalation
↳ A different problem from messaging
- 04ConsoleAgent workspaceSupervisor viewHistory and analytics
Technical implementation
The reconnection behaviour took the most care, because it is where chat products quietly lose trust. A socket on a real network drops constantly — a tunnel, a lift, a laptop sleeping — and the naive handling produces the two worst outcomes: messages that vanish, and messages that arrive twice.
So sending is treated as intent rather than as an event. A message is held until it is acknowledged, retried on reconnect, and de-duplicated on the way in, so an agent who hits send during a two-second outage gets exactly one message delivered rather than none or two.
The console itself is built to keep several conversations open without re-rendering the whole workspace when one of them receives a message. Under load that difference is the difference between a tool and an obstacle.
Difficult problems, and what I did about them
Chat that neither loses nor duplicates messages
- Problem
- Mobile and office networks drop sockets constantly, and the obvious handling either discards the message in flight or sends it twice on reconnect.
- Approach
- Treated an outbound message as intent held until acknowledged, replayed on reconnect, and de-duplicated on receipt — rather than as a fire-and-forget event.
- Trade-off
- More state to hold on the client than a naive implementation needs.
- Outcome
- A two-second outage stopped being visible to either the agent or the customer.
Being a good guest in someone else's application
- Problem
- An SDK that is heavy, or that conflicts with the host's dependencies, becomes the host's problem — and the host is the customer.
- Approach
- Kept the embedded surface deliberately small and its dependencies contained, and left media to a specialist stack rather than shipping a second transport inside the SDK.
- Trade-off
- Less freedom in the embedded UI than a self-hosted product would have.
- Outcome
- The integration stayed something a host team could accept without a long negotiation.
UI / UX
The console is organised by conversation, not by table. What is waiting, what is assigned to me, and what needs an answer now are visible without navigating. Connection state is shown honestly rather than optimistically, because an agent who cannot tell whether a reply sent will send it again.
Integrations
- WebSocket transport — chat, presence and ticket state
- OpenTok — audio and video escalation
- Embedded SDK surface inside host mobile apps and websites
05
What came out of it
Stated qualitatively on purpose. Invented percentages are the easiest thing in the world to write and the fastest way to lose a technical reader.
Running inside large fintech and logistics products
The integration standard for those environments is high, and support failures there are visible to a lot of people at once.
Reconnection stopped being visible
Messages sent during a brief outage arrive exactly once, which is what makes a chat product feel trustworthy.
The transport stayed simple
Keeping media on a specialist stack meant the socket layer did messaging and did it well.
06
Technology
Front end
- React
- JavaScript
Real-time
- WebSockets
- OpenTok
07
Final outcome
A support platform that reaches its users as a component inside other companies' products — where the engineering standard is set by the host, and where the difference between a good chat product and a bad one is entirely in how it behaves when the network misbehaves.
If this sounds familiar
Building something similar?
Most of these problems show up again in different clothes. Describe yours and I will tell you what I would look at first.