The fake customer

The fake customer buys the last table for Friday night.

It uses a disposable phone number, a test card, a normal-looking name and a believable request: anniversary dinner, one guest gluten-free, card to be charged only if they fail to turn up. The booking system accepts it. The kitchen prints the allergy note. The reminder text goes out. The table is held.

Then nothing happens, because nobody was ever coming.

That is the problem with synthetic customers. The sales deck makes them sound like harmless probes. In production, they are not harmless. They occupy capacity. They create records. They trigger messages. They touch payment systems, staff workflows, analytics, compliance logs, review funnels and loyalty databases. They become part of the business unless the business has built a way to make them disappear.

The hard part is not making an AI sound like a customer. The hard part is making sure the business can survive being visited by someone who was never there.

Fake demand is still demand

Businesses are about to learn an awkward distinction. A synthetic customer can be fake as a person and real as an operational event.

A test booking blocks a slot. A test refund opens a case. A test complaint enters a queue. A test delivery address may be passed to a courier. A test call can change an agent's score. A test basket can pollute abandoned-checkout analytics. A test identity can get merged with a genuine customer who happens to share a name, phone number fragment or postcode.

None of this looks dramatic in a demo. The demo ends when the transcript appears. The business lives with the residue.

Synthetic customers need the same design seriousness as payments, inventory and access control because they touch all three. They should have limits, ledgers, labels and expiry rules. They should be boring to reverse.

If the organisation cannot answer "where did the fake person go?", it is not ready to send fake people through the front door.

The identity problem arrives first

Most customer systems are built to remember. That is a feature until the customer is artificial.

The CRM sees a phone number and creates a lead. The booking tool sees an email address and creates a profile. The support desk sees a complaint and links it to a household. The marketing platform sees a form fill and begins a nurture sequence. The fraud tool sees a strange payment pattern and downgrades an IP range. The branch manager sees a no-show and calls the number.

Now the fake customer has a history.

That history may be small, but small records have a way of spreading. They get exported to spreadsheets, synced into dashboards, deduplicated badly, attached to sales reports and used for training data six months later. Someone will eventually ask why a customer called "Maya Test" has three refunds, no verified address and a lifetime value of negative £14.80.

The answer cannot be "delete it manually".

A serious synthetic-customer system needs an identity vault. Not a list of joke names, but controlled identities with:

permitted channels
permitted locations
spend limits
refund limits
data-retention clocks
reusable and single-use aliases
a reveal flag after the run
an owner who can revoke the identity

The identity should be able to look ordinary to the workflow being tested, then become visibly artificial to the people cleaning up afterwards. That delayed reveal is the product detail that matters. If the flag is visible too early, staff will behave for the test. If it never appears, the business gets a haunted database.

Reversal is a feature, not housekeeping

Every fake action needs a planned undo.

That does not mean every test must be sandboxed. Sandboxes are useful, but they miss the point when the risk lives in the handoff between real systems. A booking sandbox will not tell you whether a real reminder service, branch rota and payment rule disagree. Sometimes the test has to touch production.

Production contact requires a reversal contract.

A restaurant booking should auto-release before it harms revenue. A clinic appointment should never consume a scarce urgent slot unless a human has approved the test window. A refund request should have a cap and a matching accounting label. A discount-code probe should never create an actual margin report without a synthetic marker. A delivery test should stop before a courier is dispatched, unless the courier is part of the authorised exercise.

The reversal contract should be written before the scenario runs:

What can the fake customer create?
Which systems can it touch?
What must be reversed automatically?
What needs human sign-off?
Who owns cleanup if the reversal fails?
How long can residue remain?
Which records are retained for audit?

This is less exciting than the agent prompt. It is also where the cost lives.

The ledger gets messy

Finance teams will not enjoy synthetic customers unless the product speaks accounting.

A fake purchase is not revenue. A fake refund is not churn. A fake failed payment is not fraud. A fake chargeback exercise is not a customer dispute. If those events leak into the main ledger, the business will either ignore them and corrupt reporting, or ask staff to tidy them manually and slowly stop running tests.

