Which lead details do you need? Design useful forms and CRM records

Start with the promise to the visitor

“Minimum details” does not mean the same three fields on every form. Sending a digital brochure differs from arranging a home visit. First identify what the person receives, through which channel and who acts afterwards.

The European data protection authorities explain that personal data should be limited to what the purpose requires. Test each field: which promised action becomes impossible without it? If nobody can answer, it probably should not be mandatory at first contact.

A shorter form is not the objective by itself. A missing address can prevent a home visit; requiring one for a digital brochure may be unnecessary.

Fields for three enquiry types

These are design choices for these scenarios, not a universal legal checklist. Keep additional marketing signup distinct from the requested service. Assign responsibility for purpose, legal basis and retention. A privacy notice does not replace those decisions.

Add operational information inside the CRM

Staff need process information the visitor should not have to enter. Capture an enquiry ID, form ID, receipt time, original request and source page where reliable. Add an owner, status, next action and action date.

Separate person, enquiry and activity. One person can request a brochure, book a consultation and later start another project. Merging everything by name hides different intentions; creating another person for every click creates duplicates.

An illustrative record:

Enquiry A-1042 · digital bathroom brochure · received 12 October · source: bathroom page · contact: example address · owner: intake team · status: new · next action: establish whether advice is wanted · preferred channel: email.

This fictional record gives origin, intention and responsibility separate places.

Handle repetition and missing information

Treat email or phone as matching signals, not absolute proof of identity. People share contact points and make typing errors. Salesforce's duplicate-record guidance discusses shared contact points as a matching concern.

Receiving the same technical submission twice should not create another enquiry. The same person asking a new question may require one. Have a person review uncertain matches and preserve the merge reason.

Do not fill missing required data with invented values such as “unknown@example.com”. Use an explicit exception status. Missing nonessential context should not prevent a valid request from entering the queue.

Test from form to responsible employee

Include normal submission, blank optional phone, invalid email, repeat submission, an existing contact and a temporary failure. Inspect both the visitor's confirmation and the employee's record.

A success message should correspond to stored, retrievable information with a responsible owner. During a failure, visitors need a clear next step and an internal person must own recovery.

Acceptance checklist

• Every required field serves an identifiable action.
• Optional fields do not block submission.
• Original request and source remain readable.
• Repetition does not create duplicate work.
• Staff see ownership, status and the next step.
• Access and retention are deliberately configured.

Continue with lead follow-up. A correctly captured request matters only when somebody handles it.