Website Integrations: CRM, Forms and Analytics Requirements

Integrations are a data flow, not a plugin

Ask most organizations what integrations their website needs and you will get a list of tools: the CRM, the email platform, analytics, maybe a booking system. That list is a start. It is not a requirement anyone can build to.

A useful integration requirement describes a flow. Someone fills in a form. Some data goes somewhere. Something happens next. Someone is responsible. A record of where that person came from is kept so marketing can tell what is working. Consent is captured so you can follow up legally. Each of those steps is a decision, and every one that goes undecided becomes either a gap or a change order.

The easiest way to define it is to follow a single inquiry from first click to closed deal and write down every handoff. The rest of this guide is the list of questions to answer along the way.

Forms: what you collect, and why

Every field on a form is a cost to the visitor and a promise to the business that someone will use the data. Start each form by asking what the person handling the inquiry actually needs to respond well.

• Required fields should be the minimum needed to respond: usually a name, a way to reach them, and what they need.
• Qualifying fields (service of interest, location, timeline, organization size) are worth including when they change how the inquiry is routed or prioritized. If nobody uses the answer, remove the field.
• Hidden fields carry context the visitor does not type: the page they submitted from, the campaign that brought them, the language of the page.

Decide how many distinct forms you need. A quote request, a general question, a job application and a newsletter signup are different processes with different owners. Sending them all through one “contact us” form into one inbox is how sales ends up sorting resumes.

Also decide what the visitor sees after submitting: a confirmation page that sets expectations (“we reply within one business day”), and a confirmation email if appropriate. A dedicated confirmation page is also useful for measurement.

CRM: field mapping, routing and duplicates

“Forms go to the CRM” is not a requirement. These are:

1. Which object is created? A lead, a contact, a deal, a ticket? It depends on how your sales process is set up in the CRM, and the person who administers it needs to be in the conversation.
2. Which field maps to which? Write it down form by form, including picklist values. If the form offers six services and the CRM has five, someone has to decide what happens to the sixth.
3. What happens with duplicates? When an existing client fills in a form, does it update their record, create a duplicate, or flag it for review?
4. Who is assigned, and how? By service, region, language, or round robin? Write the rule.
5. What if the connection fails? Integrations break when a password changes or a field is renamed. There should be a fallback (such as an email notification with the full submission) so no inquiry disappears silently.

The connection itself can be a native integration, a form tool with a CRM connector, an automation platform in between, or custom code. The right choice depends on your CRM, your volume and who will maintain it. The questions above apply regardless.

Consent and privacy

A form that collects personal information is a privacy decision, and in Canada it touches more than one set of rules. Federal private-sector privacy law governs how commercial organizations collect and use personal information, Canada’s anti-spam legislation (CASL) governs commercial electronic messages such as marketing emails, and Quebec has its own privacy requirements if you serve people there. Your specific obligations depend on your organization and sector, so confirm them with counsel. The practical requirements for the website are fairly consistent:

• Separate consents. Agreeing to be contacted about an inquiry is not the same as agreeing to receive a newsletter. If you want to add people to marketing email, ask with its own checkbox, unticked by default, with clear wording.
• Record the consent. The CRM or email platform should store what the person agreed to, when, and on which form, so you can show it later.
• Say what happens to the data. Link to a privacy policy that matches what you actually do, including which tools receive the data.
• Cookie and tracking consent should match your analytics and advertising setup, and the settings should be respected by the tags that fire.

The measurement side of this, including how to keep useful analytics while respecting consent, is covered in privacy-conscious marketing measurement in Canada.

Analytics and attribution

Analytics should mirror the business process, not just count pageviews. For each form and conversion path, define an event: what triggers it, what it is called, and which details it records (form type, service, language). Agree on names before development so reports make sense to someone who did not build them. The conversion tracking plan before launch walks through this in detail.

Then connect analytics to the CRM. Analytics knows where visitors came from. The CRM knows which inquiries became revenue. Neither can tell you which marketing produces clients unless source information travels with the inquiry. In practice that means capturing campaign parameters and the first landing page in hidden fields, storing them on the CRM record, and keeping them there when the lead becomes a deal.

Expect the two systems to disagree on counts. Analytics may miss submissions from visitors who decline tracking, and the CRM will include inquiries that arrived by phone. That is normal, and why GA4 and your CRM report different lead numbers explains how to reconcile them. Decide in advance which system is the source of truth for which question.

Where tags are managed (directly in the site code, through a tag manager or server-side) is a separate decision with its own trade-offs, covered in tag manager vs direct tags vs server-side tagging.

Operational handoffs: who does what next

The integration is only as good as what happens after the data arrives. This is the part most website projects leave out, because it is not website work. It decides whether the website produces business.

• Notification: who is alerted, by what channel, and is there a backup when they are away?
• Response time: what is the internal expectation, and does the confirmation page promise the same thing?
• Qualification: who decides whether an inquiry is a real opportunity, and where is that recorded? Without this, marketing cannot tell good leads from noise.
• Language: in a bilingual organization, does a French inquiry reach someone who can respond in French?
• Feedback: how does sales tell marketing which sources produce good clients?

An illustrative example: a hypothetical commercial cleaning company in Halifax has a quote form that emails the owner. The redesign scopes it properly. Quote requests create a deal in the CRM with service type, building size and the source campaign. The operations lead is assigned and notified, with a backup on weekends. Newsletter consent is a separate unticked box recorded with a timestamp. Analytics records a quote request event with the service type. A monthly report compares quote requests by source with deals won. None of it is complicated, and all of it would have been invisible in a requirement that said “CRM integration.”

Test the whole chain before launch

Test every form end to end on the staging site and again on launch day: submit it, confirm the CRM record has the right fields and source data, confirm the right person was notified, confirm the consent was recorded, and confirm the analytics event fired once with the right details. Then test failure: what happens if a required field is empty, or the CRM connection is down? The guide to testing whether your website tracking is working has a fuller procedure.

Integrations are scoped during discovery on our website projects for exactly this reason: an integration discovered mid-build is a surprise, while one written down as a data flow at the start is just work. Keep the document after launch. When someone renames a CRM field or changes a form two years from now, it is the map that tells them what else will break.