Ask for enough to understand the need and decide the next action: the customer's own description, a useful reference if one exists, observable urgency, and a safe way to continue. Do not turn every incoming message into the same long form. A question about opening hours, an exchange request, and a possible account-security incident call for different paths. Intake should route a case with context and an accountable owner, not collect every piece of information a business might someday use.
Begin with an open question and a brief confirmation: “What would you like us to help resolve today?” Then ask only for the order, booking, or service reference needed to find the record on that channel. State what happens next and when the customer can expect an update. If the matter involves sensitive data, payment, account access, or immediate risk, move it to an approved secure process and an authorized person instead of requesting documents in an ordinary chat.
Define the minimum for each reason, not one universal form
Design intake around real contact reasons. A general question may need only its topic and a public answer. An order-status request may require an order reference. A quote request may need the product or service, location, desired timing, and a reply route. A complaint requires the original account of the event, the available reference, and the impact the customer describes, but the first message need not complete the investigation.
Separate required fields from details that become useful later. A required item should serve a clear purpose: finding a record, recognizing a safety risk, or enabling the next response. If nobody uses the answer to decide or act, reconsider asking for it. Brazil's LGPD Article 6 includes purpose and necessity among personal-data processing principles. It does not prescribe a universal customer-support form; each organization must justify the data it handles for its own purposes.
Use a contact-reason taxonomy with a small number of actionable categories. Do not make a customer choose between internal labels they cannot understand. Preserve the free-text request before classifying it, and allow the category to change as facts emerge. A classification correction should not make the customer start over.
Ask in stages and explain what comes next
A short sequence is often more useful than ten questions sent at once. Understand the request, find the minimum reference, confirm what has arrived, and name the next owner. If something is missing, ask one specific question and explain why the answer is needed. “Could you share the booking code from your confirmation so we can find it?” is clearer than “Send all your details.” Avoid asking again for information already available in the conversation history.
On a website form, label each input, mark required items, and explain the expected format. The W3C's form instructions guidance describes clear instructions associated with controls, including for assistive technology. In messaging channels, the same operational principle becomes simple questions, asked one at a time, with a confirmation of what the team already knows. A placeholder alone should not carry essential instructions.
Use an explicit waiting state when the next action belongs to the customer. The case still has an owner, but the team's promised update time and the time for another attempt are different commitments. If the customer does not answer, do not automatically call the underlying need resolved. Record what is missing, when the team will review the case, and how it will resume. The guide to promised customer updates separates team commitments from external dependencies.
Verify identity only when the action requires it
An informational question does not need the same check as changing a delivery address, accessing an account, or disclosing purchase details. Decide in advance which actions require identity verification and which approved channel can perform it. Do not request passwords, authentication codes, or full identity documents for convenience. When a specialist team owns a sensitive step, transfer the case without copying sensitive data into multiple channels.
A new conversation on another channel may concern the same case, but a similar name, profile picture, or phone number is not sufficient proof on its own. Before merging histories, follow the approved linking procedure and record the decision. The guide to identity across channels explains how to preserve context without a false merge. If the link remains uncertain, keep the records separate and ask for verification appropriate to the risk.
The Brazilian data-protection authority publishes security guidance for small data controllers. It is a starting point for proportionate access and protection, not a substitute for the organization's legal and security review. Review who can see each item, how long it is needed, and how the team corrects an inaccurate detail.
Hand over a case the next person can use
Intake helps only when the next person can act without repeating the interview. Pass on the customer's stated need, verified reference, channel, confirmed facts, outstanding information, priority, promised update, and the person who accepted responsibility. Distinguish the customer's account from the team's interpretation. If assignment fails, return the case to a visible queue instead of letting it disappear into an individual inbox.
Review a weekly sample: how many questions preceded the first useful action, how often did the customer repeat the same information, how many cases lacked an owner, and which fields were never used? Compare by reason and channel rather than relying on one overall average. Intake that is too short can cause repeated exchanges; intake that is too long can deter people with simple requests. Adjust the minimum set using real conversations and feedback from the team receiving the handoff.
- The customer can describe the need in their own words.
- Every requested item has a clear purpose and operational use.
- A reference is requested only when it enables location or the next action.
- Channel and risk determine whether identity must be checked.
- Required fields and expected formats are explained accessibly.
- The customer knows who owns the case, what is missing, and when to expect an update.
- The receiving team gets context and accepts responsibility.
- Unanswered cases and uncertain identity links stay visible for review.