“All done.”
It is a reassuring message from an AI assistant. It is also an incomplete description of a business transaction.
In our fictional garden-service example, the agent submitted a request for Tuesday. The company has not accepted it. In the jacket example, the agent prepared a cart but still needs the customer’s approval. Both may represent useful progress. Neither establishes the final outcome.
As agents take on more steps, we need better descriptions of what happened. The customer needs confidence that the task is complete. The business needs an accurate workload and sales record. Marketing needs to understand whether the journey is helping suitable customers.
Decide what completion means
For a service inquiry, completion might mean the request was received and assigned to someone. For a confirmed appointment, it means the business accepted the date and scope. For an order, it means the merchant created the order with the agreed details; payment and fulfillment remain additional states to check.
Write those definitions before interpreting the dashboard. A click on “Submit” is an attempted action. A successful response can establish receipt, depending on what the system actually recorded. A booking reference linked to an accepted appointment is stronger evidence of the commitment.
This is an extension of the measurement approach in Is your SEO attracting the right customers: follow meaningful activity into business records. With delegated actions, the handoff deserves particular attention because the person may not have watched the process happen.
Five records that tell different stories
Consider this illustrative sequence. It is not an OBVS traffic study.
- A server records a request for the service page. Information was accessed; this alone does not identify a customer or their intention.
- A browser records a click on “Request Tuesday.” An action was attempted; receipt is still unverified.
- The business receives request R104. The inquiry exists, but the appointment is pending.
- A retry returns the same request R104. It is another interaction concerning one inquiry, not automatically another lead.
- Staff accept the appointment and issue confirmation B208. A commitment now exists. Whether the visit takes place and satisfies the customer remains to be established.
Use the record explorer below to compare a confirmed booking, a pending inquiry and a failed submission. The words in the report should change when the evidence changes.
Five events. How many bookings?
Inspect a fictional journey one record at a time. Change what happens after submission and watch which conclusions remain justified.
- Recorded inquiries
- 0
- Accepted bookings
- 0
The record set does not establish the acquisition source. Keep it unknown.
Read the evidence trail
A page request establishes access. A submit click establishes an attempt. Request R104 establishes one inquiry. A retry returning R104 points to the same inquiry. Acceptance B208 establishes one booked appointment. None of these records alone proves payment, attendance, satisfaction or where the customer first discovered the business. If submission failed before receipt, there is no recorded inquiry. If acceptance never arrived, the inquiry remains pending.
Traffic reports see different parts of the journey
A crawler reading a public page, a human arriving from an AI answer, and an agent interacting with a signed-in service are different kinds of activity. There is no reason to expect one analytics report to describe all three completely.
Google Analytics automatically excludes known bot and spider traffic, and its documentation says you cannot see the quantity excluded. That does not establish that every AI browser session is detected, or that every unusual visit is an agent. Google Analytics documentation
Our recommendation is to compare the appropriate records: server or firewall logs for observed requests, analytics for measured visits and events, and booking, order or customer systems for recorded outcomes. Where a supported integration supplies a trustworthy identifier, retain it with the relevant action record. Where the source is unknown, keep it unknown.
Do not label all direct traffic as AI, count a crawler as a prospective buyer, or assume one customer produces one request. Delegated work and retries complicate those shortcuts. A browser that never records your analytics event can still create a request in the business system; an analytics event without a matching record does not prove the request arrived.
Our earlier article on what AI visibility tools actually measure addresses mentions, citations and sampling. Here, the additional question is what happened after the information was used.
Make failures recoverable
Suppose the appointment service receives R104, but the confirmation response never reaches the agent. A second submission could create duplicate work unless the integration knows it is a retry.
Developers call one relevant safeguard idempotency: repeating the same operation should not accidentally repeat its effect. Stripe documents this for supported API requests. It is an example of a design pattern to discuss with the provider of your booking or transaction system, not a claim that every form already behaves that way. Stripe documentation
For customers, an uncertain response should trigger a status check before another purchase attempt. For businesses, provide a reference, a clear pending or failed state, and a route to support. Test a timeout after receipt as well as a failure before submission. Those cases can look similar on screen but require different recovery.
Keep approval records tied to the actual action and details. If the price, date or scope changes materially, do not assume an earlier approval covers the new proposal. Store only the information needed for operation, support and an appropriate audit record, with access and retention rules for personal data.
Judge the customer outcome
The opportunity is straightforward. If an agent helps someone compare requirements, eliminate unsuitable options and complete the right next step, the customer may spend less effort and the business may receive a better-prepared inquiry. Those are hypotheses to test in your own journey, not a promised conversion uplift.
Review accepted bookings or orders alongside cancellations, returns, duplicate requests, staff correction time and customer feedback. Faster checkout is a poor result if the wrong product arrives. More appointment requests are expensive if the team spends its day correcting unsuitable bookings.
Compare equivalent periods and document changes to promotions, tracking and qualification. Where volume permits, a controlled test can help isolate an improvement. Where it does not, inspect individual cases and state the uncertainty. Neither method justifies assigning every new sale to the agent.
Start with a journey you can inspect
Choose one task and define its completion record. Assign an owner for exceptions. Test success, refusal, timeout and recovery with test records or a consenting participant. Review whether the customer received an accurate explanation at each stage.
Business owners can then decide whether to expand the route. Marketing teams can report what the evidence actually supports. Customers can ask for the confirmation and terms that matter before relying on “all done.”
That is the standard we would apply at OBVS: make the offer understandable, make the permitted action usable, and check the outcome against the customer’s original need. If a particular journey on your website needs that attention, bring it to OBVS.
Define what you will count.
A useful measurement brief tells your team which business record supports the outcome—and what still cannot be known.
The CSV contains every record in the selected fictional journey. It is teaching data, not an OBVS traffic or conversion report.