Customer Search
& Authentication

Overview

Customer Search and Authentication are the entry point to every agent session in OneView — Rogers' internal agent platform used by Customer Care and Retail agents across Canada. Before an agent can open any customer account, two things must happen: they need to find the right customer, and they need to verify who they're speaking with.

I designed both flows end-to-end, from the first search field to the moment the account unlocks. This includes the full Customer Search experience across Rogers, Fido, and Shaw brands, and formal Authentication flows for both Care (phone agents) and Retail (in-store agents).

The Problem

Authentication at Rogers had no formal digital flow. Agents verified customer identity informally — by training, by memory, by manually matching what the customer said against what they saw on screen. Business wanted to formalize authentication, improve security, reduce fraud risk, and create a consistent, auditable process across all agent types.

There was no UX to start from. Only rough business diagrams.

• No designed search experience — agents used legacy tools with no structured flow
• No formal authentication UI — verification happened verbally with no guided process
• No edge case handling — forgot PIN, failed attempts, manager approval, and fraud flags had no designed states
• No consistency between Care and Retail — two different contexts, no shared design language

The starting point was a set of business logic diagrams. My job was to turn them into a real product.

Before & After

This project had no prior design — built from the ground up.

Before — business diagrams and informal process

After — Customer Search

After — Authentication (Care, in-page)

What this project introduced

• A structured search experience with 6 search types, results across Rogers/Fido/Shaw brands, and clear contact hierarchy
• A formal authentication flow with conditional branching, attempt counting, and full audit visibility
• Consistent design language across Care and Retail, adapted to each context
• Edge case coverage — fraud alerts, skip authentication for specific roles, failed previous session warnings, manager approval, and API error states

My Role

I was the primary designer on both Customer Search and Authentication, from initial brief to final delivery. There was no prior design to build on — I started from business diagrams and translated complex logic into a usable product.

• Customer Search: Designed the full search experience — 6 search types, all result states, no-results flow, new account creation, skip authentication, fraud prevention, permission-based states, alerts, session management, and navigation
• Authentication logic: Identified gaps, missing states, and unclear decision branches in the business diagrams before a single screen was designed
• Modal → in-page decision: Business asked to keep modals. I proposed moving to a full in-page dynamic form immediately — they agreed and it became the direction for both Care and Retail
• Care and Retail flows: Designed both contexts separately — Care for phone agents, Retail for in-store — with shared patterns and context-specific adaptations
• Customer Search logo: Designed the CS logo to match the existing internal tool logo family (InfoAssist, OneView, Agent Assist) using the shared "wave" motif

Process

Starting point: diagrams with gaps

Business and BSAs had mapped the authentication logic as decision trees. But diagrams aren't products. Before designing any screens, I reviewed every branch and identified:

• Missing states (what happens if PIN fails on the last attempt?)
• Unclear decision points (when does the flow move to account questions vs. secret question?)
• Unhandled scenarios (what if the agent needs to leave mid-flow? Do failed attempts still count?)
• UI needs that weren't visible in the diagrams at all

My annotated reviews of these diagrams became the foundation for every design decision that followed.

Designing Customer Search

The search experience needed to support multiple ways agents might identify a customer. I designed 6 search types:

• Account number + postal code
• Account holder name + postal code
• CTN/Subscriber ID + postal code
• Other phone number + postal code
• Billing address — with Canada Post API autocomplete and manual fallback
• Email address + postal code

Results show the account holder and all authorized contacts. Agents can expand the full contact list and authenticate any individual contact directly from search results.

Edge cases designed:

• No results → option to create a new account (Mobile, Home, Rogers, Fido, Mastercard, Rogers Bank)
• Multiple brands in results (Rogers, Fido, Shaw, Shaw Direct)
• Skip authentication for specific privileged roles (Office of the President — permission-based)
• Hide Authenticate CTA when agent doesn't have access to that brand segment — with clear error message
• Fraud prevention alert — customer directed to call Rogers Validation Team
• Alerts panel with P1/P3 priority incident notices
• Session expiry timer and sign out behaviour

The logo

The Customer Search logo was designed to sit within an existing suite of internal tool logos. I studied the wave motif and typographic system, then designed the CS mark to feel like a natural fourth member of the family — not a standalone addition.

Authentication: the modal era

Both Care and Retail authentication started as modal flows. At the time, requirements were simpler: verify photo ID, pass or fail. Modals made sense for a quick confirmation.

The pivot: modals couldn't hold the complexity

Business came back with expanded requirements. Care authentication now needed to support:

• Photo ID verification
• PIN authentication (3 attempts, countdown, forgot PIN)
• Secret question / SQA
• Account reference questions (date of birth, SIN, driver's license, balance, payment method, and more)
• Manager approval when all other paths fail
• Failed previous session warnings
• Skip ID verification for outbound calls

Modals hide context. They can't show previous answered steps. Managers reviewing an approval request can't see what happened before. Every new requirement made the modal approach worse.

Business asked to keep modals. I proposed moving to a full in-page dynamic form — they agreed immediately.

The in-page approach solves every problem modals created: the full flow is visible on one page, previous answered steps remain visible as the form progresses, and managers can see the complete authentication history before approving or denying.

Final Care authentication — in-page

Final Retail authentication — in-page

Retail authentication follows the same in-page dynamic form pattern as Care, adapted for the in-store context where agents have the customer physically present.

Skip authentication

For specific agent roles (initially the Office of the President), the standard authentication flow can be bypassed. I designed this as a permission-based state — the Authenticate CTA is replaced with Skip authentication only for eligible agents, with the same downstream application access after skipping.

Outcome

Customer Search is live and in active use. The Care modal version of authentication launched for a group of Care agents at the end of April 2026 — the first formal digital authentication flow Rogers agents have had.

The Retail in-page version is scheduled for PI3-2026. The Care in-page version follows by end of 2026 — replacing the modal version entirely with the full dynamic form.

What this project established

• The first structured, auditable customer authentication process in Rogers' agent tools
• A consistent search experience across 6 search types and multiple brands
• A repeatable pattern for complex conditional flows in OneView — the in-page dynamic form is now the model for multi-step agent workflows
• A full logo identity for Customer Search, designed to fit within the broader internal tools suite

No post-launch metrics yet — adoption data and performance results will be added as the rollout progresses.

Tools Used

• Figma
• FigJam
• Rogers CDK
• Systems Design
• Security & Compliance
• WCAG 2.x AA