Relay is an omnichannel support platform built to unify conversations, ticketing, routing, knowledge, reporting, and team operations. My work focused on making the customer-facing widget and the internal admin experience feel like parts of one coherent product.
Customer conversations, ticket work, routing, live agent handoff, and reporting often live in disconnected tools, forcing teams to rebuild context every time work changes shape.
A support widget cannot just collect messages. It needs to guide people toward the right path, whether that is self-serve help, a ticket, an appointment, or a live agent.
As support volume grows, teams need queue visibility, ownership, status, replies, and operational controls instead of an unstructured stream of incoming conversations.
The product needed onboarding, widget installation, personalization, analytics, and support controls that admins could manage directly without turning every change into a developer task.
Relay brings together the customer layer and the operator layer of support: a public-facing widget that guides conversations well, and an internal system that gives teams structure, visibility, and control as support volume grows.
Built a branded support widget with launcher customization, conversation history, proactive prompts, onboarding-aware empty states, and clearer customer guidance.
Customers can move between conversational help, tickets, appointments, and human support without losing context or starting over in a separate system.
Integrated voice interactions directly into the support experience with clear speaking and listening states plus transcript-aware conversation history.
Built live support workflows around queue visibility, reply handling, join and resolve actions, and a cleaner operator view for active conversations.
Added admin flows for onboarding, widget installation, branding, FAQs, custom instructions, tone controls, and knowledge configuration.
Designed the system around reporting, quality signals, logs, and operational oversight so teams can manage support performance as the product scales.
Building Relay meant solving both product and operational UX problems across customer and admin surfaces.
Challenge: Relay needed to feel like one support product instead of separate chat, ticket, voice, and live-support features placed next to each other.
Solution: I aligned the customer widget, live support state, and internal support flows around a shared session model so people could move between support paths without the product feeling fragmented.
Challenge: The widget supported multiple actions, but they were too hidden. Users could miss important paths like booking time, raising a ticket, or escalating to a human.
Solution: I introduced visible quick actions, cleaner status messaging, and stronger idle-state guidance so the widget communicates its real capabilities before the first message is even sent.
Challenge: Live support needs more than incoming messages. Operators need queue context, session state, reply tools, and clear resolution actions to keep support moving.
Solution: I helped shape the inbox and conversation-management experience around live support sessions, replies, join and resolve actions, and cleaner admin feedback loops.
Challenge: A product like Relay only works if non-technical teams can install the widget, configure support behavior, and manage business context without digging through engineering-only concepts.
Solution: I worked on install setup, onboarding, admin guidance, and clearer configuration screens so support teams can control the product without unnecessary friction.
Challenge: Relay is not a one-size-fits-all chatbot. Different teams need different prompts, FAQs, tone, widget presentation, and support workflows.
Solution: I leaned into configurable onboarding, widget branding, knowledge, and personalization systems so the product can adapt to multiple business contexts while keeping one core support model.
Challenge: Support work often needs to continue where teams already operate, especially inside shared communication tools and operational workflows.
Solution: I added Slack connectivity for routing support activity into team workflows, but kept it as one connected part of the system rather than the center of the product story.
The product direction is about reducing friction on both sides of support: making it easier for customers to reach the right outcome and easier for operators to manage what happens next.
| Metric | Before | After |
|---|---|---|
| Support Entry | Single chat surface | Guided omnichannel support entry |
| Operator Workflow | Message handling only | Inbox, ownership, replies & resolution |
| Action Discovery | Hidden behind icon | Visible quick actions |
| Admin Setup | More manual setup | Guided install and configuration |
As Founding Engineer, I worked across the full product surface: customer-facing chat experiences, live-support workflows, voice interactions, admin tooling, install setup, personalization, and operator-facing systems. The work was less about one isolated feature and more about making the entire support stack feel coherent, operable, and production-ready.