Website With an Enquiry Form and CRM: How the Process Should Work

A contact form is not an enquiry-management system.

A basic form collects a few fields and sends an email. A website with an enquiry form and CRM creates a structured record, shows who needs to act, keeps the customer's details with the opportunity and supports the steps that follow: qualification, reply, quote, booking, payment and review.

That difference becomes important as soon as enquiries arrive through several channels or more than one person handles them. An inbox can show that a message was received. It rarely shows whether the lead was suitable, who replied, when follow-up is due, whether a quote was accepted or why the work was lost.

This guide explains how the website-to-CRM process should work, what the form should collect, how to avoid duplicate or unusable records and what to check before buying a system. It focuses specifically on lead capture; the complete website and CRM package guide covers the wider enquiry-to-payment operation.

Contents

1. What does a website and CRM integration do?
2. The correct enquiry workflow
3. What an enquiry form should ask
4. How the CRM record should be structured
5. Routing, ownership and response tasks
6. Acknowledgements and follow-up automation
7. Spam, duplicates and failed submissions
8. Connecting enquiries to quotes, bookings and payments
9. Privacy, marketing consent and retention
10. Security and supplier access
11. SEO and conversion requirements
12. What to measure
13. Implementation and testing checklist
14. Common mistakes
15. Frequently asked questions

What does a website and CRM integration do?

CRM stands for customer relationship management. Microsoft describes CRM as a system for managing, tracking and storing information related to current and potential customers in one central location. See Microsoft's explanation of CRM.

A website-to-CRM integration should take information supplied through the website and place it into that central process in a consistent form.

At minimum, it should:

• receive the form submission securely;
• create or update the correct contact;
• create a separate enquiry or opportunity record;
• store the service, location, message and other relevant fields;
• record when and where the enquiry originated;
• assign an owner or queue;
• set an initial status;
• acknowledge receipt to the customer;
• alert the right person;
• create a visible next action;
• retain a reliable history of subsequent activity.

The integration should not depend on staff copying details manually from an email. Manual copying adds delay and creates inconsistent records, spelling errors and missing fields.

Form notification versus CRM record

These are different things.

A notification tells someone that an event occurred. It may be an email, mobile alert or task.

A CRM record is the lasting source of information and status. It should remain usable even if an email notification is deleted, forwarded, marked as read or sent to spam.

A robust setup uses notifications to draw attention to the CRM record, not as a substitute for it.

The correct enquiry workflow

The process should be designed before the form is built.

1. A potential customer reaches the right page

The page should explain the service, who it suits, the service area, relevant evidence and what happens after an enquiry. A form cannot compensate for a vague page.

When several services have different requirements, each important service should have its own route or pass the selected service into the form automatically. This gives the customer a more relevant experience and reduces manual sorting.

2. The form captures a useful minimum

The form asks only for information needed to make the next decision. Required fields are clearly distinguished from optional fields.

3. The submission is validated

The system checks that required information is present and that fields are plausible. Validation should help the customer correct an error rather than simply reject the form.

4. The server accepts and records the submission

The submission should be written to the CRM or a reliable intermediate queue before the customer is told it succeeded. A green confirmation message displayed while the integration silently fails is dangerous because the customer believes the business has the enquiry.

5. The contact is matched or created

The system checks whether the person or organisation already exists. It may match on verified email address, telephone number or another suitable identifier.

It should not merge records aggressively on weak similarities. Two people can share a name, telephone numbers can be reused and business emails can be shared.

6. A separate enquiry is created

The enquiry should have its own date, source, service, value estimate where appropriate, owner, status and next step.

One contact can make several enquiries. Keeping them separate prevents a new job from overwriting the history of an old one.

7. The customer receives an accurate acknowledgement

The acknowledgement confirms safe receipt and explains what happens next. It should not claim that availability has been checked or a quote prepared when neither has happened.

8. The right person is assigned

The system routes the enquiry based on agreed rules such as service, territory, location, team, value or current workload.

