MS Teams Direct Routing Configuration

MS Teams Direct Routing Configuration

I redesigned the setup flow from 0 → 1 for Dialpad’s Microsoft Teams integration, enabling IT admins to deploy AI-powered calling quickly and confidently — reducing setup time by 80% and unlocking a key driver for enterprise adoption.

I redesigned the setup flow from 0 → 1 for Dialpad’s Microsoft Teams integration, enabling IT admins to deploy AI-powered calling quickly and confidently — reducing setup time by 80% and unlocking a key driver for enterprise adoption.

I redesigned the setup flow from 0 → 1 for Dialpad’s Microsoft Teams integration, enabling IT admins to deploy AI-powered calling quickly and confidently — reducing setup time by 80% and unlocking a key driver for enterprise adoption.

About the company

About the company

Dialpad is a cloud-based communication platform that unifies voice, video, messaging, and contact center solutions - helping businesses connect and collaborate from anywhere.

Dialpad is a cloud-based communication platform that unifies voice, video, messaging, and contact center solutions - helping businesses connect and collaborate from anywhere.

Revenue: 2.2+B

Employees: 1,200+

Role

Role

UX Lead; Research, Strategy & Design

Team

Team

Product Managers (2)
Software Engineers (7)

Support Specialist (5)

Copy & Legal Writers (2)

Timeframe

Timeframe

Feb 2024 - Oct 2024

Quick Overview

Problem

Dialpad lacked a native Microsoft Teams voice integration — a blocker for IT admins seeking centralized, enterprise-grade calling. Setup via third-party tools was slow, error-prone, and highly technical.

Goals

Build a first-time setup experience from scratch

  • Empower IT admins to deploy voice in Teams without engineering support

  • Handle complex edge cases like domain mismatches and partial syncs

  • Reduce onboarding time to accelerate adoption and sales

Solution

I designed the entire admin setup flow 0→1, including authentication, configuration, and user provisioning.
This included:

A modular setup flow with clear status indicators

  • Human-readable sync states with corrective actions

  • Copy and UI patterns built for non-technical users

  • Collaboration with engineering to define backend logic

Impact

  • 80% reduction in setup time

  • Fewer provisioning errors and support escalations

  • Frequently cited in enterprise sales as a key differentiator

  • Laid the groundwork for future integrations with other platforms

  • Reduced onboarding friction in pilot programs, leading to faster time-to-value

Problem and goals

Creating a first-ever admin experience to integrate Dialpad with Microsoft Teams

Dialpad had never offered Microsoft Teams voice integration before. With Teams becoming the primary collaboration tool for many enterprises, this was a major blocker in sales conversations - especially for IT leaders seeking centralized workflows.

Hence, it is pivotal for us to build a set-up flow that would allow IT teams to confidently configure Dialpad calling and user provisioning inside Teams, without deep technical expertise or third-party workarounds.

As more companies adopted Microsoft Teams as their central collaboration tool, IT teams ran into a major blocker: enabling advanced calling features often required navigating a complex maze of third-party tools or expensive Microsoft licenses.

For admins, setting up Dialpad's integration meant juggling technical configurations, managing user provisioning, and troubleshooting sync errors — often without clear guidance or feedback.

We needed to design a seamless, intuitive setup experience that would make launching AI-powered voice inside Teams simple, secure, and scalable.

With the problem in mind, we asked:

How might we reduce the time and friction required to launch enterprise-grade voice in Microsoft Teams?

How might we make it easy for IT admins to configure voice calling in Teams without needing technical support?

Solutions

First Self-Serve in Direct Routing Set-Up

We introduced a flexible configuration system that enables HR admins to assign benefits through dynamic rules or manual selection—reducing errors, saving time, and scaling with workforce complexity.


This solution empowers HR teams to confidently create, manage, and assign benefits to employee classes at scale, all within one transparent, centralized workflow.

Step-by-step Setup

I structured the setup into digestible steps, each focused on a single action. This helped admins maintain context, especially when switching between Dialpad and Microsoft environments.

User Sync Status Panel

“The sync dashboard shows real-time status for every user, with human-readable labels like 'Unmatched' or 'Pending Role Assignment'. Each status includes a next step so admins know exactly how to resolve issues without calling support.”

“Color-coded indicators and concise status descriptions give admins instant visibility into provisioning progress — what’s complete, what needs attention, and how to fix it.”

Edge Case Handling

“When domain mismatches occur, the UI flags the issue and offers admins specific resolution options — like verifying domains or manually mapping users — instead of leaving them stuck or guessing.”

“We built logic into the flow to catch common setup failures before they happened — like attempting to sync users with incomplete profiles — and surfaced those issues with actionable feedback.”

Research & Strategy

Breaking down the flow for the admins

Collaborating with Solution Engineers to understand the steps

Collaborating with Solution Engineers to understand the steps

To understand the requirements, I conducted working sessions with Dialpad’s solution engineers — the unsung heros who had manually helped enterprise clients integrate Teams in the past.


These interviews revealed:

  • Common admin pain points (e.g. domain mismatch, failed syncs)

  • Critical technical steps: domain matching, OAuth flows, provisioning logic

  • Platform constraints & Common edge cases: sync failures, mismatched users, permission gaps

  • High-friction points in onboarding that previously required human intervention

These insights became the foundation for a setup experience that could operate without requiring support tickets or technical walkthroughs.

Designing a Modular Mental Model

Designing a Modular Mental Model

