AskHR: Designing Conversational Support at Scale

Goal

Design an intelligent HR chatbot for a global financial services firm (25,000 employees globally) that would help employees self-serve common requests and route complex issues accurately. Significantly reducing bottlenecks for HR agents and improving the employee support experience by helping people get what they need faster.

The Problem

Employees used a fragmented mix of channels to reach HR: shared inboxes, personal contacts, ticketing systems, phone calls. A real junk drawer of navigation options. Employees didn't know which department could help them, what they were entitled to ask for, or where to start. HR agents spent significant time triaging and redirecting.

Navigating Constraints

The technology platform was already decided: Microsoft Copilot Studio. It handled straightforward queries well but had clear limitations with ambiguity and complex logic. Stakeholders were thoughtful about this, asking good questions throughout about whether this was the right tool and whether it would scale.

My role was to surface what users needed and non-negotiables for the tool to actually work, then design within those constraints without compromising the experience. How easy!

Approach

1. Qualitative research to understand mental models

I conducted interviews with employees and HR agents to understand how people thought about HR as a function, what "getting help" felt like, and where the current system broke down.

2. Proto-personas to focus scope

From research synthesis, I developed 3 personas representing distinct employee needs. These grounded the business to the employee groups who would benefit most from the tool (Andrew & Jorge), and who we needed to ensure we wouldn't leave behind as we designed (Perlah).

Key decision: Even with all the resources in the world, you can't solve for everyone. And we were already working within the technical constraints of Copilot Studio. The personas helped us scope to repeatable, high-volume requests from employees who needed simple answers fast, freeing up HR agents to focus on complex, hands-on work that actually required their expertise.

3. Future-state journey mapping

To illustrate how AskHR might shift the organization's current processes, I mapped the end-to-end journey across three layers: employees, HR agents, and technology. This surfaced the most critical design moments: handoffs between bot and human.

4. Collaboration on voice & tone

I was conscientious about how tone might shape employees' trust in (or dismissal of) the tool, so I brought in someone from the client's branding team to advise on the chatbot's voice and tone, ensuring it aligned with the company's established brand language.

Validation & Leverage

I prototyped key scenarios in Voiceflow and facilitated focus groups with employees to test the design before build. This wasn't a usability test of the tool itself, but rather a pulse check to gauge employee reactions to the experience and gather additional feedback outside of the project team.

Key finding: The focus group data became leverage when stakeholders wanted to deprioritize error-handling flows and user handoffs to ship faster. When the chatbot couldn't understand a request, employees weren't frustrated when the tool couldn't answer their question, but by constant request loops. They wanted the tool to proactively escalate requests to a real person if necessary, confirm that their input was captured, and clarify on what would happened next. The business team wanted to kick this down the road, but my research findings helped push for its necessity.

Every interaction needs a resolution, even if that resolution is "I'm handing this to a person."

Proper Escalation Handling: Before & After

Delivery

I designed the full conversation architecture in Miro from welcome message through case closure, including escalation paths, info modules, and feedback loops. I also worked directly in Copilot Studio with the development team to test what was buildable and adjust designs in real time.

The architecture was built around directness, limiting repetition, and always giving employees a way forward.

Reflection

This project reinforced something I've repeatedly encountered in my work: good design isn't about the artifact you produce, it's about the framework you create for teams to make informed decisions.

The chatbot was one output. The real work was translating ambiguous user needs into structured system requirements, using research to hold stakeholders accountable to those needs, and designing within real technical constraints without losing sight of what would make the tool actually useful.

The technology landscape would be different if I were designing this today. LLMs have improved, agentic AI looms in the near distance, and connected data systems sort through messy source data faster and better than rigid decision trees. User expectations have shifted too, but the underlying approach would stay the same: start with research, and design the handoffs as carefully as the happy paths.