Look for friction between the parts of the service
Service problems often appear at one touchpoint but begin somewhere else. A confusing setup screen may reflect missing information from sales. Delayed activation may depend on an approval outside the user’s control. A support request may start with a handoff that no team clearly owns.
Start with the service moment behind the problem. Ask what the customer is trying to accomplish, what must happen before and after that moment, who is involved and what moves between them. This keeps discovery focused on the service as a system rather than reducing it to interface feedback.
Review the journey as role × moment × handoff
Use one service moment and examine it through a simple lens.
Lens · What to examine
- Role: Who approves, administers, uses, supports or depends on the service?
- Moment: What is each role trying to understand or complete at this stage?
- Handoff: What moves to another person, team, system or channel?
- Friction hypothesis: What could be lost, delayed, repeated or misunderstood?
- Evidence state: What is observed, what is assumed and what is only a simulated signal?
This turns “Is onboarding working?” into something more useful: “At which moment does this role depend on another role or process, and what do we still not know about that handoff?”
Keep the service context stable while you change the role
For a role comparison, keep the service, industry, region and customer-company context consistent. Then change the customer role.
Ask each perspective about the same moment. What are they trying to get done? What information do they receive or provide? Who do they depend on? What would make the handoff fail?
The differences can matter more than agreement. An administrator may care about setup completeness, an everyday user about disruption to their work, and a sponsor about adoption, risk and business outcome.
Example: one onboarding journey, three perspectives
Illustrative example, not a customer result.
A B2B software-enabled service is redesigning onboarding for mid-sized industrial customers. The team believes the main problem is that setup takes too long.
It explores the same onboarding journey with three AI-simulated perspectives in the same modeled company context: the customer administrator who configures the service, the everyday user who must change how they work, and the internal sponsor responsible for the purchase.
The administrator conversation may raise a question about information arriving too late. The user conversation may suggest that uncertainty after activation matters more than setup time. The sponsor conversation may expose a question about ownership when adoption stalls.
None of this establishes what real customers do. It gives the team three specific handoff hypotheses to investigate instead of one broad assumption about “onboarding friction.”
Use simulation to add questions, not facts, to the service map
Service teams often use journey maps or service blueprints to describe how a service works today. Keep observed research and simulated exploration separate in those artifacts.
If a friction point comes from interviews, observation, product data or support evidence, record it as such. If it comes from a Virtual Customer conversation, label it as a hypothesis or simulated signal. Do not turn a plausible simulated journey into “the customer journey.”
Let simulation add questions to the map. Which handoff should we observe? Which role should we interview? Which step needs product data? Which internal team understands the backstage process?
End with a real-world research decision
The goal is not to produce the most complete simulated journey. It is to decide what needs stronger evidence before the service changes.
Return to real customer research when a handoff is consequential, when roles appear to experience the same moment differently, when the team has little observed evidence for a critical step, or when the decision depends on actual behavior. Product and operational data may also be needed to understand what people really do, how often a failure occurs or where time is lost.
Virtual Customer can help narrow the research question and choose the people to involve. Real customers, service data and observation remain the evidence for how the service behaves in practice.
Questions service teams often ask
Should one virtual customer represent the whole journey? Usually not. Compare the roles that matter to the specific handoff or decision rather than asking one persona to represent the whole organization.
Can the conversations be used in a service blueprint? Yes, as clearly marked hypotheses or questions. Do not mix simulated signals with observed current-state evidence.
Do we need to interview every role? Not automatically. Prioritize the roles and handoffs where being wrong would materially affect the service decision.
Start with one service handoff
Choose one onboarding moment where responsibility moves between people, systems or channels. Explore it from the customer administrator, everyday user and internal sponsor perspectives, then identify the one uncertainty that most needs real customer research.