A brief that identifies the record, the doubt and the next decision

A useful brief can be short if it describes the operating problem precisely. Write the current task, the people involved and the evidence they cannot establish. Avoid committing to a technical solution before the dependencies are understood.

Describe one sequence

For a fictional quote workflow, identify the initial request, two offer versions and the customer's decision. Explain which version staff use today and why that creates doubt. State the desired result as a check: an authorised colleague can identify the accepted version and prepare the permitted next step.

List the known boundaries

Name current applications and business-owned accounts. Identify available source code or exports without including credentials. List required language journeys and the people who can approve them. Mark provider access, professional questions and content preparation as dependencies where their answers are still unknown.

Define the first phase

Separate assessment findings from implementation deliverables. Include one normal acceptance case and one meaningful exception. State timing drivers, migration needs and who will operate the result. Budget discussion is more useful when it relates to those responsibilities than to an unexplained list of features.

Keep the first exchange proportionate

Use fictional names and references. Leave private records, account numbers and confidential attachments out of an ordinary message. Detailed access can be arranged later for an agreed purpose. Bring the brief to contact, and use deeper project questions if the first example reveals an unresolved authority or record relationship.