Product Strategy Conversational AI 0 → 1 Design

Azure Copilot in Teams & Slack

An AI copilot built for the Azure portal, reimagined for the places engineers actually work — a conversational experience for Microsoft Teams and Slack, where specialized agents help an engineer resolve issues without leaving the thread.

Timeline

2026

Platforms

Microsoft Teams · Slack

My Role

Design Lead — owned the design direction and end-to-end experience from kickoff to launch. Led a second designer on Slack, and partnered with content, visual design, PM, and engineering on brand, roadmap, and release scope.

Impact · First release

2
Platforms launched — Teams and Slack
30
Enterprise customers in the pilot
20%
Faster time to root cause and resolution

Context

Engineering teams coordinate in Slack and Teams. But the moment something breaks, someone has to leave the conversation.

🔗

The work lives elsewhere

Troubleshooting an issue, managing a support case, acting on a resource — all of it lives in the Azure portal. One person goes to another tab, does the work, and relays it back to the group.

⚡

Customers were asking

Amazon Q Developer already ran natively in Slack and Teams. Azure had no equivalent, some of its largest customers asked for one by name, and it became a P0 for Azure Customer Experience.

🎯

The goal was never a chatbot

Make the channel a place you can operate Azure from — investigate an issue, collaborate on it, and take real action on your cloud, where the team already coordinates.

Building a Shared Picture

Four teams each owned a piece of this product — EngOps the troubleshooting capabilities, the Portal team the existing Copilot, the Teams platform its constraints, marketing the identity. No one had the whole picture, so my first job was to build one.

👥

Stakeholder map

One-on-ones with every team: what they owned, where they were constrained, where they had room to move.

📚

Existing knowledge

Prior customer research, an audit of the Portal Copilot, and the patterns and limits of Teams and Slack — scattered across teams, pulled into one place.

🗺

End-to-end flow

The full journey, from install and notification setup to proactive alerts and case collaboration — the blueprint design, PM, and engineering built from.

Three principles

1
Make chat actionable

If every answer is a link back to the portal, nothing has moved — the flow has only gained a step. Whatever the agent surfaces should be actionable in place.

2
Keep humans in control

Customers welcomed AI-assisted troubleshooting but wanted to approve anything important. The agent recommends and prepares; people decide.

3
Native to each platform

Teams and Slack don't share building blocks. Don't copy the portal, and don't force the two to match — keep the core experience, and let each platform speak its own language.

Design Highlights

What shipped, in the order a user meets it.

App discovery

Users install Azure Copilot from the Teams app store and launch it inside Teams. As a brand-new product, it also needed a first impression — naming, icon, and visual identity.

Discovering Azure Copilot in the Teams app store

Onboarding

Sign in once to connect an Azure identity. Copilot picks up the user's subscriptions, introduces what it can do, and offers notifications — optional, and adjustable any time.

Signing in to Azure Copilot and setting up notifications

Chat agent

Describe a problem and Copilot investigates — checking in when it needs input — then lands on a likely root cause and a resolution plan, without the user switching tools.

The Azure Copilot chat agent troubleshooting an issue end to end

Specialized agents

Some questions need a specialist. Agent choice lives in New Chat, where conversations already start — the general Copilot, or a specialized agent for migration, deployment, troubleshooting, and more. Each opens with prompts written for its job.

Choosing a specialized agent from New Chat and seeing its suggested prompts

Chat history

Beside New Chat, a history entry lists every conversation across every agent, each marked with its agent's icon — one place to pick up where you left off.

Opening conversation history next to New Chat to resume a previous conversation with an agent

Proactive notifications

Copilot flags issues in the service groups a user follows — outages, retirements, cost and resiliency risks. From the notification, they can review the issue, open a Jira work item, and act — all in Teams.

A Teams notification from Azure Copilot about critical service groups, opened to review the issue and take action

Working together in a group chat

Azure operations are a team effort, so Copilot joins group chats too. Users ask privately, review the answer, and choose whether to share it — so the thread gets a vetted answer, not a raw one.

Asking Azure Copilot privately in a group chat and sharing the answer with the team

Designing for Slack

The same experience had to ship on Slack — the same stages and the same decisions at the same moments, but not the same screens. I designed Teams and defined the system a second designer built Slack from: an early workshop with PM and engineering to align scope across both platforms, then daily reviews to catch drift before it shipped.

When something needs attention in Teams, a toast can surface it over whatever the user is doing; Slack offers only a sidebar badge. Teams' Adaptive Cards support a carousel; Slack's Block Kit does not, so the same content becomes a list.

📏

The rule I drew

The meaning stays identical — what the agent says, which decisions are available, and where the user ends up. Layout and delivery are free to differ, since that's what makes each platform feel native rather than ported.

Azure Copilot in Slack — connecting an account, setting up notifications, then troubleshooting in the thread

Takeaways

🧭

Clarity is a deliverable

The most useful thing I made early on wasn't a screen. It was a shared picture — who owned what, which principles held, how the flow connected.

It kept four teams and two platforms moving in one direction while the constraints kept changing.

🤖

Agents need workflows, not replies

Once an agent can pause and ask, the interface stops being a request and a response. It becomes a process the user and the agent share.

Visibility and control are what make that process trustworthy.