Research and Answer a Customer Question

Find the most reliable answer available, verify what supports it, and turn it into a response appropriate for the customer and communication channel.

Do not invent product behavior, policy, account treatment, commitments, pricing, roadmap details, or exceptions simply because the documentation is incomplete.

A confident-sounding answer is not a substitute for a verified one.

1. Clarify the actual customer question

Identify:

• precise question;
• customer or account;
• intended recipient;
• communication channel;
• relevant product area;
• deadline or urgency;
• decision or action the answer needs to support;
• account-specific context that may materially affect the answer.

Read the current conversation or ticket before researching.

Determine:

• what the customer already explained;
• what has already been answered;
• what they are actually asking now;
• what assumptions should not be repeated as questions.

Avoid making the customer restate information already available in the thread.

Identify specialist-review topics

Flag questions involving:

• product roadmap;
• unreleased features;
• pricing;
• discounts;
• contracts;
• legal terms;
• security;
• privacy;
• compliance;
• data handling;
• billing;
• refunds;
• credits;
• custom configurations;
• account exceptions;
• commitments outside standard policy.

Research may produce a likely answer, but these categories can still require approval from a named owner before the answer is sent.

2. Search authoritative sources first

Begin with the strongest current sources.

Prioritize:

1. approved product documentation;
2. current policies;
3. canonical help-center content;
4. known-issue records;
5. authoritative internal product or operational documentation.

Then use relevant contextual sources when permitted, including:

• support history;
• CRM or account notes;
• previous customer communication;
• meetings;
• internal team discussion;
• project records;
• product issue records;
• release information;
• official external documentation.

Prefer evidence that is both authoritative and current.

Preserve:

• source links;
• source owner where relevant;
• dates;
• product versions;
• plan or role scope;
• account scope;
• what each source actually establishes.

A historical support response may provide useful relationship context, but it does not automatically represent current product behavior or policy.

3. Separate general truth from account-specific context

Distinguish:

• general product behavior;
• current policy;
• account-specific configuration;
• negotiated or approved exception;
• historical treatment;
• customer statement;
• internal inference;
• unresolved unknown.

Do not generalize a one-off customer exception into standard policy.

Do not apply another customer's configuration, commercial terms, or treatment to the current account.

Protect private customer and account information throughout the research.

4. Resolve contradictions and evidence gaps

Do not stop at the first plausible answer.

Compare relevant sources.

When sources disagree, evaluate:

• authority;
• recency;
• product version;
• applicable plan;
• role or permission;
• account configuration;
• whether one source has been superseded;
• whether the disagreement reflects a genuine unresolved issue.

Explain which source should currently control and why when the evidence supports that conclusion.

Keep separate:

• verified facts;
• account history;
• interpretation;
• uncertainty;
• unknowns.

If no reliable source answers the question, state that clearly.

Identify the smallest useful verification step, such as:

• checking the current product;
• asking the product owner;
• confirming a policy;
• reviewing a specific document;
• obtaining specialist approval;
• verifying account configuration.

Do not turn:

• an internal roadmap note;
• informal chat;
• speculative engineering comment;
• historical promise;
• unsupported support response

into a customer commitment.

5. Verify current behavior when necessary

When the answer depends on current product behavior and authoritative documentation is incomplete or potentially stale, verify the behavior in an approved environment when possible.

Check relevant:

• UI labels;
• workflow;
• permissions;
• roles;
• plans;
• configuration;
• product version;
• platform differences;
• expected result;
• failure state.

Do not perform destructive, irreversible, account-changing, or customer-data actions merely to verify an answer unless explicitly authorized.

If direct verification is unavailable, say what source was used and what remains unverified.

6. Prepare the customer answer

When evidence supports a direct answer, lead with it.

Adapt:

• wording;
• technical depth;
• explanation;
• terminology;
• length

to the customer and communication channel.

Use the customer's terminology where doing so improves clarity, while retaining official terminology when necessary.

Include only context the customer needs.

When useful, link the relevant approved customer-facing documentation.

If the answer is not final, explain:

• what is known;
• what is being verified;
• the next step;
• timing only when an approved or supportable timing commitment exists.

Do not invent an ETA to make the response feel complete.

7. Deliver both customer-facing and internal context

Provide:

Answer

The best supported answer available.

Evidence

Include confidence-driving evidence and the authoritative basis for the answer.

Sources

Preserve relevant links, dates, versions, plans, roles, or configuration scope.

Caveats

Surface contradictions, limitations, uncertainty, and unresolved questions.

Customer-ready draft

Prepare a response suitable for the requested channel.

Internal notes

Keep review requirements, sensitive context, unresolved internal questions, escalation needs, and follow-up instructions separate from customer-facing copy.

Never leak internal-only material into the customer response.

8. Turn stable answers into reusable knowledge

When a verified answer addresses a recurring question or documentation gap, route it to the help-center article creation/update workflow.

Preserve:

• authoritative sources;
• verified terminology;
• customer search language;
• relevant scope;
• review requirements.

Do not include customer-specific private context in reusable documentation.

9. Keep drafting, sending, and account actions separate

Treat these as distinct actions:

• researching;
• drafting;
• obtaining specialist review;
• sending the answer;
• updating a support ticket;
• changing account settings;
• changing permissions;
• issuing a refund or credit;
• changing billing;
• making a product commitment;
• making a commercial exception.

Follow active scoped permission for the exact:

• customer;
• account;
• communication channel;
• destination;
• system;
• action.

Approval of the drafted answer does not automatically authorize account changes, refunds, commitments, or sending.

Verify completed changes where possible.

10. Preserve useful research behavior

After the team confirms the answer, preserve reusable elements when useful, such as:

• preferred authoritative sources;
• source hierarchy;
• terminology;
• response structure;
• review requirements;
• escalation conditions;
• verification rules;
• tone appropriate to the support environment.

Remove customer-specific facts, account data, private communication, and negotiated treatment before turning the method into reusable guidance.