Worked example
Worked example: a beauty booking brand with a quiet customer list.
One business shape, one simulated week, every number labeled. It shows what the systems would do and where they stop. It is not a result.
Free audit, no accounts, we change nothing.
Or ask a person: aimarketing@gonzo.co.in +91 7390990227 WhatsApp
The problem, before any software
A beauty service that sends a person into the customer's home sells one thing first: trust. The customer is deciding who to let through the door, and that has two consequences for the work behind it.
A stranger who writes at night waits until morning. Inquiries arrive on WhatsApp at any hour. When the first answer comes the next working day, the person has often asked someone else. The business cannot staff the phone all night, and it should not guess at answers about prices or complaints.
The best customers are the ones already on the list. A business like this is built so that the second booking is likely. A past customer who has gone quiet costs almost nothing to write to, compared with a new stranger. But no list can be messaged freely: a customer who never agreed to marketing, or who has since said stop, must not hear from you. Mailing the whole list is the fast way to damage the one thing the business sells.
That leaves four narrow questions. Who may be written to? How fast does a new inquiry get a first answer? What happens to a customer who asks for money back? Who sees it, and can you prove what was sent?
What is stated as fact, and where it is written
Only the facts listed here are stated about Velesia, and they are the owner's own description of the business, not client data. Everything else here is simulated: invented data shaped like this kind of business. Velesia is not a Gonzo client.
- Velesia is a premium beauty service that comes to the customer's home, in Lucknow. Source: The owner's own description of the business
- WhatsApp is the first channel the business uses to talk to its customers. Source: The owner's own description of the business
What this page does not state
- the size of any real customer list, or how many customers consented to what
- any real booking count, average ticket, repeat rate, response time or revenue
- Velesia's real prices, service menu, opening hours or beautician capacity
- anything about Velesia as a client: this is invented data shaped like this kind of business; structural facts are the owner's own, not client data, and Velesia is not a Gonzo client
The simulated week
The sandbox builds a business of this shape from invented parts: a large list of past customers, a smaller group who booked recently, people who never agreed to marketing, some who have opted out, and a stream of new inquiries on WhatsApp and web chat at all hours. Every person is labeled as a sample (for example "Sample Customer 0042", with a phone number of zeros). The existing agents then run on it for four simulated days, on a virtual clock, with a share of external calls made to fail on purpose.
Everything below is output from that run. None of it describes Velesia's customers, volumes or results, and Gonzo has no paying clients.
Which agent would run what
The table maps each stage of a customer's journey to the agent that covers it, and shows where no agent does. Two rows are gaps on purpose: nothing in the Autopilot confirms that a visit happened, and nothing sends review requests.
Who covers which stage
| Stage | Agent | What it does | Status |
|---|---|---|---|
| Traffic | Ads | Moves budget between campaigns inside the owner's caps; pauses a loser. | Built, ran in the sandbox |
| Google Business Profile engine (Velesia repo) | Scores the listing, drafts posts, reads performance. The domain logic exists; the live API is not connected. | Built, not run in this scenario | |
| Enquiry | Lead response | Answers each enquiry on WhatsApp, web chat or email, says it is an AI, answers only from the knowledge base. | Built, ran in the sandbox |
| Receptionist (chat and calls) | Takes chats and calls, offers slots, refuses a double booking. | Built, ran in the sandbox | |
| Qualified | Lead response | Asks up to three questions and bands the lead by the business's own signals; a person follows up. | Built, ran in the sandbox |
| Booked | Receptionist (chat and calls) | Books into the calendar and confirms by message. | Built, ran in the sandbox |
| Dormant revival and rebooking nudges | Books a customer who answers a win-back or rebooking message with yes. | Built, ran in the sandbox | |
| Money lane (owner flag and holding line) | Price, discount, instalment and money-back questions: the system quotes nothing, sends one neutral line and flags the owner. | Built, ran in the sandbox | |
| Finance desk conversation agents (answers, objections, negotiation) | Not used here. They speak as Gonzo and quote Gonzo's products, so they cannot answer a Velesia customer until a Velesia identity and price list are loaded. | Built, not run in this scenario | |
| Served | Watchdog | Watches the booking page and the WhatsApp webhook so a booking is not lost to an outage. | Built, ran in the sandbox |
| Gap | Nothing in the Autopilot confirms that a visit happened or collects feedback afterwards. Today that stays in Velesia's own app and with its staff. | Not covered | |
| Review request | Review and referral loop (Velesia repo) | Specified, drafts for a person. It waits for a bookings-completed trigger that does not exist yet. | Specified only |
| Gap | No agent in the Gonzo Autopilot sends review requests. Nothing here claims to. | Not covered | |
| Repeat | Dormant revival and rebooking nudges | Win-back for quiet customers and rebooking nudges inside the consent gate and a daily cap; stops on a reply or STOP. | Built, ran in the sandbox |
| Money lane (owner flag and holding line) | A money-back or discount ask is never executed by an agent: one neutral line goes out and the owner decides. | Built, ran in the sandbox |
The agents in this scenario are the ones sold as separate systems: Lead Response Engine for inquiries, AI Receptionist for chats and calls, Dormant List Revival for win-back and rebooking nudges, and the monitoring and ad-budget agents described under how it works. No agent in this scenario answers a question about price, a discount, an installment or money back. The customer gets one neutral line, and the owner is told.
What the funnel looked like
The funnel uses the stage names of the sales funnel module and its rule that a rate on fewer than 30 people is not evidence. Several steps here are that small, and each is tagged.
The funnel, stage by stage
| Stage | People | Conversion from the previous stage | Where the number comes from |
|---|---|---|---|
| Traffic | 599 | start of the funnel | sandbox week |
| Enquiry | 37 | 6.2% of the previous stage (37 of 599) Enough people (n of 30 or more) | sandbox week |
| Qualified | 8 | 21.6% of the previous stage (8 of 37) Enough people (n of 30 or more) | sandbox week |
| Booked | 3 | 37.5% of the previous stage (3 of 8) Indicative only (n under 30) | sandbox week |
| Served | 3 | all of the previous stage (3 of 3) Indicative only (n under 30) | sandbox week |
| Repeat | 439 | 39.9% of the previous stage (439 of 1,100) Enough people (n of 30 or more) | simulated booking history |
A rate on fewer than 30 people is arithmetic, not evidence. Steps tagged INDICATIVE must not move money. The same rule is applied to every Gonzo funnel.
Before and after, as process metrics
This is the only comparison on the page. The "before" column is a modeled baseline built from stated assumptions, not a measurement of any business. The "after" column is counted from the sandbox run.
Before and after, on invented customers
Simulated
| Metric | Before (modeled) | After (sandbox run) | How each number was made |
|---|---|---|---|
| Median first reply to a new enquiry (minutes) | 314 | 0.3 | Modelled: a person answers 25 minutes after the desk next opens (09:00 to 17:00, Monday to Friday) or after the enquiry arrives. Measured in the sandbox from the clock: arrival to the first message the system sent, including the one neutral line sent when a case is passed to a person. |
| Enquiries first answered within five minutes (of enquiries) | 0 of 37 | 35 of 37 | Modelled from the same desk assumption. Counted from the sandbox run; the run reacts to each arrival, which a real deployment would need a webhook to do. |
| Enquiries that arrived while the modelled desk was closed (of enquiries) | 25 of 37 | 25 of 37 | Same arrivals in both columns. Same arrivals in both columns. |
| Win-back and rebooking messages sent in the week (messages) | 0 | 325 | Assumed: no systematic win-back programme is running. Counted from the sandbox outbox, inside the daily ramp and the consent gate. |
| Enquiries passed to a person (money, complaint, outside the knowledge base) (of enquiries) | 0 of 37 | 13 of 37 | Not applicable: a person answers everything. Passed on purpose: the system sends one neutral line and flags the owner. |
| Slowest first reply to a new enquiry (minutes) | 972 | 159.3 | Modelled from the same desk assumption: the longest wait is an enquiry that arrives just after closing before a weekend. Measured in the sandbox. A send that failed and was retried later shows up here; nothing was dropped silently. |
The assumptions behind the before column
- A person reads and answers 25 minutes after the desk opens, and the desk is open 09:00 to 17:00, Monday to Friday.
- No win-back programme is running before.
- The sandbox calendar offers slots 09:00 to 17:00 UTC on weekdays. These are not Velesia's service hours.
- Customers, messages, replies and the order in which they arrive are invented and drawn from a fixed seed.
What would need to be connected
Nothing in this example is connected to anything. Adapters for WhatsApp, calendars and email exist in the codebase, and none has ever run against a live account. Before this could run on a real list, each of these would have to exist and be tested live:
- A WhatsApp Business account with an approved re-engagement template, through an official provider.
- The customer list as a read-only export, with the date of each last booking.
- Consent records stored somewhere a STOP survives a restart, and a recorded basis for every person who would be written to.
- A booking calendar the agents can read, so a slot offered is a slot that exists.
- The owner's limits for anything touching money, set once and written down.
- Read and budget access to the ad accounts, only if the ads agent is wanted.
The order matters. The first piece of real work would be a free audit of the list and the consent records, which would establish the real numbers that this page deliberately does not state. See the free audit.
What was not verified
- Not run against any live system. No real customer, message, booking or ad account was touched.
- The 'before' column is a modelled baseline built from stated assumptions. It is not a measurement of Velesia.
- No result is claimed. A simulated week says the machinery behaves as built; it says nothing about demand.
- The finance desk's conversation agents speak as Gonzo and use Gonzo's price book, so they were not run on Velesia customers: every money question got one neutral line and a flag to the owner.
- Complaint detection is keyword-based. In testing, a complaint phrased without the trigger words was not recognised and received an ordinary reply, so a person must still read the inbox.
- A review-request step does not exist in the Autopilot. Confirmation that a visit happened is not covered.
- Rebooking nudges reuse the win-back wording with a shorter window; dedicated rebooking copy is not written.
- The ads agent is USD-only today, so its figures are sandbox USD and its ad copy is not shown.
- Adapters for WhatsApp, calendars and email exist in the codebase and have never run against a live account. Consent persistence and the customer list export are not built.
- The consent shares on the list are invented. The shares on a real list are unknown until a consent audit measures them.
See it as a client would
The dashboard demo shows this same run as a client's page: the funnel, the coverage map, the consent gate, the owner's inbox, a check of the audit chain that runs in your browser, and a kill switch you can trip. It is a demonstration and is labeled as one.
What is stated as fact, and where it is written
Only the facts listed here are stated about Velesia, and they are the owner's own description of the business, not client data. Everything else here is simulated: invented data shaped like this kind of business. Velesia is not a Gonzo client.
- Velesia is a premium beauty service that comes to the customer's home, in Lucknow. Source: The owner's own description of the business
- WhatsApp is the first channel the business uses to talk to its customers. Source: The owner's own description of the business
What this page does not state
- the size of any real customer list, or how many customers consented to what
- any real booking count, average ticket, repeat rate, response time or revenue
- Velesia's real prices, service menu, opening hours or beautician capacity
- anything about Velesia as a client: this is invented data shaped like this kind of business; structural facts are the owner's own, not client data, and Velesia is not a Gonzo client
The simulated week
The sandbox builds a business of this shape from invented parts: a large list of past customers, a smaller group who booked recently, people who never agreed to marketing, some who have opted out, and a stream of new inquiries on WhatsApp and web chat at all hours. Every person is labeled as a sample (for example "Sample Customer 0042", with a phone number of zeros). The existing agents then run on it for four simulated days, on a virtual clock, with a share of external calls made to fail on purpose.
Everything below is output from that run. None of it describes Velesia's customers, volumes or results, and Gonzo has no paying clients.
Which agent would run what
The table maps each stage of a customer's journey to the agent that covers it, and shows where no agent does. Two rows are gaps on purpose: nothing in the Autopilot confirms that a visit happened, and nothing sends review requests.
Who covers which stage
| Stage | Agent | What it does | Status |
|---|---|---|---|
| Traffic | Ads | Moves budget between campaigns inside the owner's caps; pauses a loser. | Built, ran in the sandbox |
| Google Business Profile engine (Velesia repo) | Scores the listing, drafts posts, reads performance. The domain logic exists; the live API is not connected. | Built, not run in this scenario | |
| Enquiry | Lead response | Answers each enquiry on WhatsApp, web chat or email, says it is an AI, answers only from the knowledge base. | Built, ran in the sandbox |
| Receptionist (chat and calls) | Takes chats and calls, offers slots, refuses a double booking. | Built, ran in the sandbox | |
| Qualified | Lead response | Asks up to three questions and bands the lead by the business's own signals; a person follows up. | Built, ran in the sandbox |
| Booked | Receptionist (chat and calls) | Books into the calendar and confirms by message. | Built, ran in the sandbox |
| Dormant revival and rebooking nudges | Books a customer who answers a win-back or rebooking message with yes. | Built, ran in the sandbox | |
| Money lane (owner flag and holding line) | Price, discount, instalment and money-back questions: the system quotes nothing, sends one neutral line and flags the owner. | Built, ran in the sandbox | |
| Finance desk conversation agents (answers, objections, negotiation) | Not used here. They speak as Gonzo and quote Gonzo's products, so they cannot answer a Velesia customer until a Velesia identity and price list are loaded. | Built, not run in this scenario | |
| Served | Watchdog | Watches the booking page and the WhatsApp webhook so a booking is not lost to an outage. | Built, ran in the sandbox |
| Gap | Nothing in the Autopilot confirms that a visit happened or collects feedback afterwards. Today that stays in Velesia's own app and with its staff. | Not covered | |
| Review request | Review and referral loop (Velesia repo) | Specified, drafts for a person. It waits for a bookings-completed trigger that does not exist yet. | Specified only |
| Gap | No agent in the Gonzo Autopilot sends review requests. Nothing here claims to. | Not covered | |
| Repeat | Dormant revival and rebooking nudges | Win-back for quiet customers and rebooking nudges inside the consent gate and a daily cap; stops on a reply or STOP. | Built, ran in the sandbox |
| Money lane (owner flag and holding line) | A money-back or discount ask is never executed by an agent: one neutral line goes out and the owner decides. | Built, ran in the sandbox |
The agents in this scenario are the ones sold as separate systems: Lead Response Engine for inquiries, AI Receptionist for chats and calls, Dormant List Revival for win-back and rebooking nudges, and the monitoring and ad-budget agents described under how it works. No agent in this scenario answers a question about price, a discount, an installment or money back. The customer gets one neutral line, and the owner is told.
What the funnel looked like
The funnel uses the stage names of the sales funnel module and its rule that a rate on fewer than 30 people is not evidence. Several steps here are that small, and each is tagged.
The funnel, stage by stage
| Stage | People | Conversion from the previous stage | Where the number comes from |
|---|---|---|---|
| Traffic | 599 | start of the funnel | sandbox week |
| Enquiry | 37 | 6.2% of the previous stage (37 of 599) Enough people (n of 30 or more) | sandbox week |
| Qualified | 8 | 21.6% of the previous stage (8 of 37) Enough people (n of 30 or more) | sandbox week |
| Booked | 3 | 37.5% of the previous stage (3 of 8) Indicative only (n under 30) | sandbox week |
| Served | 3 | all of the previous stage (3 of 3) Indicative only (n under 30) | sandbox week |
| Repeat | 439 | 39.9% of the previous stage (439 of 1,100) Enough people (n of 30 or more) | simulated booking history |
A rate on fewer than 30 people is arithmetic, not evidence. Steps tagged INDICATIVE must not move money. The same rule is applied to every Gonzo funnel.
Before and after, as process metrics
This is the only comparison on the page. The "before" column is a modeled baseline built from stated assumptions, not a measurement of any business. The "after" column is counted from the sandbox run.
Before and after, on invented customers
Simulated
| Metric | Before (modeled) | After (sandbox run) | How each number was made |
|---|---|---|---|
| Median first reply to a new enquiry (minutes) | 314 | 0.3 | Modelled: a person answers 25 minutes after the desk next opens (09:00 to 17:00, Monday to Friday) or after the enquiry arrives. Measured in the sandbox from the clock: arrival to the first message the system sent, including the one neutral line sent when a case is passed to a person. |
| Enquiries first answered within five minutes (of enquiries) | 0 of 37 | 35 of 37 | Modelled from the same desk assumption. Counted from the sandbox run; the run reacts to each arrival, which a real deployment would need a webhook to do. |
| Enquiries that arrived while the modelled desk was closed (of enquiries) | 25 of 37 | 25 of 37 | Same arrivals in both columns. Same arrivals in both columns. |
| Win-back and rebooking messages sent in the week (messages) | 0 | 325 | Assumed: no systematic win-back programme is running. Counted from the sandbox outbox, inside the daily ramp and the consent gate. |
| Enquiries passed to a person (money, complaint, outside the knowledge base) (of enquiries) | 0 of 37 | 13 of 37 | Not applicable: a person answers everything. Passed on purpose: the system sends one neutral line and flags the owner. |
| Slowest first reply to a new enquiry (minutes) | 972 | 159.3 | Modelled from the same desk assumption: the longest wait is an enquiry that arrives just after closing before a weekend. Measured in the sandbox. A send that failed and was retried later shows up here; nothing was dropped silently. |
The assumptions behind the before column
- A person reads and answers 25 minutes after the desk opens, and the desk is open 09:00 to 17:00, Monday to Friday.
- No win-back programme is running before.
- The sandbox calendar offers slots 09:00 to 17:00 UTC on weekdays. These are not Velesia's service hours.
- Customers, messages, replies and the order in which they arrive are invented and drawn from a fixed seed.
What would need to be connected
Nothing in this example is connected to anything. Adapters for WhatsApp, calendars and email exist in the codebase, and none has ever run against a live account. Before this could run on a real list, each of these would have to exist and be tested live:
- A WhatsApp Business account with an approved re-engagement template, through an official provider.
- The customer list as a read-only export, with the date of each last booking.
- Consent records stored somewhere a STOP survives a restart, and a recorded basis for every person who would be written to.
- A booking calendar the agents can read, so a slot offered is a slot that exists.
- The owner's limits for anything touching money, set once and written down.
- Read and budget access to the ad accounts, only if the ads agent is wanted.
The order matters. The first piece of real work would be a free audit of the list and the consent records, which would establish the real numbers that this page deliberately does not state. See the free audit.
What was not verified
- Not run against any live system. No real customer, message, booking or ad account was touched.
- The 'before' column is a modelled baseline built from stated assumptions. It is not a measurement of Velesia.
- No result is claimed. A simulated week says the machinery behaves as built; it says nothing about demand.
- The finance desk's conversation agents speak as Gonzo and use Gonzo's price book, so they were not run on Velesia customers: every money question got one neutral line and a flag to the owner.
- Complaint detection is keyword-based. In testing, a complaint phrased without the trigger words was not recognised and received an ordinary reply, so a person must still read the inbox.
- A review-request step does not exist in the Autopilot. Confirmation that a visit happened is not covered.
- Rebooking nudges reuse the win-back wording with a shorter window; dedicated rebooking copy is not written.
- The ads agent is USD-only today, so its figures are sandbox USD and its ad copy is not shown.
- Adapters for WhatsApp, calendars and email exist in the codebase and have never run against a live account. Consent persistence and the customer list export are not built.
- The consent shares on the list are invented. The shares on a real list are unknown until a consent audit measures them.
See it as a client would
The dashboard demo shows this same run as a client's page: the funnel, the coverage map, the consent gate, the owner's inbox, a check of the audit chain that runs in your browser, and a kill switch you can trip. It is a demonstration and is labeled as one.
Start with the free audit.
Send one web address. In about five business days you get a short written report. If a system fits, a fixed-price scope follows.
Free audit, no accounts, we change nothing.
Or ask a person: aimarketing@gonzo.co.in +91 7390990227 WhatsApp