AI customer support that knows when to act and when to step aside.

Because Relay is an independent product concept, the starting point was not a set of client findings. I framed the product around familiar support situations in subscription businesses: failed payments, account access, plan changes and refund requests.

• I kept the conversation at the centre of the workspace and didn’t give AI its own separate area, so agents never lose context.
• I added confidence indicators and an explicit human handover so automation never dead-ends a customer.
• I limited Relay to approved knowledge sources so every answer can be traced and trusted.
• I built shared status patterns (synced, low confidence, escalated) so they read the same everywhere.

I organised Relay around the work support teams already do: respond to customers, check trusted information, understand account history and step in when automation reaches its limit.
Rather than separating AI into its own world, each product area was designed to strengthen the same support conversation.

I brought customer context, trusted knowledge, payment activity, AI reasoning and human handover into a single workspace, so agents can resolve issues without switching between tools.
The information architecture puts the conversation at the centre, with the right context and actions at hand, helping agents move from question to resolution faster.

Automation becomes risky when the source behind an answer is unclear or out of date. I designed the knowledge area as a controlled source of truth, where support teams can connect existing documentation, organise articles and decide what Relay is allowed to use.

I designed the analytics workspace to make Relay’s performance easier to understand across every customer conversation. Instead of presenting activity as a collection of disconnected numbers, the screen brings resolutions, handovers and recurring support issues into one clear view.

Customer information rarely lives in one place. Payment activity, product documentation, account details and team communication are often spread across several platforms.

I designed the integrations experience to bring those systems into Relay without making setup feel like a technical project. Each connection clearly explains what information Relay can access, its current status and when the data was last synchronised.

As the product expanded across conversations, knowledge, analytics and integrations, I created a reusable design system to keep the experience consistent. The system brought the product’s colours, typography, spacing, controls and interface patterns into one shared foundation.

Beyond visual consistency, I used repeated status styles and interaction patterns to make Relay easier to understand. A synced source, low-confidence answer or human escalation is communicated in the same way wherever it appears.

I translated Relay’s core capabilities into a simple, benefit-led story: connect the tools a team already uses, resolve routine conversations with trusted information and hand sensitive issues to people with the full context preserved.

Outcome: a complete product system covering conversations, knowledge, analytics and integrations, plus a reusable design system and a go-to-market narrative. The next step is usability testing of the handover flow with support teams.

Relay reinforced that designing for AI is not simply about making automation feel intelligent. It is about deciding what the system should handle, showing the information behind its decisions and creating a clear path to human support when confidence is low.

The project pushed me to think beyond individual screens and consider how conversations, customer context, trusted knowledge and business systems work together as one experience.

If I continued developing Relay, the next step would be testing the concept with support teams and customers—particularly the handover flow, confidence indicators and the amount of context agents need to act with confidence.