Day 177: An Enquiry Is Not a Customer Dossier

An optional home-address field still needs a reason to exist—even if an assistant could fill it effortlessly.

Imagine a B2B advisory enquiry whose only job is to route a request and arrange contact by email. A home address does neither. I would remove that request, not make it optional or save it for the next conversation. The reply email stays: without it, the firm cannot respond.

For Day 177, my proposed ZSA operating rule is to judge each requested detail by what it enables, not how easy it is to supply. The walkthrough below concerns that fictional enquiry. It is not a deployed form, client practice or measured conversion experiment.

Give each requested detail a purpose

Imagine an advisory firm offering marketing and operations assessments. Its initial enquiry has a narrow purpose: route the request to the appropriate adviser and arrange contact. It does not assess the buyer's organisation, issue a proposal or start delivery.

That boundary makes individual fields easier to judge. The question is not whether a detail could be useful somewhere in the relationship. It is what the firm needs it to do now.

The UK's Information Commissioner's Office describes data minimisation as keeping personal data adequate, relevant and limited to what is necessary for the specified purpose. Adequate matters: collecting too little can also leave the purpose unfulfilled.[1]

Here is how I would apply that principle to this fictional first step.

Keep a reply route and enough context

Reply email: keep it. The firm needs a way to respond and arrange contact. In this scenario, email serves that job; collecting a telephone number as well would need a separate reason. Removing every contact detail would make the form shorter and the requested follow-up impossible.

Area of help: ask whether the enquiry concerns marketing, operations or something else. That enables routing. Include an unsure option so someone does not have to diagnose their own problem before speaking to an adviser.

Brief description: ask what the person wants to discuss, with a short example such as “We need help understanding delays in our enquiry process.” This provides context for the unsure route. Do not invite a full case history. Tell the sender that customer records and private attachments are not needed here.

Company or website: in this stipulated workflow, neither determines routing or the ability to reply, so I would leave both out of the initial request. If another service genuinely needs company context to identify an existing account, that is a different purpose to examine—not a universal ban on the field.

Nor is “business information” automatically outside personal-data rules. The ICO distinguishes information about legal entities from information relating to identifiable individuals, including sole traders. It explicitly identifies a name and corporate email address as personal data.[2] A domain or company description therefore needs assessment in context, not a blanket non-personal label.

Remove requests with no justified purpose

Home address and date of birth: omit them. This fictional advisory enquiry has no stated job for either. Moving them into an optional section would not supply one.

CRM export, customer list or internal report: offer no upload request at this stage. The adviser is arranging a conversation, not diagnosing the business from its records. A later, separately agreed assessment may need selected material, but that does not justify collecting it now on the chance it becomes useful. The ICO specifically warns against that kind of speculative personal-data collection.[1]

An internal report might contain personal data, ordinary commercial secrets, both or neither. Confidentiality is a broader operating concern; not every private business fact is legally personal data. I would still avoid asking for an unnecessary confidential report.

Deferring a request does not automatically make later collection lawful or secure. Any assessment needs its own justified information requirements. Lawfulness, retention and security remain distinct responsibilities; minimisation alone is not a complete compliance programme.[3]

Do not let assistance enlarge the request

Suppose the prospective buyer asks an assistant to prepare this enquiry for review. That is a hypothetical workflow, not evidence that answer engines routinely submit forms.

The proposed intake should still ask only for the reply route, routing choice and brief context. An assistant's possible access to more background is not a reason to request or infer extra personal details. Faster preparation should not turn a contact request into a dossier.

This belongs to ZSA's agentic-workflow work downstream of discovery, including answer-led discovery. It is not a ranking or citation tactic, and no conversion gain is established here.

For the marketing leader, the practical test is this: if every field became effortless to complete, which requests would still have no justified purpose? Remove those requests rather than relabel them optional. In this enquiry, the home address goes and the reply email stays. The aim is not the fewest fields; it is enough information to do the stated job without collecting unrelated details.

The ICO pages cited are under review following the Data (Use and Access) Act. This is a bounded operating proposal informed by UK guidance, not legal advice or a compliance certification.

Sources

[1] ICO, “Principle (c): Data minimisation”: https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-protection-principles/a-guide-to-the-data-protection-principles/data-minimisation/

[2] ICO, “What is personal data?”: https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/personal-information-what-is-it/what-is-personal-data/what-is-personal-data/

[3] ICO, “A guide to the data protection principles”: https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-protection-principles/a-guide-to-the-data-protection-principles/