A Mystery-Shop Test for the Full Local Customer Journey

A marketing report may show impressions and clicks while the real-world path remains confusing. A customer can find the business but still fail to ask a question, understand the offer, or reach the right entrance. This method addresses tests what a new customer can actually do across discovery, contact, booking, and arrival. It can be scaled down for a solo operator or split across staff when several people contribute.

The operating rule

A dance studio promotes a trial class. The page loads, but the address leads to a building with several entrances and the confirmation message does not say which floor to visit. This example is hypothetical. It illustrates the decision pattern rather than claiming a measured customer result.

Run the process in this order

1. Choose one realistic customer goal and a defined starting point.
2. Use a test identity and avoid creating a real booking or cost unless authorised.
3. Follow the public path: search result or advert, landing page, contact route, response, booking confirmation, and arrival information.
4. Record the exact point where a decision becomes unclear or a handoff fails.
5. Ask the responsible team to validate the finding before changing live information.
6. Repeat the test after the fix using the same scenario for comparison.

Risks and limits

Do not contact competitors, impersonate vulnerable customers, or create fake public reviews. Keep the exercise proportionate and ethical.

How to tell whether it works

Count failed steps, unanswered contact routes, contradictory details, and successful completion rate for the defined test scenario.

Working record template

Test goal | starting point | step | expected result | observed result | evidence | severity | fix owner | retest date

Example of a proportionate decision

For a dental clinic, the test might check whether a new patient can find the correct entrance, understand how to request an appointment, and know what information to bring—without collecting actual patient data.

Record observable evidence

Write observations as facts: “the confirmation page did not display a floor number” is more useful than “the booking experience is bad.” The first statement can be checked and assigned; the second mixes judgement with diagnosis. When the path crosses a third-party service, note which organisation controls the failure before assigning a fix. After correction, repeat the same test and add a separate test for any newly introduced step. A single successful run is evidence about that scenario, not proof that every customer can complete the journey.

Controls for the less obvious cases

Choose a safe test path that does not create a real financial commitment or consume a scarce appointment. When a live transaction is unavoidable, obtain authorisation and reverse it through the proper process.

Avoid changing several steps at once before retesting, or the team may not know which repair solved the problem. Record the observed defect and the change made before running the same scenario again.

The check has to work in the real operating context. In practice, that means choose one realistic customer goal and a defined starting point. Capture the result in the same place where the next person will look for status.

The check has to work in the real operating context. In practice, that means use a test identity and avoid creating a real booking or cost unless authorised. Capture the result in the same place where the next person will look for status.

The check has to work in the real operating context. In practice, that means follow the public path: search result or advert, landing page, contact route, response, booking confirmation, and arrival information. Capture the result in the same place where the next person will look for status.

The check has to work in the real operating context. In practice, that means record the exact point where a decision becomes unclear or a handoff fails. Capture the result in the same place where the next person will look for status.