Website CRM integration should give every genuine enquiry a traceable route from submission to a person who can respond. That means deciding where the request is recorded, how it relates to an existing customer, who receives it and what happens if part of the transfer fails.
For a service business, the practical test is simple: can someone open the enquiry, understand what the customer asked and see who is dealing with it? A successful connection needs to support that everyday task.
This checklist starts after the visitor submits their request. Use it when briefing a developer, reviewing an existing connection or deciding whether an automation is ready to go live. The examples are hypothetical and can be adapted to your own services, team and CRM.
1. Agree what a completed enquiry handover looks like
Start by writing one sentence that describes the outcome you need. For example: “Every accepted quote request appears in the enquiries list, links to the correct contact and has a named owner with a review task.”
Then separate the milestones that make that sentence true:
- Received: the business has a retained record of the submitted request
- Recorded: the relevant CRM records exist and are linked correctly
- Assigned: a person or monitored team queue is responsible for reviewing it
- Acknowledged: the customer's receipt message has been handled
- Reviewed: someone has read the request and recorded what should happen next
These are suggested working labels. Your CRM may use different terminology, and some stages may happen together. What matters is that your team can tell them apart when something goes wrong.
Ask what evidence proves each stage. A CRM record link proves where the enquiry was recorded. An owner and task show responsibility. A timestamp on a review action helps colleagues understand whether anyone has actually looked at it.
Keep the original request visible throughout. If a customer asks about two services in one message, the person responding should see both, even if the first routing rule only recognises one.
2. Map the enquiry to the right CRM records
A contact represents a person. An enquiry represents something that person has asked for. Your business may also use company, opportunity, job or support records. Decide which of those the submission should create or update before connecting the systems.
For a hypothetical maintenance firm, an existing customer's repair request might become an enquiry linked to their contact and property record. A request about a new maintenance contract might start a separate opportunity. Both come from the same person, but colleagues need to handle them differently.
Create a mapping note for every value passed between systems. Record its source, destination, permitted format and update rule. Include system-generated information such as the submission reference and receipt time, as well as the customer's message.
One mapping entry might read: “Service requested goes to the enquiry's service category. Existing contact details remain unchanged unless the agreed update conditions are met.” Another might specify that the original message is preserved as a dated activity rather than replacing an earlier enquiry description.
Check the destination system's actual field definitions. For example, HubSpot's contacts documentation says enumeration properties use internal names, which can differ from the labels displayed to users. It also describes associations between contacts and other records. Those details matter when checking a particular implementation. See HubSpot's contact API guide.
Include an explicit rule for empty values. A blank optional value should not casually erase information that a colleague has already checked. Equally, avoid filling an unknown value with a convenient guess just to make an automation pass.
3. Distinguish a returning customer from a repeated delivery
Two different situations can look like duplicates. A customer may submit a second genuine request, or the integration may deliver the same request again. Write a separate rule for each situation.
For returning customers, decide how matching works and what happens when it is uncertain. An email address may help find an existing contact, but shared office inboxes, changed addresses and spelling mistakes need thought. Treat ambiguous matches as review work rather than automatically combining people who might be different.
Use hypothetical examples when agreeing the rules:
- An existing customer requests a different service: keep the new enquiry visible against the existing relationship
- Two employees use a shared company email address: ask how the business wants people and enquiries represented
- Someone submits a correction to yesterday's request: preserve enough history for the reviewer to recognise the change
Repeated technical deliveries need a different safeguard. Developers call this idempotency: processing a repeated request should not create additional unintended effects. AWS describes using a request token that remains the same when an operation is retried. See its guidance on idempotent operations.
Ask the developer how that principle applies to each action in your handover. Replaying one submission should not produce another opportunity, another assignment task or another acknowledgement simply because the transfer was attempted twice. A genuinely new enquiry needs its own reference. Test both behaviours explicitly.
4. Make routing rules readable by the team
Write routing rules in ordinary language before configuring them. “Existing contract enquiries go to the service desk; new installation requests go to estimating; anything unmatched goes to office review” is a useful starting point for a discussion.
Add a clear order of precedence. If an existing customer asks about a new service, should the account owner keep the relationship, or should the specialist team take over? Decide that deliberately. Otherwise, whichever rule happens to run last may determine the outcome.
Every route needs a fallback. An unrecognised service, missing territory or inactive staff account should leave an enquiry somewhere that a real person checks. Name the person responsible for that queue and the colleague who covers absence.
Be careful with alerts sent to a whole team. Agree how somebody claims an enquiry and how everyone else sees that it has been claimed. Without that convention, two colleagues could reply independently while another request is overlooked.
For each route, record the business reason, owner, fallback and review expectation. Keep the explanation near the configuration so the next person can understand why a rule exists. Review it when responsibilities change, even if the website itself stays exactly the same.
5. Match the acknowledgement to what actually happened
The message shown to a customer should describe the stage the system has reached. If the business has accepted and retained the enquiry, it can confirm receipt. If the enquiry has not been retained anywhere, a confident success message would give the customer the wrong impression.
Choose wording that fits your real process. A hypothetical receipt might say: “Thanks, we have received your enquiry. Our office team will review it and contact you using the details provided.” Add a response window only if the business has agreed it and can manage the expectation.
Avoid implying that a quotation is approved, an appointment is booked or a job has been accepted unless that separate action has genuinely happened. For out-of-hours submissions, explain the review arrangements in terms that remain accurate at weekends and during closures.
Decide what happens if the acknowledgement email cannot be sent. The enquiry should still be available to its owner, with the messaging problem visible for review. Record the appropriate sending status without assuming that a message accepted by an email service has been read by the customer.
Include the acknowledgement in repeat-delivery testing. A recovery process should not repeatedly send the same receipt while trying to finish a different step.
6. Choose a connection your team can support
Possible routes include a CRM's own website tools, a supported connector, an automation platform or a custom API integration. Compare the actual handover requirements against the capabilities available in your account and plan.
A short list of questions is more useful than choosing a tool by familiarity alone:
- Can it create and link the records your team needs?
- Can it preserve the enquiry while another service is unavailable?
- Can you inspect unsuccessful runs and understand the reason?
- Can a failed step be recovered without repeating successful actions?
- Who can maintain the connection when its original builder is away?
Ask for a demonstration using your agreed examples. A connector that handles a straightforward new contact may still need additional work for returning customers, several service teams or partial failures.
Where delayed processing is acceptable, a durable queue can hold work until the receiving service processes it. Microsoft's queue-based load-levelling guidance explains this pattern and notes that durability, capacity and retention limits require attention. A queue also adds operational responsibility; it is not automatically necessary for every small implementation. See Microsoft's queue-based architecture guidance.
Ask where an accepted submission lives during a delay and how staff can find it. The answer should remain clear whichever connection method is chosen.
7. Define retry, correction and recovery behaviour
An unsuccessful transfer needs a specific response. A temporary service interruption, an invalid category value and a permission problem call for different handling. Agree which failures the integration will retry, which need correction and which should alert the responsible person immediately.
Retry behaviour depends on the service and integration route. HubSpot's error-handling documentation, for example, distinguishes API errors, webhooks and workflow actions, with different conditions applying to them. Do not assume that a platform's outbound webhook retry policy also covers your website's inbound enquiry submission. Check HubSpot's error-handling reference for the relevant mechanism.
For automated retries, ask the developer to define the waiting pattern, limit and final escalation. AWS recommends controlled retries with increasing delays and random variation, alongside a stopping condition and checks that repeated operations are safe. See AWS guidance on limiting retry calls.
Your operational recovery note should answer three questions: what is still unfinished, what has already succeeded and what can an authorised person safely do next?
Consider a hypothetical partial failure: the contact and enquiry exist, but the assignment task could not be created. The recovery instruction should identify that missing task. Staff should not have to guess whether to submit the customer's request again or create a second contact manually.
Also agree how a corrected enquiry leaves the failed-work list. Someone needs to verify the intended result, record the resolution and check whether the customer is still waiting for a response.
8. Monitor unfinished enquiries, as well as connection errors
A useful operational view should help the office answer “What needs attention now?” Begin with a short list: accepted enquiries awaiting CRM recording, requests awaiting ownership, failed acknowledgements and enquiries still awaiting their first human review.
Give each item enough context to investigate without opening several unrelated systems. A submission reference, age, current stage, owner and link to the relevant record are useful starting points. Show the latest issue in language the responsible person can understand.
Choose review expectations around your actual opening hours and enquiry types. A firm offering scheduled project consultations may need a different arrangement from one handling time-sensitive service requests. Set internal thresholds that the team can act on, and revisit them when staffing or services change.
Reconcile a sample of accepted submissions against their expected CRM outcomes. Do not compare submissions only with newly created contacts: returning customers may generate new enquiries without generating new people. Use the submission reference to follow the agreed path.
Investigate unexplained gaps even when the connection dashboard looks healthy. It is possible for a request to arrive correctly yet sit in an unattended queue. Have the business owner review the operational picture while the technical maintainer checks connection health.
Keep alerts actionable. Each should say what needs attention, where to inspect it and who is expected to respond. Agree an escalation route for alerts that remain unresolved.
9. Keep personal data out of unnecessary copies
Review where enquiry information will travel: the website, CRM, automation platform, notification channels and diagnostic records. Give each destination a clear purpose and check who can access it.
The ICO's data-minimisation guidance explains that personal information should be sufficient for its purpose, relevant to that purpose and limited to what is needed. Use its official data-minimisation guidance when reviewing what the handover shares. This is a practical planning point, rather than a complete legal compliance assessment.
For example, a team alert may only need an enquiry reference, service category and restricted CRM link. Consider whether copying the full customer message into every notification adds anything useful. Agree access and retention arrangements for temporary copies and troubleshooting records with the people responsible for those systems.
Keep the operational enquiry handover and marketing subscription decisions separately defined. An automation should follow the business's approved process for each, rather than silently treating every enquiry as a request for unrelated messages.
10. Run a handover rehearsal before launch
Use controlled test records with clearly recognisable names and an agreed clean-up process. Involve someone who will handle real enquiries. They should be able to find and review the result without the developer narrating every step.
Start with the ordinary route: a new enquiry reaches its expected record, is assigned correctly and receives the agreed acknowledgement. Then rehearse the situations most likely to reveal gaps:
- A recognised customer submits a separate new enquiry
- The same technical submission is delivered again
- Two similar submissions arrive close together
- A service category has no matching route
- The intended owner is absent or inactive
- The CRM cannot accept the request temporarily
- A mapped value is rejected by the receiving system
- One action succeeds and the following action fails
- The acknowledgement cannot be sent
- A failed enquiry is corrected and recovered
For every test, record the expected result, observed result and remaining issue. Check the customer's experience, the CRM records and the office workflow together. A successful technical response alone does not establish that the right person can act.
Ask a colleague to explain the recovery process back to you. Can they identify the outstanding step? Do they know when to contact the maintainer? Can they avoid repeating work another person has already done?
Resolve material gaps before relying on the new connection. At launch, agree how the team will review the first real enquiries and who can pause a problematic automation while protecting accepted requests.
Keep one owner accountable for the whole handover
Technical maintenance and enquiry handling may belong to different people, but somebody should own the process as a whole. Give that person the mapping notes, routing rules, test results and support contacts.
Record which changes require a fresh check. Adding a service category, renaming a CRM property, changing a team or replacing an integration account can affect the handover. A short change checklist helps the business notice those dependencies before they become missed work.
Review the process after a real exception. Ask whether the right person saw the problem, whether the recovery instructions were usable and whether the customer received an appropriate response. Update the documentation while the details are still clear.
A dependable website CRM integration gives the team a shared understanding of what has happened to each enquiry. The strongest evidence is an ordinary colleague being able to trace a request, take responsibility and deal with an exception confidently.
Frequently asked questions
Does every website enquiry need a new CRM contact?
No. A returning customer may already have a suitable contact record. Decide how to match them and retain the new enquiry against the right relationship. A separate request should remain visible even when the person already exists in the CRM. Uncertain matches should have an agreed review route.
Can we use an automation platform instead of custom development?
Possibly. Check whether the available connector handles your record types, matching rules, assignment and recovery needs. Ask for tests using your real workflow scenarios. The appropriate choice depends on the work required, the tools available in your account and who will maintain the connection.
What should happen if the CRM is unavailable?
Your specification should identify where accepted enquiries are retained, how delayed work is surfaced and who checks it. The recovery plan should establish which steps need completing. If the system cannot retain the request, the customer should receive accurate guidance rather than a misleading confirmation of receipt.
How do we know an enquiry has been followed up?
Agree a visible human action, such as recording a reply or completing a review task with an outcome. Assignment and notification are useful milestones, but neither proves that someone responded. Include outstanding first reviews in the operational checks your team actually uses.
Should the website and CRM synchronise in both directions?
Only add return updates where there is a defined need. For each value, decide which system is allowed to change it and how conflicts will be handled. Start with the enquiry handover you can describe and test. Add further synchronisation when its purpose and ownership are clear.
Plan the connection around your enquiry process
Before discussing tools, gather a few anonymised examples of enquiries, the systems involved and the points where your team currently checks or copies information. Add any exceptions that have caused confusion. That gives a developer a useful starting brief.
Explore Healy Web Design's business automation services for support connecting websites, CRM systems and business processes. To discuss your own enquiry handover, contact Healy Web Design with the workflow you want to improve.