9. A response task becomes visible

The CRM should show that the enquiry requires action and when. A status such as "new" is not enough if nobody owns the next step.

10. Replies and outcomes stay with the record

Calls, emails, notes, quotes and follow-ups should be associated with the enquiry. The final outcome should be recorded as booked, won, lost, withdrawn, unavailable or unsuitable, ideally with a useful reason.

What an enquiry form should ask

There is no universal perfect form. The right fields are the smallest set that lets the business respond intelligently.

Core contact fields

Most service businesses need:

• name;
• email address;
• telephone number when it is genuinely useful;
• service or reason for enquiry;
• a message or structured description.

Do not require both telephone and email merely because a template includes them. Decide how the business actually responds and give the customer reasonable choice where possible.

Service-specific fields

Useful additional fields may include:

• postcode or area;
• preferred date or timescale;
• event or job date;
• venue;
• property or project type;
• approximate size or quantity;
• package interest;
• budget range where it materially affects suitability;
• existing-customer status;
• file upload where photographs or documents are genuinely needed.

A DJ enquiry might need an event date, venue and event type. A web-design enquiry might need the current website, business type and main objective. A trade enquiry might need the postcode, urgency and a concise description of the fault.

The form should reflect the decision the business makes next.

Required versus optional fields

Make a field required only when the business cannot take the next step without it.

An optional field can still be useful. For example, a customer may not know the final venue when checking a DJ's availability, but town or general area may be enough for an initial assessment.

Overuse of required fields creates false data: customers enter "N/A", choose an arbitrary option or abandon the form.

Use structured choices where they improve accuracy

Dropdowns, radio buttons and checkboxes work well where the options are known and meaningful. They improve routing and reporting because the CRM receives consistent values.

Use open text where the customer genuinely needs to explain something. Do not force a complex requirement into a list that does not fit.

A balanced form may use structured fields for service, date and location, followed by a short open question such as "What would you like help with?"

Avoid collecting information too early

Some details belong after qualification or booking, not at first contact.

Examples include:

• full planning questionnaires;
• detailed medical or accessibility information;
• payment-card details;
• identity documents;
• extensive marketing profiling;
• every member of an event's contact details.

The ICO's data minimisation guidance says personal data should be adequate, relevant and limited to what is necessary for the purpose. Staging data collection also makes the first enquiry easier to complete.

Label fields clearly

Placeholder text inside a field is not a reliable replacement for a visible label because it disappears when the customer starts typing. The W3C's guidance on labels or instructions explains that users need labels or instructions when content requires input.

Good labels are specific:

• "Event date" rather than "Date";
• "Postcode where the work is needed" rather than "Postcode";
• "Telephone number for this enquiry" rather than "Phone".

Help text should explain unusual formats and why sensitive-looking information is needed.

Make errors easy to correct

The form should identify the field with a problem, explain it in text and preserve the customer's other answers. The W3C's error-identification guidance supports clear, specific feedback when input errors are detected.

Avoid a generic message such as "There was an error" at the top of a long form. The user should not have to hunt for the problem.

How the CRM record should be structured

Poor record design turns a capable CRM into an expensive notes app.

Keep contacts and enquiries separate

The contact record should identify the person or organisation and hold relatively stable details.

The enquiry record should represent a particular commercial request.

A contact might be:

Alex Smith, alex@example.com, 07123 456789

That same contact could have:

• a birthday DJ enquiry in 2026;
• a company event enquiry in 2027;
• a referral to another customer;
• a cancelled booking and a later confirmed booking.

If all of that is stored in one free-text contact note, reporting and follow-up become unreliable.

Recommended enquiry fields

A small service business may need:

• enquiry ID;
• date and time received;
• linked contact or organisation;
• service;
• source and landing page;
• location;
• requested date or timescale;
• original message;
• assigned owner;
• current stage;
• next action and due date;
• estimated or quoted value where useful;
• quote status;
• booking status;
• payment status;
• outcome;
• loss or disqualification reason;
• communication history.

