A discovery summary should record what was understood, what was decided and what still needs confirmation. Attribute reported information, keep proposed work separate from agreed actions and name owners and dates. Invite corrections explicitly, and do not treat the absence of a reply as acceptance of a commercial agreement.
Summarize decisions rather than transcribing everything
The useful record of a discovery conversation is rarely a complete transcript. Organize it around the project problem, relevant constraints, decisions made and remaining questions. Preserve detail when it changes scope or interpretation. Exclude conversational material that does not support the next decision, especially personal information or confidential examples that participants did not expect to circulate beyond the discussion.
Write the problem statement in language the client can recognize. If the discussion changed your initial understanding, state the revised account rather than quietly editing the history. Attribute claims that remain unverified: the operations team reported repeated checking, for example. A reported experience matters, but your summary should not turn it into a measured finding or an independent assessment of the organization.
Add a brief status line near the top: discussion summary for factual confirmation, proposal preparation notes or another accurate label. This prevents an orderly document from looking more authoritative than its underlying agreement. Keep any offer, contract or quotation clearly identified in the appropriate separate document. A meeting summary can support those later artifacts without substituting for them.
Use explicit labels for the state of each item
Distinguish decisions, suggestions, assumptions and open questions. “Review a sample guide” may be an agreed action; “rewrite all guides” may only have been discussed as an option. Name the difference. For each action, include the person responsible and a date they actually accepted. If a date was suggested but not agreed, mark it as proposed rather than presenting it as a commitment.
Record important exclusions and dependencies as well as positive intentions. A content proposal may depend on access to an approved sample or confirmation from a technical owner. An uncertain dependency belongs in the summary even when it makes the next step less convenient. Include conflicting accounts where they affect the work and name how they will be resolved. Do not smooth away disagreement to make the document look complete.
Make correction easy and keep a revision trail
Send the summary to the appropriate participants through a suitable channel and explain which facts require confirmation. A focused request such as “please confirm the publication owner and the sample deadline” is easier to act on than asking everyone to approve everything. Allow written corrections, and choose a response window consistent with time zones, working arrangements and the importance of the decisions involved.
When corrections arrive, issue a dated revision or record the changes clearly. If nobody replies, follow the communication process you actually agreed; do not invent acceptance through silence. Carry unresolved items into the proposal as conditions or questions. Keep the summary available to the people who need it, while avoiding unnecessary distribution of commercial details or personal information captured during the conversation.
Fictional example: correcting an approval assumption
A fictional service designer sends a summary after discussing a volunteer portal. It says that the programme coordinator will approve all public content. The coordinator replies that she can confirm operational accuracy but that publication requires the communications lead. The designer updates the decision map and changes the proposed review sequence before preparing an estimate.
The revised summary labels the portal redesign as an option discussed, records a sample review as the agreed next action and leaves the implementation schedule open. Its change note identifies the corrected approval responsibility without retaining unrelated conversational detail. This example demonstrates why factual confirmation matters: the document now supports a more accurate proposal. It does not imply that the fictional organization commissioned work or that the absence of any other correction created an agreement.
A checklist for your next step
- Label the summary’s status.
- Separate decisions from suggestions.
- Attribute unverified reports.
- Request specific corrections.
- Carry unresolved items forward.
Common questions
Can a summary include an estimated schedule?
Yes, with a clear provisional label and its dependencies. Do not present an unaccepted estimate as a committed delivery date.
Should I include every participant’s comment?
Include comments needed to understand decisions, uncertainty or disagreement. A concise decision record is usually more useful than a complete conversational history.
Further reading
These primary resources provide related background. They do not validate the illustrative example or endorse AliveProfile.
AI-assisted drafting and automated technical checks. Examples are illustrative; no independent expert review or real-world outcome validation is claimed. Read our editorial policy.