02 / 04 Playbook · AI · Service design 7 min read

Building an AI concierge

A five-step roadmap for deciding what to hand to AI and what to leave alone. Most product teams add AI in the wrong order. They start with the technology ("we should add a chatbot") instead of the user ("where does our user actually struggle"). The result is AI sitting in a corner of the app, ignored.

The concierge metaphor

A concierge is different from a chatbot. A concierge has a job. Knows the user. Knows the building. Hands off to the right person when needed. That is the metaphor that works.

This roadmap is what I use to take a product from "we want AI in this" to a scoped, paradigm-ready brief. Five steps. Each step has one objective and a tight set of action items.

The concierge metaphor is what stopped our team from designing chatbots. A concierge has a job. A chatbot has a UI.

The five steps

01

Define the problem and scope

Objective. Get clarity on what you are solving, for whom, and within what boundaries. This is where most AI projects fail. Teams skip the problem and jump straight to "let's add a chatbot."

  1. Write a clear problem statement.
  2. Define the needs the assistant exists to serve.
  3. List the domains or products it covers (example: credit cards inside banking).
  4. Create one primary persona with goals, frustrations, and behaviours.
  5. Choose one core use case to focus on first.

If you cannot name the persona and use case in one sentence each, you are not ready for step 2.

02

Tell your persona's story

Objective. Understand how the user thinks, where they hit pain points, and what they want at each step.

  1. Map a linear journey, sequential or non-sequential, whichever fits the user's reality.
  2. For each step, identify the user's action, goal, and pain point.
  3. Mark which steps are sequential and which are not. The non-sequential ones are usually where AI can help most.

This is a journey map, read specifically as a map of where the user struggles, not where the product flows.

03

Identify where AI plays a role

Objective. Find the moments in the journey where AI can meaningfully help, and decide what kind of help.

  1. Highlight every point in the journey where AI could provide value.
  2. For each point, decide: does this need a UI component, or can it be conversational text?
  3. Note any variables or conditions that change the interaction (user state, context, data availability).

This is where most teams overscope. The discipline is to leave the points where the user is fine without AI alone.

04

Define the feature list

Objective. Turn the journey insights into a tangible feature list, then prioritise.

  1. List the main assistant features (example: compare, calculate).
  2. Choose the core features that ship in v1 (example: save, autofill, history, notification).
  3. Note any technical or data limitations that affect what is feasible.
  4. Run a feedback session with stakeholders before locking the list.
  5. Prioritise by feasibility, value, and constraints.

Required across any AI assistant

Memory · Prompts · Handoff · Explainability · Fallback. No project ships without all five. The other features stack on top of that base.

05

Design the paradigm and execution

Objective. Build a consistent, scalable design direction for the assistant.

  1. Pick your interaction paradigm (one of the seven below).
  2. Write design principles for AI behaviour. See What good AI feels like.
  3. Document the design system rules for AI usage (typography, motion, copy tone).
  4. Finalise high-fidelity mockups and interaction specs.

The seven recurring paradigms

These paradigms keep showing up across products our team has designed for. Pick one or two that fit your product's role.

Paradigm 01

Enter and minimise

A floating CTA opens the AI surface. When the user is done, it minimises back.

Best when AI is a sometimes-tool, not always-on.

Paradigm 02

First-time and returning users

Different entry experiences for first-timers and returning users. Onboarding for one, instant continue for the other.

Best when the assistant earns value over repeated use.

Paradigm 03

Initiate a conversation

A clear, single way to start the AI surface, whether by typing, voice, or continuing a past thread.

Best when users land with intent and want minimum friction.

Paradigm 04

View Level 1 responses

Short, scannable initial AI responses with key actions inline. The first thing the user sees should be small enough to absorb at a glance.

Best when quick answers are the default success case.

Paradigm 05

View Level 2 and 3 responses

Overlay or expanded views for users who want more depth. The primary CTA stays anchored in the chat box.

Best when results have layered detail (sources, alternatives, breakdowns).

Paradigm 06

Level 4 detail

The deepest detail view, surfaced only when the user explicitly drills in.

Best when power users need full data without overwhelming new users.

Paradigm 07

Navigation

Secondary options (new chat, history, search past chats, bookmarks) sit in a hamburger menu, never in the main interaction surface.

Best when the assistant supports multi-session, multi-thread work.

Copy the templates

I left the templates for all of these artefacts, the five steps and the seven paradigm wireframes on this Miro board for you. Duplicate it into your workspace and use it on your next project.

What this roadmap is not

It is not a process. It is a tool. The artefacts have to look like things a designer would want to pull off the shelf, not policies they have to comply with. That distinction did most of the adoption work when this rolled out internally.

It is also not finished. The next iteration needs a measurement layer at the production end so the framework gets better against real user outcomes, not just internal velocity.

How to use this