Try the process
Follow a chatbot enquiry into a record and a staff task
A useful chatbot handover gives the next person a request, an owner and an accurate status. Run these prepared examples to see why a saved contact, an assigned task and a confirmed booking are different outcomes.
What this demonstration shows
This is an interactive teaching model with fixed rules and dummy records. It runs locally in your browser. It does not use a language model or connect to Messenger, a booking calendar or a CRM, and it is not a client case study.
Each example starts with one existing sample customer. A distinct event may create a new request linked to that contact. The same event delivered again should not create another request. Staff, rather than this model, confirm availability.
Run an example and inspect the records
Choose a prepared case. Each run starts with fresh dummy records. Nothing is sent to Messenger, a CRM or a customer.
Choose an example and run it to inspect the result.
What should happen in each case
| Case | Expected result | What it teaches |
|---|---|---|
| Booking request | One contact, one pending request and one staff task | A preferred day is not confirmed availability |
| Repeated event | One request after processing the same event twice | A delivery retry is different from a new enquiry |
| Missing preferred day | A request and task marked Needs preferred day | Incomplete input stays visible |
| Destination unavailable | No request written; a recovery task remains | An attempted write is not a completed handover |
| Customer asks for staff | A staff task and a paused reply path | Assignment and automation state both matter |
| Unsupported question | A task marked Needs approved answer | The model makes no answer up |
| Existing customer, new request | One contact linked to two distinct requests | Deduplication must not erase legitimate later work |
How to evaluate the same process in actual software
Ask the provider to trace the event through the real inbox, destination record and staff queue in an authorised test environment. Check account permissions, simultaneous deliveries, monitoring and recovery. This local model does not test vendor API behaviour, persistence, production concurrency, language understanding or message delivery.
Manychat documents separate Inbox assignment and conversation states and a Pause all automations action. Its pause action has timing and running-action limitations. The teaching model is not an implementation of those vendor features.
The software comparison guide gives you a broader selection checklist. The Messenger guide explains channel-specific boundaries.
Keep a small test record
For every case, write the starting records, input event, expected result, observed result and unresolved issue. Save a redacted screenshot of both the staff queue and destination. A successful customer reply does not establish that the record was saved.
The model source is available as a JavaScript file. Each click of Run example starts with fresh records for the selected case; changing the selection alone leaves the previous result visible. The model is intended for learning rather than keeping business data.