1. Map the journey of one enquiry
Start with an ordinary enquiry: the visitor submits information, the website accepts it, the integration sends it to the CRM, a record is created or updated, and someone receives a task. Name an owner and a success signal for every handoff.
Do not combine “accepted by the website”, “delivered to the CRM” and “being handled” into one status. These are different events. A database record does not mean anyone is working on it if no owner has been assigned.
For the first launch, choose one channel and one enquiry type. Expand after testing normal cases, repeated events and failures.
2. Agree on a field map
This is a discussion example, not a universal mandatory list. Collect only what the selected workflow needs rather than adding personal information “just in case”.
| Field | Purpose | Decision to make |
|---|---|---|
| Event identifier | Recognise repeated delivery | Who creates it and where it is stored |
| Received time | Reconstruct the event order | Time zone and format |
| Contact channel | Reply to the person | Accepted values and validation |
| Enquiry topic | Route to the right owner | Topic list and an “undetermined” option |
| Enquiry page | Preserve context | Which part of the address is needed |
| Source and campaign tags | Keep available acquisition information | Rules for missing or conflicting values |
| Owner and next action | Turn the enquiry into a task | Assignment, fallback owner and action |
Record a missing source as unknown rather than inventing one. Do not retain the full page address when it may contain unnecessary personal or secret parameters.
3. Separate repeated events from new enquiries
The same request can arrive again after a repeated submission or recovery from a failure. This differs from an existing customer making a new enquiry, and the handling rules should reflect that.
- The same event: repeated delivery should not create an identical second task.
- The same person, a new task: preserve the new context instead of silently discarding the enquiry.
- A similar contact: do not merge people merely because their names match.
Agree on how existing contacts are identified and which fields can be updated. What may be added? What must not be overwritten? How is an ambiguous match handled? These decisions should be explicit in configuration and tests, not left to a team member’s guess.
4. Treat failure handling as part of the workflow
An external service may not respond, may reject data or may accept a request without producing the expected result. Each situation needs an observable status and a next action.
Separate temporary failures that can be retried under an agreed rule from invalid data that needs correction. Retries need limits; sending indefinitely is not a recovery strategy.
Assign someone to receive failure notifications and explain manual recovery: how to find the event, check the CRM and safely repeat delivery. Logs can include the identifier, stage and error reason. They should not include passwords, tokens or full private enquiry text by default.
5. Accept the integration through scenarios
Use agreed test data and an agreed environment. Do not message real customers merely to check an integration.
| Scenario | Expected result |
|---|---|
| Ordinary enquiry | Fields, source, owner and next action are retained |
| The same event delivered again | No identical second task |
| New enquiry from an existing contact | The new context is preserved |
| A required field is missing | A clear error rather than false success |
| The CRM is temporarily unavailable | A visible failure and agreed recovery route |
| Recovery after failure | The enquiry arrives without extra records |
| The source is unknown | Uncertainty is explicitly retained |
Check the record in the destination system and the assigned task. A response from an intermediary service is not sufficient acceptance evidence for the full journey.
6. Hand over more than a connection
The handover should include the route map, field table, duplicate rules, test results and failure instructions. Name the person responsible for changing each part.
Short specification: enquiry source …; destination system …; required fields …; duplicate rule …; owner assignment …; failure handling …; successful delivery means … .
After launch, assess technical delivery separately from team handling. An integration can deliver correctly without resolving a missing owner or an unclear next action.