A good customer briefing is not a checklist you tick off. It is the conversation in which you find out what problem the customer actually wants to solve.
Start with the problem, not the solution
Customers often ask for a feature ("a member portal") when they actually have a problem ("members find it hard to pause their subscription"). Probe the current situation: how does the customer solve it today, who does that work, and what does it cost in time or money?
Ask about people, not screens
Who uses the system? Are there roles with different permissions? Who approves something? Who must see nothing? Roles and permissions are almost always where scope is misjudged.
Make explicit what is not needed
An out-of-scope register matters as much as the wish list. Without it, a project grows silently. Record what is deliberately excluded and why.
Separate facts from assumptions
Not every answer is a confirmed wish. Sometimes a developer infers something from context, sometimes the customer contradicts themselves. Record that status instead of averaging it out. Brieflo uses the statuses confirmed, inferred, ambiguous, contradictory and not discussed.
Ask about success, not hours
"When would you consider this a success?" produces usable acceptance criteria. "How many hours do you think it takes?" produces a negotiation you will regret later.
Record the conversation itself
Keep the original conversation as the source. A summary is useful but must never be the only place a requirement exists. Every requirement should be traceable to a message, a file or an explicit approval.