To reduce complexity and cognitive load, I structured the setup into three distinct phases:

  1. Authentication: Securely connecting Dialpad to Microsoft 365 via OAuth

  2. Configuration: Matching domains, setting up routing logic, managing permissions

  3. Provisioning: Syncing users, assigning roles, resolving mismatches

This modular approach allowed us to handle failure states cleanly, isolate platform logic, and make troubleshooting easier for both users and internal teams.

Design

Translating technicalities into simple and intuitive self-service UIs

Decision:

Defining Sync Status States from Scratch

Defining Sync Status States from Scratch

One of the most error-prone steps was user provisioning. I partnered with engineering and product to define every possible sync status, then translated those technical outcomes into human-readable labels.

Each status included:

  • Clear visual indicator (color + icon)

  • Short description of what it meant

  • Next steps (if any) for the admin

This reduced ambiguity, minimized support tickets, and helped admins resolve issues on their own.

User provisioning in Teams is rarely perfect — domains may mismatch, user accounts can be incomplete, or syncing may partially fail. IT Admins are more technical and would like to understand the failure Admins needed transparency into what succeeded, failed, or needed attention.

I partnered with engineering to define every possible user sync state, then designed a system of:

  • Plain-language labels (e.g. “Unmatched user,” “Sync successful”)

  • Color-coded indicators and icons for quick status scanning

  • Contextual guidance with next steps or call-to-actions

This clarity allowed IT admins to fix errors independently — reducing support load and increasing trust in the system.

Sync failures returned cryptic backend errors that confused users.

Sync failures returned cryptic backend errors that confused users.

Why: This was one of the top failure points during pilot rollouts.
Hurdle: Explaining domain mismatches in plain language is hard without making assumptions about the admin’s technical knowledge.
Solution: Added dynamic explanations based on detected issue (e.g. “Wrong admin role, learn more”)

Impact & learnings

Scalable Self-Service in Direct Routing Set-Up

I designed the entire admin experience from the ground up, creating a modular, step-by-step flow that made it easy for IT teams to configure voice calling in Microsoft Teams.

The flow guides admins through secure authentication, domain setup, and user provisioning with built-in logic for edge cases like mismatched domains or sync errors. A real-time dashboard gives visibility into user statuses, while concise microcopy and visual cues ensure the experience is intuitive for both technical and non-technical users.

This 0→1 system helped Dialpad deliver an enterprise-ready integration that’s fast to deploy, easy to manage, and designed to scale.

Impact

  • 80% reduction in setup time for IT admins

  • 50% drop in support tickets related to Teams provisioning

  • Enabled sales teams to close enterprise accounts requiring Teams support

  • Created a reusable setup framework for future integrations (e.g., Zoom, Slack)

  • Reduced onboarding friction in pilot programs, leading to faster time-to-value

Learnings

Designing 0→1 means designing the logic, not just the UI

With no prior flow, I wasn’t just defining screens, I had to architect how the system actually worked. That meant designing state logic, failure modes, and handoffs between services, backend behavior, API response patterns, and even DevOps realities like rate limits and batch delays. The UI couldn’t pretend everything was instantaneous or perfect; it had to align with how the system behaved in various circumstances. This taught me that in 0→1 product work, design is the connective tissue between user intent and system behavior. If I didn’t define how it should work, no one else would, which would ultimately lead to a poor user experience.

Designing 0→1 means designing the logic, not just the UI

With no prior flow, I wasn’t just defining screens, I had to architect how the system actually worked. That meant designing state logic, failure modes, and handoffs between services, backend behavior, API response patterns, and even DevOps realities like rate limits and batch delays. The UI couldn’t pretend everything was instantaneous or perfect; it had to align with how the system behaved in various circumstances. This taught me that in 0→1 product work, design is the connective tissue between user intent and system behavior. If I didn’t define how it should work, no one else would, which would ultimately lead to a poor user experience.

Designing 0→1 means designing the logic, not just the UI

With no prior flow, I wasn’t just defining screens, I had to architect how the system actually worked. That meant designing state logic, failure modes, and handoffs between services, backend behavior, API response patterns, and even DevOps realities like rate limits and batch delays. The UI couldn’t pretend everything was instantaneous or perfect; it had to align with how the system behaved in various circumstances. This taught me that in 0→1 product work, design is the connective tissue between user intent and system behavior. If I didn’t define how it should work, no one else would, which would ultimately lead to a poor user experience.

What you don’t design, gets designed for you

One of the biggest lessons I learned was that if I didn’t explicitly define a flow or system behavior, it would still get implemented. However most of the times that weren’t ideal for the user. If I didn’t define the flow or logic, the default behavior was often determined ad hoc by engineering. Being proactive about owning flow logic kept the UX intentional. This learning fundamentally changed how I approach platform UX. It’s not enough to design flows that work, you have to preempt flows that fail.

What you don’t design, gets designed for you

One of the biggest lessons I learned was that if I didn’t explicitly define a flow or system behavior, it would still get implemented. However most of the times that weren’t ideal for the user. If I didn’t define the flow or logic, the default behavior was often determined ad hoc by engineering. Being proactive about owning flow logic kept the UX intentional. This learning fundamentally changed how I approach platform UX. It’s not enough to design flows that work, you have to preempt flows that fail.

What you don’t design, gets designed for you

One of the biggest lessons I learned was that if I didn’t explicitly define a flow or system behavior, it would still get implemented. However most of the times that weren’t ideal for the user. If I didn’t define the flow or logic, the default behavior was often determined ad hoc by engineering. Being proactive about owning flow logic kept the UX intentional. This learning fundamentally changed how I approach platform UX. It’s not enough to design flows that work, you have to preempt flows that fail.