Return to work
CASE STUDY / 03Secure Email Communication
Sonnet's digital-first positioning required a way for policyholders to send account-specific inquiries by email. Customers emailing about their policy were redirected to chat or phone and had to repeat their explanation across channels. As Lead UX, I designed an authenticated contact flow that identifies policyholders, captures explicit email consent for email disclosure, and routes structured account inquiries directly to customer service heroes for resolution. The published account reports 1 touchpoint to customer resolution, 100% accessibility improvement, and 100% self-serve improvement — calculation, baseline, sample size, and reporting period are not provided for any figure.
Sonnet — authenticated contact landing and note entry
- Problem
- Account-specific email inquiries could not be handled in channel — customers were redirected to chat or phone and required to repeat their explanation across touchpoints.
- Why it mattered
- Repetition across channels created friction and accessibility barriers. Sonnet's fully digital positioning required an async, account-specific contact option when alternative channels were not practical.
- My responsibility
- Led UX: service-team contextual research, proxy usability testing, sketching entry alternatives and form structure, low-fidelity prototype and UX documentation iteration, supporting UI, technology, and stakeholder handoff.
- What changed
- An authenticated Send us a note flow — identity verified through login, explicit email consent captured for email disclosure, inquiry structured by topic and policy, and continued conversation by email with the service hero.
The problem
Customers contacting Sonnet about account-specific policy questions by email were redirected to chat or phone because account details could not be discussed over unverified email. This forced customers to repeat their explanation across channels, creating friction and accessibility barriers for those for whom alternative channels were not practical.
- 01
Customer sends email
Customer emails Sonnet to explain an account-specific policy question — no authenticated async channel exists to handle it. - 02
Account detail blocked
Policy-specific information cannot be disclosed over unverified email — the inquiry cannot be resolved in channel. - 03
Redirect to chat or phone
Customer is redirected to chat or phone. The published account describes 3 touchpoints before; no method, sample, or reporting window is provided by the source. - 04
Repeat explanation
Customer must re-explain their situation in the new channel. Accessibility barriers arise for those for whom alternative channels are not practical.
Channel redirection and repeated explanation were the core breakdown — no async, account-specific route existed for policyholders who could not easily use chat or phone.
Limited time and budget meant direct customer interviews were not possible. Analytics instrumentation was not in place at the start of the project. The solution needed to work within Sonnet's existing tools and technology. Service heroes acted as proxy participants throughout discovery and usability.
Organized a team huddle and received the lead service hero's presentation on pain points. Conducted a contextual interview with a senior service hero to understand service interactions and the language customers used. Spoke with the VP of Digital about customer interview feasibility. Explored entry alternatives through sketches and ran two rounds of proxy usability with service heroes — no participant counts or measured results are available from the source.
The decisions
Three consequential design choices defined how Secure Email Communication worked: how account and general inquiries would be routed separately through authenticated identification, how the note would be structured around topic and policy for agent clarity, and how consent and follow-through would be made explicit within the flow.
Route account and general inquiries differently through login identification
The earlier design workflow (labeled EARLIER DESIGN WORKFLOW — not all steps are confirmed production behavior) included a contact-us or header-login entry, media/general/policyholder branching, a general FAQ/note/chatbot path, customer login, a contact-us token routing to account inquiries or the dashboard, and an authenticated FAQ/note/chatbot.
After the product owner raised chat as an additional channel for users arriving from chat, a revised modal was introduced asking "What can we help with?" — offering "I have a Sonnet account" and "I have a general inquiry." The account option references login then chat; the authenticated landing offers both FAQs and Send us a note. This modal is the shown starting point in the revised prototype; no login form is pictured.
Structure the note around topic and policy for agent clarity
Subject choices in the form: Requests and inquiries; Billing; Troubleshooting; Cancellation and non-renewal. In the shown Requests and inquiries state, sub-topics include: Policy assistance; Account assistance; Quoting or purchasing assistance; Policy document(s) and proof of insurance; Renewal assistance.
A relevant policy section displays Active policies and Inactive policies with radio selection and View all policies. The form shows populated first name, last name, and email fields, a Your message area, and a 0/5000 character counter.
These are observed UI features in the prototype artifacts. They are not proof of editable identity fields, mandatory validation, branching logic enforcement, or character-limit enforcement in production. Early sketches explored the information architecture that led to this structure.
Make consent and follow-through explicit within the flow
The form includes an explicit consent checkbox with the exact copy: "I agree to receive policy and account specific information to the above email address." Followed by Send note.
The updated prototype confirmation screen shows an acknowledgement of the sent note, a response email reference, and a one-business-day response promise — then Go to dashboard and dashboard continuation. Customers continue conversing with the service hero by email after submission. The one-business-day promise is a UI service commitment visible in the prototype, not a measured outcome. This confirmation artifact is prototype, not final production confirmation.
Security in this context is tied to authenticated identification and explicit email consent — not encryption, MFA, certification, or independently verified privacy claims.
Working with customer service
I led UX by organizing service and digital discussions, using service-team expertise as primary discovery input, mapping next steps with the team, responding to product-owner direction, and revising prototypes and UX documentation for UI, technology, and stakeholder handoff.
Product
Product Owner: directed addition of chat-origin users to the contact page; reviewed and approved the revised prototype and UX documents
VP of Digital: consulted during discovery on customer interview feasibility and overall digital strategy alignment
Design
Led UX: sketching, low-fidelity prototyping, two rounds of usability with customer service heroes; revised prototype and UX documentation after product-owner input
Copywriting team: collaborated on interface language including consent checkbox copy; UI team: received handoff documentation
Customer Service
Senior customer service hero: contextual interview source for service interactions and customer terminology; lead hero presented service pain points at team huddle
Heroes participated as stand-in research participants in two rounds of usability testing; consulted post-launch via analytics review and conversation
Organized a team huddle, received the lead hero's presentation on service pain points, and conducted a contextual interview with a senior hero to understand service interactions and the language customers used. Spoke separately with the VP of Digital about interview feasibility. Direct customer interviews were not conducted due to time and budget constraints.
Built a low-fidelity clickable prototype and ran two rounds of usability testing with customer service heroes as stand-in participants — no participant counts or measured test results are available from the source. After product-owner input about chat-origin users, revised both prototype and UX documentation.
Mapped next steps with the team, coordinated with analytics, technology, copywriting, customer service, UI, underwriting, and the product owner. Produced revised UX documentation for UI team and technology stakeholder handoff. Analytics were added after rollout; FullStory session replays reviewed post-launch.
Enabling delivery
Delivering the flow required coordinating across analytics, technology, copywriting, customer service, UI, and underwriting — using existing tools and a unified route to keep the work achievable within the team's constraints.
Led UX from discovery through handoff: organized service and digital discussions, sketched and tested entry alternatives and form structure, built and iterated the low-fidelity prototype across two usability rounds, responded to product-owner direction on chat routing, revised prototype and UX documentation, and coordinated with the copywriter on interface language including the consent checkbox copy.
Analytics team: instrumentation added post-launch; technology team: received UX documentation and built within existing tooling; copywriting: interface language collaboration; customer service heroes: proxy discovery and usability participation; UI team: received handoff documentation; underwriting and the product owner coordinated scope and delivery.
Senior customer service hero — primary discovery source and service expertise. Lead customer service hero — team huddle presentation. VP of Digital — discovery consultation. Product Owner — scope and revision direction. Analytics, technology, copywriting, UI, underwriting teams — delivery and coordination.
The result
Three figures reported in the published case study by Roger Ennis. The flow was rolled out; analytics were added; service heroes were consulted post-launch; FullStory session replays were reviewed. Calculation, baseline, sample size, and reporting period are not provided for any figure.
1
Author-reported claim. Before-state described as 3 touchpoints. Calculation, baseline definition, sample, and reporting period are not provided by the source.100%
Author-reported claim. This is not 100% accessibility or WCAG compliance — the before-state is characterised as accessibility at 0% priority in the dashboard. Calculation, scope, and measurement period not provided.100%
Author-reported claim. This does not mean every issue is self-service — the before-state is characterised as self-serve limited to quotes and FAQs. Calculation, scope, and reporting period not provided.Email redirected to chat or phone — 3 touchpoints, no async account-specific channel, limited self-service beyond quotes and FAQs
Earlier customer vs. non-customer workflow — before the authenticated email route existed, account inquiries by email required channel switching.Authenticated Send us a note flow — account identification through login, explicit email-disclosure consent, inquiry structured by topic and policy, and continued conversation with customer service by email.
Completed design — authenticated landing and note entry. This is a design evolution comparison, not a controlled before/after test.After rollout, analytics were added, service heroes were consulted directly, and FullStory session replays were reviewed. This supported an ongoing understanding of how the flow was used. Testing with heroes had anticipated reduced phone, email, and chat traffic — no measured channel-traffic reduction is available from the source.
All three result figures are author-reported claims from the published case study by Roger Ennis. Calculation, baseline, sample size, and reporting period are not provided for any figure. The 100% accessibility improvement is not 100% accessibility or WCAG compliance. The 100% self-serve improvement does not mean every issue is self-service. No first-contact resolution rate, adoption improvement, or measured resolution-time reduction is claimed.