The system does not need every field on day one. It needs the fields required to answer operational questions.

Preserve the original submission

Staff may correct spelling, standardise a postcode or add qualification details. The original form submission should still be available or auditable so that later edits do not erase what the customer actually sent.

Record source accurately

Useful source fields may include:

• organic search;
• Google Business Profile;
• paid campaign;
• direct visit;
• referral;
• social media;
• partner;
• returning customer;
• unknown.

Store the landing page and relevant campaign parameters where appropriate. Do not rely entirely on a required "How did you hear about us?" dropdown; customers often do not remember the exact route, and technical attribution can supply useful supporting evidence.

Source tracking should be proportionate and explained through the site's privacy and cookie information where required.

Use controlled statuses

Statuses should represent meaningful stages. A practical sequence could be:

1. New
2. First response due
3. Waiting for customer
4. Qualified
5. Quote required
6. Quote sent
7. Follow-up due
8. Booked or won
9. Lost
10. Not suitable

Each active stage should imply an owner and next action. "In progress" is usually too vague.

Record why enquiries do not convert

Useful reasons include:

• unavailable date;
• outside service area;
• service not offered;
• price or budget mismatch;
• customer chose another supplier;
• no response;
• duplicate;
• spam;
• timescale unsuitable;
• reason unknown.

Do not force staff to guess. A small number of well-defined reasons is more useful than an exhaustive list nobody completes.

Routing, ownership and response tasks

An enquiry is most likely to be neglected when responsibility is implied rather than explicit.

Assign one accountable owner

Several people may collaborate, but one person or queue should be accountable for the next response. The record should show who that is.

Routing may use:

• service type;
• customer location;
• account ownership;
• staff skill;
• availability;
• rota;
• business hours;
• lead value or urgency.

Keep rules understandable. A complicated routing engine that nobody can explain is difficult to troubleshoot.

Separate urgent from important

A customer ticking "urgent" does not necessarily establish operational priority. Define the conditions that change routing, such as a safety issue, an event within seven days or an existing contractual service level.

The form can collect the relevant facts, while the CRM applies the rule.

Create a due task, not just an alert

An email alert disappears in the flow of the day. A CRM task remains open until completed or reassigned.

A useful task includes:

• the action required;
• the owner;
• the due time;
• the linked enquiry;
• escalation rules where appropriate.

For example:

Review wedding DJ enquiry for 18 July, check availability and reply by 10:30 tomorrow.

That is more actionable than "New lead received".

Define response expectations honestly

The website and acknowledgement can state a realistic response window, such as "within one working day". Do not promise a 15-minute reply unless the business is staffed to provide it.

Outside-hours enquiries may need a different acknowledgement. The system should use the business's actual operating schedule rather than pretending every submission is monitored continuously.

Acknowledgements and follow-up automation

Automation should reduce uncertainty and prevent omissions. It should not impersonate a human decision.

The immediate acknowledgement

A good acknowledgement includes:

• the customer's name where safe and appropriate;
• a concise summary of the service or date requested;
• confirmation that the details arrived;
• what happens next;
• a realistic response window;
• an urgent contact route where relevant;
• a copy or reference number if useful.

It should not say:

• "Your date is available" unless availability was genuinely checked;
• "Your booking is confirmed" when it is only an enquiry;
• "I have reviewed your request" when the message is automatic;
• "We will definitely call at 9am" unless a call is scheduled.

Internal reminders

Good internal automation might:

• create a first-response task;
• escalate an unowned lead;
• remind the owner when a quote has not been sent;
• flag a quote with no follow-up date;
• close obvious spam;
• ask for a reason when an enquiry is marked lost.

Customer follow-up

Follow-up should depend on the record's state.

Examples:

• no reply after requesting essential information;
• quote sent but no decision after an appropriate period;
• deposit link sent but unpaid;
• provisional date nearing expiry;
• completed job ready for a review request.

