The agent trains for a week. The customer has thirty seconds.
Designing the customer engagement layer of an enterprise platform — an omnichannel agent desktop on one side, and on the other an interface a stranger should never have to think about.
GegoSoft designs and builds the interface layer of this platform — the Angular web application, the embeddable chat widget and the Android app. Backend services, architecture and product direction belong to the client. What follows describes the interface design and the reasoning behind it.
- CLIENT
- Australian MSP
- CHANNELS
- Voice, email, chat, bot, social
- WIDGET
- Vanilla JavaScript
- STACK
- Angular, Android
- OUR SCOPE
- UI/UX, web and mobile
One module, two users who have nothing in common
Every screen in this module serves one of two people, and almost every assumption that holds for one is wrong for the other.
Lives here all day
- Trained before their first shift
- Will learn shortcuts and use them thousands of times
- Needs density — more on screen means fewer clicks
- Measured on how fast they resolve things
- Tolerates complexity if it saves seconds
Arrives once, with a problem
- No training, no manual, no second attempt
- Already mildly annoyed before they start
- Needs one obvious action and nothing else
- Judges the provider by this interaction
- Leaves if it takes thought
Density is a feature on one side of this module and a defect on the other. Treating them as one design problem produces something that is cluttered for customers and slow for agents.
The customer side: designed to be unnoticed
The client is a managed services provider. Their customers are hotels, hospitals and corporate campuses reporting faults — a broken intercom, a network outage, a camera that has stopped recording. The person making contact wants that fixed, and has no interest whatsoever in the software either side is using.
A chat widget written in vanilla JavaScript
The embeddable widget goes onto other companies' websites. That single fact rules out most of the convenient choices. It cannot assume a framework is present, cannot collide with the host page's styles, and has to stay small enough that the customer's web team agrees to add it at all.
So it is plain JavaScript — a deliberately different engineering problem from the Angular application it belongs to, solved by different constraints. Appearance is set from a small range of colour presets rather than free-form theming, which is enough for the widget to sit comfortably on a customer's site without becoming a design project every time someone installs it.
A chatbot as the first responder
The chatbot is our design, built on Amazon Q. It handles the opening exchange — identifying who is contacting, what site they are calling about, what has failed — and hands over with that context attached rather than leaving an agent to start from nothing.
Every way in is the same kind of thing
Telephony, email, chat, bot and social are modelled identically as contact points. A phone number and a support address are configured the same way, route the same way, and behave the same way once an interaction begins.
This matters more for the administrator than for anyone else. Channels added over time usually arrive as separate configuration areas with their own vocabulary, and an operations manager ends up learning four systems. Treating them as one object type means adding a channel is a familiar task rather than a new one.
Mail sent to addresses the administrator defines creates tickets automatically, so a message to a support address becomes tracked work without anyone rekeying it. That join between customer engagement and the service desk is configuration, not integration.
The agent side: a shared queue, not an inbox each
The agent queue is a shared inbox. Interactions arriving across every channel land in one place that the team works from together, rather than being distributed into individual mailboxes where they become invisible to everyone else.
That is the right model for a service operation — work is owned by the team until someone picks it up — and it creates the interface problems that follow. An agent needs to know at a glance what is unclaimed, what they are holding, and what has been waiting too long, across channels that arrive at completely different rhythms.
Concurrency
An agent holds one call but may run several chats at once — tested to ten concurrent conversations. Ten live threads on one screen is a real density problem, and the interface has to make it obvious which one is waiting on the agent rather than the customer.
Context on arrival
Details gathered before an agent joins — who is calling, which site, which reference — arrive as context rather than as questions the customer has to answer twice.
Quick responses
Keyed canned replies for the exchanges that repeat dozens of times a day. High-frequency actions that have to be instant or they are not used.
Variables, typed the way people already type
Agents insert stored values into messages using either @ or /
as a trigger, which opens a picker and inserts at the cursor. Supporting both is a
small accommodation of the fact that people arrive with habits formed in different
tools, and neither group should have to unlearn theirs to compose a sentence.
Design decisions
Part of a long-running engagement, delivered as the interface team inside the client's own distributed process.
Two audiences, two rulebooks
Agent screens optimise for density and repetition. Customer surfaces optimise for a single obvious action. The same visual system, applied with opposite priorities.
The widget travels alone
Plain JavaScript, small, style-isolated, preset-themed. Anything that assumes an environment fails on somebody's website, and that failure is invisible to us until a customer reports it.
Channels as one object type
Adding a channel should be a familiar task. Modelling every route in identically means administrators learn the concept once rather than per channel.
Optimise what happens constantly
Quick responses and variable insertion are used dozens of times a shift. Interactions at that frequency have to be instant, or agents route around them and the feature may as well not exist.
Common questions
Can GegoSoft design and build contact centre software?
Yes. We design and build the interface layer of an omnichannel customer engagement module covering voice, email, chat, chatbot and social, plus the embeddable chat widget and the Android app, working alongside the client's backend and QA teams.
Why build a chat widget in vanilla JavaScript?
Because it is installed on other companies' websites. It cannot assume a framework is loaded, must not collide with the host page's styles, and needs to stay small enough that a customer's web team will agree to add it. Framework dependencies turn a widget into something people decline to install.
Should a chat widget support full custom theming?
Usually a small set of presets is better. Full theming turns every installation into a design exercise and produces widgets that clash with the sites they sit on. Presets get the widget close enough to belong on a customer's page without requiring anyone to make design decisions.
Should agent work be assigned individually or held in a shared queue?
A shared queue, for service operations. Work distributed into individual mailboxes becomes invisible to the rest of the team, so nobody can see what is unclaimed or ageing. A shared queue keeps ownership with the team until someone actively takes an item.
How many concurrent chats can one agent handle?
In this system, tested to ten. The practical limit is set less by the software than by the interface: with several live threads, the design has to make it immediately obvious which conversations are waiting on the agent rather than on the customer.
Should a contact centre and a service desk be one product?
Where the same team handles both, yes. Here mail to defined addresses creates tickets automatically and every ticket records the channel it arrived on, so an interaction and a ticket are one object at different stages rather than two records joined by an integration.
More from this platform
Building for agents and customers at the same time?
Tell us who uses each screen and how often. Products that serve trained and untrained users at once usually fail by treating them as one audience, and that is the first thing worth separating.
Start a conversation See all case studies