Connecting website enquiries to a CRM: what to agree before the build

A website-to-CRM integration needs more than a form and a connection. Someone has to decide where each enquiry belongs, what happens when a contact already exists and how the client finds out when something fails.

For an agency, those decisions affect the scope you quote and the work you hand over. Use this checklist to agree the important details before choosing a connector or asking a developer to build the connection.

Decide what a successful enquiry should create

Start with the action, not the tool. Should a submission create a contact, a lead, an enquiry, a task or more than one record?

Agree what happens next. A record saved in the CRM does not prove a salesperson has been assigned or notified. If those steps are needed, include them in the scope and testing.

Set the direction, expected volume and acceptable delay. This checklist concerns website enquiries moving into a CRM; historical imports, attachments and updates flowing back to the website are separate scope choices. Immediate delivery and a scheduled batch are different requirements.

Write the desired result in one sentence. For example: “An accepted website enquiry creates a new enquiry linked to the appropriate contact, with the selected service and an owner for follow-up.”

If you are still preparing the wider project, start with the development brief for agency projects. This guide covers the connection decisions in more detail.

Map the form fields to the CRM

List what the form collects, where it belongs and what makes it valid. Check the destination’s required fields and accepted values, not just the labels the website displays.

Include server-side validation and spam/abuse handling in the scope. Browser checks alone do not protect the receiving endpoint.

A service dropdown might show “Website support” while the CRM expects an internal option code. A field called “Company” might need an organisation record rather than a text value. Those differences need a decision before information starts moving.

Fictional field-mapping example

This is an illustrative specification, not a client project or a universal CRM setup. The destination fields and rules must be checked against the actual system.

In this example, each new submission creates an enquiry linked to a contact. A matching email links it to an existing contact; several matches go for review rather than an automatic merge. Existing contact details stay unchanged.

Scroll horizontally if needed to see every column.

These field names, matching rules and limits are fictional choices. The real brief needs the client’s approved values, including what to do when matching is uncertain.

Include only information needed for the agreed workflow. Confirm the client’s privacy requirements and any separate marketing-permission fields; do not infer a marketing opt-in from an enquiry.

Separate returning contacts from repeated deliveries

These are different situations:

• The same submission arrives twice. A retry should not create a second enquiry for the same submission reference.
• The same person sends another enquiry. That may be a genuine new request, linked to an existing contact rather than discarded as a duplicate.
• The website and CRM disagree. Decide which fields the website may update and which existing CRM values must be preserved.

Agree the matching rules with the client. Do not assume that finding an email address means every existing field can be overwritten. Test a returning contact and a repeated submission separately.

Be precise about the confirmation message

Distinguish “the website received your message” from “the enquiry is saved in the CRM”. A third-party service accepting a request is not, by itself, evidence of every downstream step completing.

If the website saves the enquiry safely for background processing, it can acknowledge receipt while CRM delivery is still pending. That needs a real stored submission, a way to track delivery and someone responsible for unresolved failures.

If nothing has been accepted or stored, do not show a success message. Agree a useful retry instruction or alternative contact route instead. The visitor should not have to understand the integration to know what happened.

Agree what happens when the CRM is unavailable

Connections can fail because of temporary outages, rate limits, missing permissions or invalid data. They should not all be handled in the same way.

Agree which temporary failures can be retried, how retries avoid duplicate records and when processing stops for review. Invalid field values or revoked access may need a person to fix the cause rather than the same request being repeated indefinitely.

Keep enough information to investigate: a submission reference, timestamps, delivery state and a useful error category. Do not copy entire enquiry messages, access tokens or unnecessary personal information into logs and alerts.

A failed delivery needs an owner. Specify who sees the problem, how they check it and what happens if it remains unresolved. An alert existing somewhere is not the same as someone being responsible for it.

Confirm access, ownership and handover

Before building, check that the available API or connector can perform the required actions. Confirm account-plan restrictions, permissions and who can authorise the connection. If the tool has no suitable interface, investigate the options before promising a workaround.

The client should know which accounts and configuration the integration depends on. Agree appropriate access, where secrets are held and how access can be withdrawn. Do not put credentials in the project brief or a public website script.

Handover should explain the field mapping, matching rules, configuration, delivery checks and recovery process. Clarify who maintains the connection if the CRM changes, and whether monitoring or ongoing support is included. Those are scope decisions, not automatic features of every build.

Test the flow before the client signs it off

Use clearly labelled test data and an agreed test environment or authorised production test. Do not send real customer records around simply to demonstrate the connection.

Check the outcomes, not just whether the form button works:

• A valid new enquiry reaches the intended CRM record with the agreed fields.
• An existing contact follows the matching rule without overwriting protected values.
• A repeated delivery of the same submission does not create another enquiry.
• A genuine second enquiry from the same person is handled as agreed.
• Missing or invalid fields produce useful feedback and no misleading confirmation.
• A CRM outage leaves the visitor with accurate receipt/failure information and the team with a traceable delivery state.
• A timeout after possible CRM creation can be investigated or retried without creating duplicates.
• Revoked access or an invalid field mapping becomes visible to the agreed owner.
• The handover explains how to check and resolve a failed delivery.

Also test any separately scoped assignment, notification and source-tracking steps. Do not infer them from the existence of the CRM record.

Copy this integration-scoping checklist

WEBSITE-TO-CRM CONNECTION
Website/form and CRM involved:
Direction, expected volume and acceptable delivery delay:
What a successful submission creates:
Any assignment or notification required:

DATA AND MATCHING
Website fields and intended CRM fields:
Required fields, formats and allowed values:
Server-side validation and spam/abuse checks:
How an existing contact is identified:
Which existing values may be updated:
How genuine repeat enquiries are handled:
Stable submission reference and repeated-delivery rule:

DELIVERY AND FAILURES
When the visitor receives confirmation, and what it confirms:
Where a pending submission is safely stored, if applicable:
Which failures can be retried and when retries stop:
Who checks unresolved failures and how:
What minimal logs/alerts are needed:

ACCESS AND HANDOVER
Required accounts, plan features and permissions:
Client privacy and data-handling requirements:
Who owns configuration, recovery and future maintenance:
Acceptance tests and agreed test environment:
Open questions before a quote can be confirmed:

A written answer can be “undecided”. It is better to scope an investigation than hide an assumption in the quote.

Need help connecting the parts?

Odd Little Bits provides API integration services for small agencies, connecting websites, CRMs and other business tools with an agreed scope and written updates.

Send the tools involved, what information should move and the decisions you need help with. Please do not send passwords, access tokens or confidential customer records.