Stop rules are essential. A customer who declines, pays, cancels or asks not to be contacted should not continue through an old sequence.

Read How to Follow Up Enquiries Without Feeling Pushy for practical message examples.

Templates should support, not replace, judgement

Templates improve consistency for common replies, but staff should be able to edit them and address the customer's actual question.

A polished irrelevant template is worse than a short useful response.

Spam, duplicates and failed submissions

A lead system must handle imperfect traffic and technical failures.

Spam protection

Possible controls include:

• hidden honeypot fields;
• rate limits;
• bot-detection services;
• server-side validation;
• blocking known abusive patterns;
• attachment restrictions;
• manual review queues for uncertain submissions.

Avoid making every real customer solve repeated image puzzles. Security controls should be proportionate to the risk and tested for accessibility.

Duplicate handling

The system should decide separately whether to:

• link a new enquiry to an existing contact;
• merge two contact records;
• reject an exact repeated submission;
• preserve repeated attempts that indicate a technical or customer-service issue.

Two submissions from the same email address may represent two different jobs. Matching a contact does not mean discarding the second enquiry.

Idempotency and repeat clicks

Customers double-click submit buttons, refresh pages and retry after slow responses. The integration should be designed to avoid creating several identical opportunities or sending several acknowledgements.

The interface can disable the button after a valid submission starts, but server-side duplicate protection is still needed because browser controls are not enough.

Failed integrations

Plan for the CRM being temporarily unavailable.

A resilient process may:

• place the submission in a secure retry queue;
• alert an administrator;
• retry safely without creating duplicates;
• keep an auditable failure log;
• avoid telling the customer it succeeded until the submission is safely accepted somewhere reliable.

At minimum, conduct a regular test submission. A form can appear normal for months while a changed email setting or expired integration credential prevents leads from arriving.

Email deliverability

Acknowledgement and notification emails should be sent through a properly configured service using the business's domain. Domain authentication and monitored bounce handling reduce the risk of messages being rejected or impersonated.

Do not use the customer's supplied email address as the technical "From" address. Use the business's authenticated address and place the customer in the reply-to field where appropriate.

Connecting enquiries to quotes, bookings and payments

The enquiry record should move forward without retyping the same information.

Qualification

The business may need to confirm:

• service fit;
• location;
• date or capacity;
• budget;
• scope;
• decision-maker;
• timescale;
• required credentials or access.

Qualification should be proportionate. A £50 standard service does not need an enterprise sales process.

Quote creation

A quote should pull the customer's details and relevant job information from the enquiry. It should state what is included, price, validity, payment terms, expected timing and acceptance method.

The CRM should record when it was sent, viewed or accepted where the system supports that, while avoiding unsupported assumptions. "Email delivered" is not the same as "customer read and understood the quote".

Booking conversion

When a quote or request becomes a booking, the system should create a booking record with the confirmed date, service, status and payment requirements. It should not overwrite the original enquiry.

For date-led work, the guide to a website with a booking system explains instant booking, request-to-book and hybrid models.

Deposits and balances

The CRM should show whether a deposit has been requested, paid, failed or refunded and when the remaining balance is due.

A hosted provider such as Stripe Payment Links can provide a payment page that is linked from the website or email. Payment success should update the correct customer and booking using a reliable transaction reference, not merely a redirect to a "thank you" page.

Invoices

Where invoices are issued, make sure they contain the required information and use a consistent numbering process. GOV.UK sets out the basic requirements in Invoices - what they must include.

The operational CRM and accounting platform can be separate systems, but their responsibilities and synchronisation must be clear.

Privacy, marketing consent and retention

The form is a point of personal-data collection. Privacy cannot be added as an afterthought once the integration is live.

Give privacy information clearly

The ICO explains that organisations collecting personal data must provide specified privacy information. Its guidance on what privacy information should be provided covers identity, purposes, lawful basis, recipients, retention and individual rights.

