How to distinguish redelivery from a new enquiry, confirm receipt and keep work running during a CRM failure.
A customer submitted a form, saw a success message, and closed the page. The manager opened the CRM, but the inquiry was missing. Another customer clicked the button again, creating two identical records. These hypothetical situations are worth examining before launch: a success screen does not show what happens to the request next.
Here we examine acceptance testing for a specific process at a company in Kazakhstan: enquiries arrive from the website and bot, while employees work in CRM. If the process has not yet been chosen, start with about the first automation. The next step is to agree how to verify that every enquiry has been retained.
Assign a source of truth for each state
Decide where an employee checks receipt, handoff results and ongoing work with the customer. These may be different places: a request log confirms receipt, while the CRM card stores the assigned manager and processing status. Link the records so the entire journey of a request can be reconstructed.
Describe states in plain words: “saved”, “awaiting transfer”, “created in CRM”, “requires review”. A notification in the team chat must not be the only evidence of receipt. If the message is deleted or missed, the original enquiry should remain available in the agreed location.
Distinguish a delivery retry from a new inquiry
Every accepted enquiry needs a stable identifier. A retry to deliver the same request must retain that identifier so the system can detect an action already completed. Ask to see it both in the original record and alongside the transfer result. This is clearer than looking for matches by time and name.
The same phone number alone does not mean a duplicate: a customer may order another product or inquire about a new site. Agree separately on repeated button clicks, technical delivery retries, and independent new requests. If someone first uses the form and then the bot, a questionable match is best sent for review while preserving both inquiries.
Preserve the meaning of the enquiry during transfer
Review the record from a manager's perspective. It should contain the agreed information: source, contact, selected product or service, request text, and necessary clarifications. If someone selected an option from a catalog, it helps to save its name or link so the employee does not have to reconstruct the choice from the conversation.
For Russian and Kazakh messages, check that letters, line breaks, and the original meaning are preserved. If the automation creates a short summary, keep a route to the original text. Do not replace an unknown value with a guess: a missing quantity or convenient contact time should be visibly marked for clarification.
Confirm only results that have been achieved
Customer-facing text must match the enquiry’s status. If the request is safely saved and awaiting transfer, receipt can be confirmed. Do not say it has been assigned to a manager until the assignment is confirmed. Do not promise a response time that the team has not agreed and cannot control.
Test failed submissions too: a clear message should explain the available action, such as retrying or using another listed contact method. On-screen confirmation must not appear before the request is saved. If an enquiry number is provided, make sure an employee can actually find the record using it.
Examine unavailability and an uncertain response
When the CRM is unavailable, the request needs a visible pending status and an agreed retry procedure. A separate case is when the request was sent but no response came back. The record may already exist. Before creating it again, check the result using its identifier; if that cannot be checked, the request needs manual investigation rather than a silent decision.
Agree on when waiting becomes a problem and who is notified. After recovery, check the entire backlog: which inquiries arrived, which are still queued, and which were handled manually. The recovery procedure matters more than a single “the service is working again” message.
Assign an exceptions owner and a manual fallback
Every unprocessed request needs an owner, including when the main employee is absent. Specify where they see the queue, how they contact the customer and how they record manual actions. After manually creating a record, preserve its link to the original identifier so that automation does not create another record when it resumes.
The fallback process must be practical for the team. Access to received requests, a record of completed actions and a clear shift handover are more useful than “tell the developer if something fails”. Test this workflow with the employee who will actually use it.
Accept the process using a verifiable template
For each scenario, record the input data, identifier, expected state, actual record, responsible person and confirmation of review. Use fictitious contact details agreed for testing. Include the following in the test record:
- A normal submission from the form and bot: the contents are preserved, and the record is accessible to an employee.
- Repeated delivery: one enquiry did not create a second working card.
- A new inquiry from the same customer: a separate task has not disappeared as a duplicate.
- Unavailability and lost responses: the enquiry remains visible and the next action is defined.
- Manual recovery: the result is linked to the original record, preventing duplicate processing.
At the end, reconcile unique accepted inquiries with those delivered, pending, and requiring review. There should be no unexplained gaps. You can discuss this check in the section GIFS AI and automation: send the current processing chain and examples of exceptions without real personal data.