A website enquiry often starts a much longer process. Someone reads it, enters the details into another system, assigns it to a colleague and decides what to do next. Connecting the website to a CRM can make that process more consistent, especially when the team is handling several enquiry types.
The connection is only part of the job. Before choosing a plugin or asking for an API integration, agree how an enquiry should move through the business. A form arriving successfully in a database is useful only if the right person can recognise it and take the next step.
Map one real enquiry from start to finish
Choose a common request, such as a customer asking for a service visit or a trade buyer asking about an account. Write down what the visitor submits, what the team needs to know and how the request reaches its owner today. Include any manual copying, missing information or repeated questions.
Then describe the intended process. A new enquiry might create a lead, assign a service category and notify a relevant team. Another may need human review before anything is scheduled. Keep those decisions separate from the tool used to deliver them.
Our website development and integration work starts with that map. It provides a practical specification the business and developer can both check.
Collect information with a clear purpose
A CRM can store far more than a first enquiry needs. That does not mean the website form should ask for everything. Include information that helps the team respond and explain why a detail is needed when it is not obvious.
The ICO’s data minimisation guidance says personal information should be adequate, relevant and limited to what is necessary for the purpose. Apply that thinking when deciding which details enter the website, the integration and the CRM.
A service enquiry may need a postcode to identify the right team. A full set of account details may belong later in the process. Consider the customer’s effort alongside the information your staff actually use.
Agree where each piece of information belongs
Field mapping sounds technical, but the decisions are very practical. Is a company name stored against a person, an organisation or both? Which field contains the requested service? Does a postcode need a consistent format? What happens if a customer already has a record?
Keep a simple mapping document with the website field, CRM destination and any transformation or rule. Establish which system is authoritative for information that can change. If staff update a telephone number in the CRM, a later website interaction should not silently overwrite it with an older value without an agreed reason.
- Identify the record type being created or updated.
- Define required fields and accepted values.
- Agree how existing customers are matched.
- Record routing and ownership rules.
- Specify what counts as a successful handover.
Choose the connection around the workflow
A native form or supported connector may be enough for a straightforward process. A custom connection can be appropriate when the business has specific rules or several systems to coordinate. The choice should reflect maintainability as well as the initial setup.
APIs let systems exchange information through defined interfaces. Webhooks can notify another system when an event happens. Microsoft’s Dataverse webhook documentation illustrates that event-driven pattern, including authentication and execution considerations. The exact behaviour still depends on the CRM and integration being used.
For an online shop, orders and customer records may introduce additional requirements. WooCommerce documents API access to external systems, but the presence of an API does not establish that stock, order and CRM rules are already connected correctly.
Plan for the times the connection fails
External systems have outages, credentials expire and requests can time out. Decide how the website handles that situation without misleading the customer. A success message should correspond to a defined outcome, rather than appearing simply because a button was pressed.
A dependable implementation may keep an appropriate record of the request, retry a temporary failure and alert the responsible team. It should also avoid creating several leads when the same request is retried. The design must respect the actual provider’s API behaviour and limits.
Think about the operational view too. Staff need a way to identify an enquiry that failed to transfer and to recover it safely. A technical log that nobody checks will not help a customer waiting for a reply.
Protect the connection and its credentials
Keep private credentials on the appropriate server or secure integration service, away from public page code. Give the integration only the access it needs and document how that access can be revoked. Access for creating a lead should be assessed separately from access to export an entire customer database.
Validate the information received from the website and protect any endpoint that accepts external events. WordPress security guidance covers important practices such as checking permissions and handling input and output appropriately. The implementation needs to reflect the actual platform rather than assuming a plugin name proves the whole connection is safe.
Test what the team will see
Use an agreed test environment and fictional data. Try a normal enquiry, missing information, an existing customer, an unsupported value and a temporary CRM failure. Check that the correct record is created, the intended owner sees it and the customer-facing message is accurate.
Where notifications or automated follow-ups are part of the design, arrange testing so real customers are not contacted. Review the wording and timing before enabling them. A clear handover should explain the fields, rules, failure alerts and person responsible for checking them.
A practical example, without invented results
In our Ace Gas project, website enquiries are sent into Leadzilla through an API integration. The website also provides ServiceM8 booking routes. These are distinct parts of the setup; describing them accurately is more useful than implying that every system is connected directly to every other one.
The general lesson is to name the action and destination precisely. Does the website create an enquiry, request a booking or confirm an appointment? Customers and staff should share the same understanding.
Ongoing care needs to include the integration when the website depends on it. If you want to connect your website and CRM, bring us the journey you want to improve, including how your team handles the enquiry today. That gives the technical work a clear purpose.