The form should link to an understandable privacy notice. A short just-in-time explanation may be useful where a field's purpose is not obvious.

Separate the enquiry from marketing permission

A customer can submit an enquiry without agreeing to unrelated promotional email.

Do not use wording such as:

By sending this form, you agree to receive news and offers.

The operational messages needed to answer the enquiry are different from future direct marketing. Where consent is the chosen basis for marketing, make it optional, specific and recorded. The ICO's electronic mail marketing guidance explains the PECR rules and the conditions around the "soft opt-in".

Record the evidence behind consent

Where the form captures marketing consent, the CRM should retain:

• the exact wording shown;
• the date and time;
• the source form;
• the affirmative choice;
• the version of the privacy information where needed;
• withdrawals or suppression status.

A simple marketing = yes field with no provenance may be inadequate evidence.

Set retention periods

Unsuccessful enquiries, completed customer records, financial documents and marketing records may have different retention needs.

The ICO's storage limitation guidance says personal data should not be held longer than necessary. The CRM should support deletion, anonymisation or review rather than keeping every message indefinitely.

Understand processors and integrations

The data may pass through:

• website hosting;
• form software;
• CRM provider;
• email service;
• analytics platform;
• automation service;
• payment provider;
• support contractor.

The business remains responsible for understanding that chain, putting appropriate contracts in place and giving accurate privacy information. The ICO's updated guidance on data protection by design and by default recommends considering privacy at the design stage and throughout the system's lifecycle.

Security and supplier access

A CRM may contain customer contact details, commercial information, event dates, property details, payment status and private correspondence. Access should be controlled accordingly.

Account controls

Use:

• individual accounts rather than shared passwords;
• multi-factor authentication;
• least-privilege roles;
• prompt account removal when staff or suppliers leave;
• strong recovery procedures;
• logs for important changes;
• periodic access reviews.

Website and integration controls

The technical setup should include:

• encrypted HTTPS connections;
• server-side validation;
• protected API credentials;
• secret rotation where appropriate;
• restricted integration permissions;
• update and patch management;
• backups;
• monitored errors;
• protection against mass form submission;
• a documented response to a data or account breach.

The National Cyber Security Centre's small organisations guide gives practical guidance on accounts, devices, phishing, backups and incident preparation.

Supplier access should be temporary and accountable

A web developer or support provider may need access during setup. Confirm:

• which systems they can access;
• whether they use named accounts;
• whether multi-factor authentication is enabled;
• how access is removed;
• what customer data they can view;
• how support copies and exports are handled;
• what happens at contract end.

Do not leave a permanent all-powerful administrator account merely because it was convenient during launch.

SEO and conversion requirements

A form works only after the right visitor reaches it and feels confident enough to submit.

Match the page to the enquiry

Each key service page should answer the questions relevant to that service and lead to a form that already knows the service selected.

Do not force a wedding customer, boiler customer and web-design prospect through the same generic "Nature of enquiry" box when the website already knows which page they used.

Put the form at the right point

A form can appear:

• after the core service explanation;
• in a clear contact section;
• behind a specific call to action;
• as a short first step followed by conditional questions.

Putting a long form before any evidence or explanation is usually premature. Hiding the only form behind several vague buttons is equally unhelpful.

Use clear calls to action

The button should describe the outcome:

• Check availability
• Request a quote
• Ask about your project
• Book an initial call
• Send job details

"Submit" describes the website's action, not the customer's goal.

Do not create thin pages for every keyword variation

Google recommends useful, reliable, people-first content rather than pages made primarily to manipulate rankings. See its guidance on creating helpful content.

Create a distinct page when the service, audience, location or decision process genuinely differs. Do not publish dozens of near-identical pages that replace only a town name.

Keep important information outside the form widget

Service descriptions, coverage, pricing guidance, reviews and FAQs should remain in accessible page content. A third-party form or embedded CRM interface should not contain the only useful information on the page.

What to measure

