From enquiry to the next step
Try routing an enquiry to the right person without multiplying contacts. See what to link, when to pause and how to recover from a failure.
Choose a fictional enquiry and inspect the decision before automating it.
Fictional data only. The demo sends no enquiries, emails or CRM data; it uses no network or storage. Its memory disappears on reload. These rules are illustrative, not a third-party integration or a customer outcome.
Starting point: Alex Example · alex@example.test · owner: Account team. Changing scenario resets the example.
- Incoming enquiry
ENQ-102 · Sam Example · sam@example.test
Fictional request: connect the website form to sales follow-up.
- Decision
Ready. This enquiry has not been processed.
- Owner and next step
No task yet. Process the scenario to see the next step.
Contacts in memory: 1 · Tasks in memory: 0
What you can check
This interactive demonstration uses four fixed scenarios, with no fields for personal data. Each scenario starts with one fictional contact. Processing the same submission ID again adds no extra task; changing scenario or resetting returns the example to its starting point. Nothing is saved when you leave.
The logic runs in your browser. It does not connect forms, providers or a real CRM. It sends no follow-up: it shows a task for a person to review. The no-network and no-storage boundary applies to the simulator; the project button opens the existing commercial enquiry flow.
Transcript of the four scenarios
New enquiry
ENQ-102 arrives from Sam Example, using sam@example.test. It does not match the starting contact. The example creates CONTACT-102 and a task for the Sales team: confirm scope and required data. Processing ENQ-102 again keeps just one new contact and one task.
Known contact
ENQ-103 arrives from Alex Example. The email alex@example.test matches exactly after trimming surrounding spaces. The example keeps CONTACT-101 and its owner, the Account team. It adds a task to review this new enquiry; it does not discard the request because the contact already exists. A shared mailbox or conflicting details would require a different policy and review.
Ambiguous match
ENQ-104 has the same name, Alex Example, but uses alex.other@example.test. A name does not establish identity. Linking pauses without merging records or creating sales tasks. A person must confirm identity through an authorised channel. This example implements neither that check nor a real exception inbox.
Failure and retry
ENQ-102 arrives and a failure is simulated before saving. One starting contact and zero tasks remain. Operations must inspect the exception; “Retry the same submission” recovers the scenario using ENQ-102 and creates just one task. Recovery is deliberately deterministic so it can be tested. In production, a timeout may leave an uncertain result: the destination would need checking before repeating the write.
What to agree before connecting it
Define the source of truth, what identifies a submission and what identifies a contact. Decide who reviews uncertain matches, what data they can see and how to preserve preferences and owners. Do not remove dots or “+” tags from email addresses by default. Separate receiving an enquiry from permission to send marketing.
Also test repeated messages, changed email addresses, insufficient permissions and destination outages. Agree on audit records without unnecessary information, retry limits, retention and recovery. This bounded demo does not demonstrate those capabilities in your tools.
Prepare your own workflow
Write down the enquiry source, destination tool, owner and a common exception. Use invented examples without passwords or customer exports. We can then review fit and prepare a proposal with a defined scope.
Prepare my project · Email Taldrivo · Custom CRM development · Preparing a project quote