Timeline
Four weeks to prepare V1 designs for engineering
Role
Senior Product Designer
Collaboration
Engineering and product teams
Contributions
End-to-end V1 design and ticket-submission flow
Focus
In-product support and conversation continuity
Outcome
A shared ticket-submission pattern; support volume maintained through migration
Overview
Twilio’s Help Center offered customers a dedicated place to get documentation assistance through chat and raise support tickets. As Twilio developed One Console—a unified platform for its products and services—those help capabilities needed to become part of the shared experience.
I led the design of Twilio assistant, the global AI assistant within One Console. For V1, I designed the end-to-end experience, with four weeks to prepare the design for engineering to begin implementation. This case study focuses on bringing ticket submission into the Console without requiring customers to leave their current page or lose their active conversation.
Business requirement
V1 needed to carry forward documentation assistance and ticket creation. Success meant making those capabilities available through Twilio assistant while maintaining customers’ ability to reach support.
Previous customer research supported two priorities relevant to this flow: assistance should stay close to the customer’s work, and customers should still have access to human support when guidance was insufficient.
User risk and technical constraints
The legacy ticket flow opened the external Help Center in a new window. Although this interrupted the task, it left the customer’s original Console page in place. That mattered in a product with deep navigation: moving customers away from their current location could make returning to their work difficult.
With One Console, ticket creation was moving inside the product instead of sending customers to an external support center. Simply opening a full-page form within the Console would replace the page they were working on. Twilio assistant also occupied enough screen space that customers would need to close it to complete the form—and V1 could not save or restore chats, so closing it would erase the active conversation.
The migration therefore put two kinds of context at risk: the customer’s place in the Console and the conversation they had already started. The design needed to make ticket submission usable without requiring customers to give up either.
Designing for continuity
Introduce escalation within the conversation
I used progressive disclosure to connect documentation assistance to ticket creation. Customers could begin by asking for help, then select an action in the conversation to raise a ticket when they needed further support. The form appeared after that choice, rather than occupying the initial help experience.
Open the form without replacing the customer’s workspace
I kept the existing form and opened it in a modal over the Console. The customer’s current page stayed in place, and Twilio assistant remained active underneath.
The modal addressed both risks: it made the form usable without the assistant competing for screen space, and it avoided closing the chat or replacing the underlying page. It temporarily took focus while customers completed the request.
This separated the capability we could reuse—the familiar ticket form—from the transition that needed to change. Ticket creation could move inside the product without depending on saved conversations or a new conversational form.
Bring confirmation and tracking back into the chat
After successful submission, a confirmation appeared in the chat with a link to the request in ticket history. Customers could submit the ticket without being automatically redirected away from their work.
If they chose to follow the link, they navigated to ticket history while Twilio assistant remained open. This made tracking a separate, explicit action: submitting a request preserved the current workspace; checking the request changed the page without ending the conversation.
Business outcome
By the end of beta testing, the project dashboard recorded 17,928 users, 30,255 conversations, and 4,689 tickets.
Ticket submission volume remained consistent with the previous experience after the migration. Maintaining that volume supported the V1 goal of carrying the existing support channel into the new experience.
Product outcome
V1 carried the legacy documentation and ticketing capabilities into Twilio assistant. Customers could submit a request through the familiar form while retaining their Console page and active conversation, then choose whether to navigate to ticket history.
Under heavy delivery pressure, I designed and presented the ticket flow for Twilio assistant. The approach was subsequently reused across the Console as a shared ticket-submission pattern. Links in the new in-product Help Center opened the same flow, and other product teams used it where their customers needed a path to support.
Each team decided where ticket submission belonged in its product. The shared pattern provided a consistent flow behind those entry points without requiring every product to place them in the same way.
Project notes
The migration changed more than where help appeared. The legacy experience preserved the Console page through a separate window; the new in-product journey needed another way to protect that context. Reusing the form while changing its presentation kept V1 focused and preserved the customer’s workspace through submission.
Future improvements
The modal protected the workspace and conversation during ticket submission, but it did not solve chat persistence. Customers could still lose their conversation if they closed Twilio assistant themselves. Restoring the last conversation would be my next priority, so customers could leave and return without depending on the panel remaining open.