Measure the full lead path, not form counts in isolation.

Acquisition measures

• sessions to relevant service pages;
• traffic source;
• landing page;
• call-to-action use;
• form starts;
• form completion rate;
• technical failure rate.

Operational measures

• number of genuine enquiries;
• first-response time;
• enquiries without an owner;
• overdue follow-ups;
• qualification rate;
• quote rate;
• time from enquiry to quote;
• duplicate and spam rate.

Commercial measures

• enquiry-to-booking conversion;
• quote acceptance rate;
• average booking value;
• revenue or potential value by source;
• deposit completion rate;
• cancellation rate;
• common loss reasons.

Interpret the figures in context. A page may generate fewer enquiries after the form is improved but produce more suitable work. Quantity without fit can create admin rather than revenue.

Use outcome data to improve the website

Examples:

• Many "outside area" leads suggest the service area is unclear.
• Many price mismatches suggest better price guidance is needed.
• Many unavailable dates may justify an availability prompt or alternative offer.
• Many incomplete enquiries may indicate confusing fields.
• Strong conversion from one service page may justify deeper content around that service.

The CRM should create a feedback loop into website decisions.

Implementation and testing checklist

Process design

• Define what counts as an enquiry.
• Define required fields for each service.
• Define owners and routing rules.
• Define response expectations.
• Define stages and outcomes.
• Define when a quote, booking and payment record is created.
• Define marketing and privacy handling.
• Define retention periods.

Form build

• Use visible labels.
• Mark required fields clearly.
• Include specific error messages.
• Preserve entered data after an error.
• Make the form keyboard accessible.
• Test on mobile.
• Limit file types and sizes.
• Add proportionate spam controls.
• Link the privacy notice.
• Keep marketing choice separate.

CRM setup

• Separate contacts and enquiries.
• Set controlled service and source values.
• Assign an owner.
• Create first-response tasks.
• Configure duplicate rules conservatively.
• Store the original submission.
• Set meaningful stages.
• Require an outcome or reason where useful.
• Restrict permissions.

Integration tests

Test:

• a new customer;
• an existing customer with a new enquiry;
• two people with the same name;
• duplicate clicking;
• invalid fields;
• a large or unsafe attachment;
• obvious spam;
• CRM downtime;
• email delivery failure;
• acknowledgement wording;
• routing for every service;
• source and landing-page capture;
• consent evidence;
• mobile and keyboard completion.

Ongoing checks

• Send a real test enquiry regularly.
• Review failed integration logs.
• Review unassigned and overdue records.
• Audit staff and supplier access.
• Update form choices when services change;
• review retention and deletion;
• check automated messages after price, policy or branding changes.

Common mistakes

Sending the form only to an email address

The message may arrive, but status, ownership and follow-up remain invisible.

Creating a contact but no enquiry record

Repeated opportunities from the same person become mixed together.

Asking for every possible detail at once

The first form becomes too long and collects information before it is needed.

Treating a successful browser message as proof of CRM delivery

The customer sees "thank you" while the integration has failed in the background.

Making marketing consent compulsory

The customer should be able to ask about the service without being forced into unrelated promotions.

Sending a fake-personal automated reply

Automation should be transparent about what has and has not been reviewed.

Having statuses with no next action

A lead can sit in "new" or "in progress" indefinitely when nobody owns a due task.

Merging contacts too aggressively

Similar names or shared details can cause separate people and opportunities to be combined incorrectly.

Measuring leads but not outcomes

The business cannot tell which pages and sources generate suitable, paid work.

The practical conclusion

A useful form-to-CRM setup removes the gap between "someone contacted us" and "someone is responsible for the next action".

The website should collect a relevant minimum, validate it clearly and confirm only what has genuinely happened. The CRM should create a structured enquiry, assign ownership, keep communication and commercial stages visible and preserve the path from first contact to final outcome.

The goal is not automation for its own sake. It is a dependable process in which good enquiries cannot quietly disappear into an inbox.