Frozen Verbal Brief: Freeze the Client's Words Before Team Notes
Freeze a verbal client brief before acting: verbatim quotes separated from team notes, conflicts recorded instead of decided.
TL;DR
Verbal requests were frozen as quoted input, not approved decisions, with team notes kept strictly separate. Each point was mapped to existing documents, revealing scope gaps and a direct conflict that was logged as an open question. Only ready work entered the backlog while blocked items waited for written client direction.
A verbal brief from the client arrived through the project owner: three core points regarding access restrictions and adding activity trails, plus one downstream effect on the public-facing view. Everyone agreed. Someone was already about to translate those points into work tickets so development could start the next morning.
The easiest initial guess is also the most dangerous: writing those verbal points into a working document and treating them as approved decisions. It sounds neat, fast, and saves a step. Instead of that, the conversation was frozen into a new intake document with an input status, marking that not a single point had been agreed upon yet.
What gets frozen is not a summary. The document's content is intentionally split into two parts. First, the client's words quoted verbatim, as they are, without translation into technical jargon. Second, a table titled “Team Notes”, which explicitly states in its title that its contents are not the client's words.
Mapping, Not Translating
That team notes table does not translate requests into tasks. It maps each verbal point against the existing chain of documents, then writes the result as it is: one point expands on a decision already made, one point falls outside the scope of the current specification, and one point targets a module that does not exist in the codebase yet.
One point turned out to clash directly with criteria that were previously accepted and signed off. The team did not pick a winner. The conflict was recorded as a conflict, naming both parties, and added to the list of questions the client must answer. At this stage, the correct decision is to refuse to decide.
The reasoning aligns with long-established practices. The CMU Software Engineering Institute notes that requirement inputs can arrive as verbal requests during user forums, and before entering a model, they need classification, deduplication, and reformulation [2]. RIT's elicitation documentation describes the process as recording a shared understanding, with one fitting suggestion for this case: encourage stories, avoid design [3].
The neatness of this document lies in one separation: the client's words and the team's words must not mix in the same block. Verbatim quotes preserve the original sound, including unclear sentences, because clarity is the result of the next phase of work. The team table holds a temporary reading, complete with its uncertainties.
That role difference often vanishes when a frozen verbal brief is summarized directly in a meeting. The most convincing summary usually belongs to the most confident person, not the one closest to the client's intent. NASA emphasizes that requirements should state what is needed, not how to provide it [1]. The same pattern applies to uncertainty: unset values should be written explicitly as open items, not patched with guesses that look plausible [1].
Two Tracks, One Status Marker
Once the mapping is complete, the work merges into two tracks. The first track is measurable and can be worked on from the backend first, so it goes straight into the board backlog. The second track is completely blocked while waiting for written direction from the client, especially for points that clash or are not yet tracked in any system.
The log line records what was made, when, and why, so the reason for the freeze does not evaporate along with the conversation. A good design process is indeed iterative and recursive until it produces a validated set of requirements [4]. That iteration can only run if its foundation does not shift because one person misremembered the meeting outcome.
Freezing a verbal brief into a distinct document has one effect that is not visible at first: points that are not ready clearly look unready. At least one item stops being forced into a work column, and the list of questions for the client grows as a written list, not as a conversation wandering in someone's head. Verbal summaries may live in chat; the actual brief lives in a document anyone can reopen.
Sources
[1] NASA Appendix C: How to Write a Good Requirement, accessed 10 October 2026.
[2] CMU SEI: Requirements in Model-Based Systems Engineering, accessed 10 October 2026.
[3] RIT SWEN-440: Requirements Elicitation lecture, accessed 10 October 2026.
[4] NASA Systems Engineering Handbook 4.0: System Design Processes, accessed 10 October 2026.