Turn a bespoke training enquiry into a programme brief by separating the customer's stated goals, intended audience, delivery preferences, and practical constraints. Preserve what the customer actually said and label any interpretation as a proposal for staff review. The brief should help a programme designer ask better questions, not pretend the needs assessment is already complete.
Start with the enquiry forms, CRM templates, and document requests already available to the team. Content Snare describes reusable information collection and review features. A custom tool is useful when it assembles scattered context or exposes missing decisions that existing forms do not adequately support.
Separate the goal from the proposed format
Fictional Northbank Training receives an email: “We need a two-hour leadership workshop for twenty new team leaders before our November launch.” An attached note mentions inconsistent shift handovers and difficult conversations. The requested format is two hours; the stated business concerns are more specific.
| Brief section | Confirmed information | Question for staff review |
|---|---|---|
| Business concern | Shift handovers and conversations | Which situations matter most? |
| Audience | Twenty new team leaders | Shared experience level? |
| Requested format | Two-hour workshop | Is the duration fixed? |
| Timing | Before November launch | Which dates are feasible? |
| Success evidence | Not supplied | What change would be useful? |
The tool should not infer that a generic leadership course is the right solution. It can present the concern, format request, and missing information to the programme designer, who decides how to explore fit with the customer.
Keep facts and hypotheses distinct
Use labels such as customer-stated, confirmed by staff, proposed interpretation, and unresolved. A sentence like “Participants lack confidence” should not appear as fact unless supported by the enquiry. It may be a useful hypothesis, but it needs to remain visibly provisional.
Retain links to the email, note, or approved conversation summary behind each material point. If two sources disagree on audience size or timing, show the conflict. Do not silently combine them into a polished brief that hides uncertainty.
Capture constraints that affect design
Practical fields may include delivery location, remote or in-person preference, available time, participant count, required materials, and decision-maker contact. Ask only for information relevant to the next step. Avoid collecting sensitive participant details merely because a free-text form makes it easy.
Caiger's public event enquiry is one example of a business asking explicitly about dates, numbers, and logistics. For training, choose the fields with the programme team; an event form is a useful structural example, not proof that the same requirements apply to learning design.
Prepare targeted clarification questions
- What situations should participants handle differently afterward?
- Which audience groups or experience levels need to be considered?
- Which delivery constraints are fixed and which are preferences?
- Who will approve the proposed scope and schedule?
- What information is still needed before a designer can recommend an approach?
Questions should follow from the actual gaps in the brief. Do not send every question to every customer. Staff may already know an answer from an approved call note, or may decide that it is unnecessary before an initial discussion.
Keep budget information in its original form if the customer supplies it. A broad spending range is a constraint for staff discussion, not permission to infer a final programme price or commit to a delivery format.
Pilot against varied enquiries
Create fictional enquiries containing a clear objective, a vague request for “better communication,” conflicting audience counts, and a fixed format that may not fit the stated goals. Have an experienced programme designer prepare the expected brief and identify which interpretations must remain tentative.
Measure omitted facts, invented assumptions, useful questions, and staff editing time. Review the brief with the person who receives the handoff, not only the person who configured it. Clear Anvil's workflow planning can support this preparation process, while programme recommendations, learning design, and promises to the customer remain staff decisions.
Sources and further reading
AI-assisted research and writing, checked against the linked sources. Worked examples are fictional. Product features can change; confirm the details in your own account.