I have sat in rooms that booked a customer experience day and still never spoke to a customer. The pack had maps, personas and a tidy pain-point list. Every input came from people who already work inside the process. By four o'clock the wall looked busy, and the service stayed the same.
If you're about to pay for one of these days, read the agenda first. Check that it books real time with the people who use the service and leaves room to rewrite the problem once the team hears from them. The day should end on one fix small enough to ship, with an owner named before anyone leaves.
Start from a live path through the service
Bring a real path that a customer or frontline staff member already takes, like a claims form people abandon or a support handoff that drops context between channels. With a made-up case everyone stays polite, and nobody challenges the current design.
Write the brief as a situation with a person in it. "Customers stall when they have to re-enter details after a channel switch" gives the room something to investigate. "Improve our CX score" hands them a metric and no clue where to look.
Bring the evidence you already hold as well. Complaint logs, drop-off numbers, call notes and the last survey comments help the team decide who to interview. Use them to aim the interviews, then go and have the interviews.
Time with the people affected
The Design Council says the first stage of design means speaking to and spending time with the people affected, so you understand the problem before anyone assumes it. I use that as the test for any customer experience agenda. If the customers or staff who live with the friction never appear, you've skipped discovery.
Our customer experience workshop maps the real path and the moments that cost trust, then ends with one fix the team can ship. On a one-day format, that means recruiting a handful of customers or frontline staff beforehand and booking them into short slots. On a longer format, the team can observe the service in the field and come back with notes.
Someone on your side has to own that recruiting a week or two out. When nobody owns it, the interviews quietly turn into a panel of colleagues role-playing the customer. Colleagues know where the problems hide. They also built the current process, and when they play the customer they defend it.
I ask buyers to book the interview slots before they book the catering. The interviews are the part that fails first. Once they fail, the rest of the day turns into the team guessing what customers think.
Define the problem again before you sketch fixes
Buyers underrate the step between the interviews and the ideas. The team has to turn messy notes into one sharp problem statement, and it's often a different problem from the one on the brief. That moment needs a sponsor in the room who's ready to hear it.
Ask the facilitator how they handle a room that discovers the brief was wrong. A good answer covers who signs off the new statement and what happens to the original plan. A vague answer about staying flexible tells you they've never had to do it.
What you learn in the interviews should change how you state the challenge. If the agenda jumps straight from a warm-up into ideas, the room will just build on the old brief.
I like to write the new problem statement on one line and read it back to the sponsor before lunch. If they wince, we talk about it while the interview notes are still on the wall. That conversation is cheaper on day one than in month six, when the build has started and nobody wants to admit the brief was off.
One fix, tested small
The day should land on one change the team can try at small scale. That might be a rewritten letter, a shorter form, a handoff script between two teams or a mocked-up screen a customer can click through. Test it small and keep improving the version that works.
Every team should leave with a prototype or a service experiment that a real person has already seen. If the day ends on a ranked list of concepts and no contact with a user, you've stopped right before the useful part.
Build those answers with people who see the service differently. That's why a mixed room matters. A product owner and a frontline lead will argue usefully about the same interview note, and that argument is part of the work.
Who should be in the room
Mix the functions that touch the path. Product, operations, frontline staff and someone from risk or legal will hear different problems in the same interview, and the friction between them is useful. At a minimum, keep the sponsor in the room for the define step and the final readout.
A sponsor who opens the day and leaves before the evidence arrives will overrule the team later from a slide. Remote works when the team is spread across cities, provided the session is built for screens and the customer interviews get the same care you'd give an in-person day.
Warning signs
Some warning signs show up in the proposal. The agenda lists six methods and no customers. The pack promises a mindset shift and never names an output. The facilitator offers a generic case from another industry for the team to practise on. Any one of these means the day will feel energetic and change very little.
Another sign shows up in the room. People present ideas to each other and vote with dots, and nobody leaves the building or picks up the phone. Voting has its place. When it replaces contact with users, the team ends up ranking its own guesses.
What to ask before you book
- Will the day run on a live path we bring, and will you help us rewrite the brief if the interviews contradict it?
- Who recruits the customers or staff we meet, and how many will the team actually hear from?
- What will the team hold at the end, and will a real person have seen it?
- How will the team run the method again next month without you in the room?
The last question matters more than buyers expect. A workshop that only works with an outside facilitator leaves you waiting for the next booking. The team should leave with a method it can run on the next broken path by itself.
After the workshop
Give the fix an owner before anyone leaves the room. Put the next round of customer tests in the calendar while everyone is still there. If the idea survives those tests and turns into a larger bet, a lean startup and product sprint is a sensible next step, because it tests whether the change holds when money and operations get involved.
If you want to book the day, send me the path the way your customers describe it, plus the names of a few people who live with it. We'll shape the workshop around that path and plan the interviews with you.
When the room is still guessing, run a design thinking workshop on a live problem.
