Fill in your website form as a customer would, asking about a boiler repair, then ask a staff member to open your CRM. They should find a new contact with your name, your phone number, “boiler repair” as the service and the page you came from, so fix anything missing before launch.
Get that test working before you spend any time tracking where every lead came from. Your CRM (customer relationship management system) needs enough detail for someone to call the customer back and a record that shows the inquiry arrived, and once that works, those same records show you which visits bring good inquiries.
To start, write down what counts as a lead for your business, decide who receives each inquiry, and pick a few fields your whole team understands, like the service and where the visit came from.
Decide what counts before adding an event
For a service business, an accepted inquiry might be a working phone number or email plus a request for a service, saved in the CRM your staff use. A qualified lead goes a step further, so it might also need to be in your service area, for work you do, with enough detail to plan the next step. Write those rules down before you decide which Google Analytics event counts as a success.
Google Analytics recommends distinct lead events, including generate_lead, qualify_lead, and close_convert_lead. Together they can follow a lead from the first inquiry to a converted customer, and your own rules decide when each one counts.
Google’s enhanced measurement includes form activity events too, but those come from the browser, so open the CRM and find the record before you call the handoff done.
Follow one inquiry through the whole system
Picture a roofer who gets an estimate request from the service page. The visitor came from a tagged link in the newsletter, filled in the form and now expects the office to reply.
For example, each record could hold:
| Field | Example meaning |
|---|---|
| Inquiry reference | A unique reference for this submission |
| Received time | When the receiving system accepted it |
| Contact details | Only what the team needs to respond |
| Requested service | The service the person selected or described |
| Landing page | Where this visit began, when available |
| Submission page | Where the inquiry was sent |
| Observed source | The source information captured for this visit |
| Customer-reported source | Their answer to an optional discovery question |
| Delivery status | Accepted, awaiting retry, or needs attention |
| Assigned owner | The person or team who replies |
| Qualification and outcome | Staff update this as the inquiry goes on |
Keep the inquiry reference separate from the person’s contact details. The same person can send two real requests and a dropped connection can send one request twice, and the reference is how you tell those apart.
The website should get a clear answer back as well. If the record is already in the CRM when the website replies, the confirmation can say the inquiry reached the team, and if the request is saved but still waiting to go to the CRM, the message can say it was received while staff check later that it arrived. Either way, the customer should read that their request was received, and words like “booked” belong to a real appointment.
Keep the source and allow for gaps
Campaign tags are labels you add to the links you share, and Google documents utm_source, utm_medium, and utm_campaign among other parameters. The values are case-sensitive, so “Newsletter” and “newsletter” show up as two different sources. Pick a short naming rule and use it every time you share a link.
In the roofer’s case, the newsletter link might set the source as the newsletter, the medium as email and the campaign as a fall service reminder. The tags sit in the link and the CRM only gets what the form sends, so when the visitor sends the form, the website has to copy those source fields into the CRM record.
Then decide whether to keep the source of the first visit, the source of the visit when they sent the form, or both. For a small business we think keeping both, in clearly labeled fields, is easier to explain than writing over one field every time the person comes back.
Keep “unknown” on the list as well. A visitor can arrive without tags or a useful referrer, and cookie consent choices or a switch from phone to laptop can hide where they came from, so with “unknown” available your staff can save the record without guessing.
Leave names and contact details out of campaign links and general analytics fields. Google’s data redaction guidance describes ways to keep some information from being collected, and we would also build the form and links so they do not send it at all.
Treat repeat submissions as a delivery problem
Suppose the visitor presses Submit, the server accepts the inquiry and the response never reaches the browser. The visitor tries again, and a basic connection creates two records and two staff notifications, plus two automated messages if the form sends them.
A better setup sends the same inquiry reference when it retries and checks whether the CRM already has that inquiry. Developers call this idempotency, which means sending the same request twice still creates one record.
How that works depends on your form service and CRM, so ask your developer to show you a repeat submission creating one record. A customer should still be able to send a second real request, though, so two separate requests that share an email address stay as two records.
Decide, too, what the customer sees if the CRM is down and where the inquiry waits until it comes back. Give automatic retries a limit and an alert that goes to one person on your team, so they can follow up with the customer.
Run a delivery test with a real staff handoff
Use test contact details your team owns, like a staff email address, instead of a real customer’s, and mark the records as tests. If the form sends messages or creates staff tasks, pick a time when those will not confuse anyone.
Then run these cases and keep the results:
- Submit a valid inquiry from a tagged link, then check the record, the source fields, the assigned owner and the confirmation.
- Submit from an untagged visit and confirm the request still goes through, with the source marked unknown or as observed.
- Leave a required field empty and check that the customer can correct the form without losing the rest of what they typed.
- Repeat the same submission after a simulated slow response and check that it creates one record.
- Simulate a receiving-system failure in a test environment and confirm the customer message, the retries and the staff alert.
- Ask the assigned staff member to find the record and take the next step without help from the developer.
The last case is easy to skip, so make sure the record shows up in the CRM view or inbox your staff check every day.
Compare the counts before you judge your marketing
Pick a month and compare the form submissions your website accepted, the inquiries in your CRM and the lead events in Google Analytics. They can differ for ordinary reasons like test records, blocked analytics or processing delays, so write down the reason for each gap before you count it as lost business.
For any gap you cannot explain, look the inquiry up by its reference and delivery status. Your customers’ contact details should stay in the CRM while you do this, so leave full exports out of the spreadsheet you use to check analytics.
Then look at which inquiries were a good fit. If one service page brings a lot of requests for jobs you do not take on, say more clearly on that page which jobs you do.
If most of your inquiries come through calls or an AI receptionist, use the same definitions there. Our guide to what happens when booking fails shows why a booking attempt and a confirmed booking need separate records.
Keep the report small enough to keep up
A monthly report can show accepted inquiries by source, how many were a good fit, how many still need a reply and any delivery failures. If you ask customers how they found you, put their answers in a column of their own.
For visits from AI tools, our guide to measuring AI search traffic shows how to keep citations and crawler requests out of your lead count. If the website is new, write these rules down before launch, so the data from your first week is ready to use.
Once this works, anyone on your team can find an inquiry, see where its source label came from, check whether someone replied and track down a missing record, and after that you can add more detailed source tracking.
If you would like help connecting your form to your CRM, our Connect page shows what we set up and test.