The problem is not only formal accounting. Operational metrics are ledgers too.

No-show rate. Average handling time. Conversion rate. Complaint volume. Promo redemption. Staff utilisation. Refund reason codes. Lead quality. Booking value. Queue backlog. First-contact resolution. Every one of those can be bent by fake demand.

The right answer is not to pretend the events never happened. The right answer is to account for them separately.

Synthetic activity needs a shadow ledger: visible to operations, excluded from commercial reporting by default, retained long enough to prove what happened, and easy to reconcile when a test crosses into a real transaction by mistake.

Without that, the fake customer becomes a small form of data debt.

Staff need a policy before they need a score

Synthetic customers can become surveillance with a friendlier logo.

It is easy to say the point is systems, not staff. It is harder to prove that when a transcript contains a named employee, a timestamp, a hesitation, a mistake and a manager who wants a simple answer. If the workflow routes every failed interaction to a performance dashboard, the staff will understand the product correctly: it is a trap.

The policy has to arrive before the first test call.

Staff should know synthetic interactions may occur. They should know what data is collected, how long it is kept, who can listen, what counts as training use, what counts as disciplinary use, and how disputes are handled. The specific test identities can stay hidden, but the programme cannot be secret.

There should also be protected categories of scenario. Do not simulate a bereavement call because it might expose a weak script. Do not imitate severe distress unless the team has agreed the boundary and support is in place. Do not use accents, disability markers or language fluency as cheap difficulty settings. A business can test whether its service is accessible without turning protected traits into props.

Good synthetic-customer governance should make staff less exposed, not more. It should move attention from "who sounded unsure?" to "which rule, screen, incentive or missing permission made the interaction fail?"

That distinction has to be enforced in access controls, not left as a moral preference.

Realism is overrated

Vendors will compete on how natural the fake customer sounds. That is understandable and slightly beside the point.

A business does not need the most lifelike artificial caller if the cleanup process is bad. It needs a caller whose actions are bounded, labelled afterwards, reversed cleanly and excluded from the wrong reports. It needs a system that knows when to stop.

The best synthetic customer may be less realistic than a human and more disciplined than one. It will not improvise its way into a real mortgage application. It will not threaten staff. It will not buy a regulated product without permission. It will not create a live medical appointment just to see what happens. It will not keep arguing after the test has already produced enough evidence.

The useful question is not "could this pass as a person?"

The useful question is "what is the maximum damage this artificial person can do?"

That answer should be small, known and agreed in advance.

Some doors should stay closed

There will be places synthetic customers should not go, or should enter only with strict controls.

Emergency healthcare. Crisis support. Credit decisions. Housing applications. Benefits advice. Legal intake. Safeguarding channels. Anything involving children. Anything where a fake interaction can delay a real person, distort eligibility, create a duty of care or place staff in a moral bind.

"We are only testing the workflow" is not enough in those settings. Workflows are made of human attention, scarce appointments and legal duties. A fake customer can consume all three.

That does not mean regulated sectors cannot use synthetic demand. It means the default should be simulation, recorded role-play, sandboxed records, scheduled test windows, explicit governance and small production probes only where the risk has been named.

The boring question matters most: who might be worse off because this fake person existed for ten minutes?

The market will split

There will be two synthetic-customer markets.

The first will sell theatre. It will promise realistic voices, messy personalities, secret-shopper reports, manager dashboards and the comforting idea that a business can buy insight by sending artificial strangers into the system.

The second will sell containment. Identity controls. Test-number pools. Payment caps. Auto-release bookings. Data labels. Staff policies. Audit trails. Shadow ledgers. Scenario permissions. Cleanup evidence.

The theatre market will be easier to explain. The containment market will be easier to trust.

That trust will become the buying criterion when the first careless deployments create embarrassing residue: fake patients in recall lists, fake refunds in board reports, fake leads in sales targets, fake no-shows in staff reviews, fake complaints in regulator packs.

Synthetic customers will not fail because they are unrealistic. They will fail because they are too real in the wrong systems.