Training requests often arrive as a course, workshop, or asset before anyone has named the real task, system condition, or evidence standard.
- A cleaner way to name the system problem before the team jumps to production.
- A one-page structure you can copy into a meeting note, document, spreadsheet, or tracker.
- A practical next action that can happen before a bigger playbook or template is needed.
- A requester asks for a course before naming the task.
- The team suspects the answer might be a job aid, workflow change, manager support, or tool fix.
- The request feels urgent, but the performance problem is still fuzzy.
Treat the requested training as an input, not the answer. The request is a clue about a larger system made of people, policies, tools, handoffs, incentives, information, and evidence.
Ask one question from each row before accepting the format. If the requester cannot answer, the next move is discovery, not production.
Use the rows as a thinking aid, not a compliance form.
Start with the lightest version that still changes the work.
Use the questions in a 15-minute requester conversation. Write the answers in plain language and end with a decision: build, redirect, inspect, pause, or gather examples.
Use Microsoft Forms, Google Forms, Word, Docs, Excel, Sheets, SharePoint Lists, or Microsoft Lists after the questions work in conversation. Do not turn bad questions into a formal form.
Use AI to turn rough request notes into likely problem patterns, missing information, non-training causes, and follow-up questions. Keep the human decision owner visible.
- Ask for the anti-request: what should we not build for this problem?
- Create a friction receipt. Send the requester a short note naming what is known, what is missing, and what decision cannot be made yet.
- Prototype the smallest non-course support first. A checklist, decision tree, manager prompt, or searchable article may teach more than a course request.
- Ask where the behavior already happens correctly. The best source material may be the team or region that already solved the problem.
Paste this into the tool next to the work.
Triage questions
# Training Request Triage Questions
Use before accepting the requested format.
1. What should someone be able to do that they cannot reliably do now?
2. Who needs help, and where are they in the workflow?
3. Where does the work fail today?
4. What do people do now when they get stuck?
5. What source material or example shows the correct work?
6. What would make us comfortable saying the support helped?
7. What is the smallest useful move before we build a course?
Decision:
- Build training
- Build a job aid
- Improve documentation
- Inspect the workflow
- Add manager support
- Route to a tool or platform owner
- Pause for discoveryUse AI to inspect the work, not replace the owner.
These prompts are strongest when you give the model approved source material and ask it to separate known facts, assumptions, missing information, risks, decisions needed, and next actions.
ChatGPT GPT-5 family
Use an outcome-first prompt with the job, approved source material, constraints, and the exact artifact you want back.
I am working on Turn a vague request into triage questions for an L&D system problem.
Goal: Help me turn the notes below into a practical next move.
Context: Use this when a training request arrives as a format before the team knows the task, break point, or evidence.
Use these working fields: requested asset, audience, task, break point, current workaround, evidence, smallest useful move.
Rules:
- Use only the source notes I provide.
- Do not invent policy details, metrics, learner needs, compliance requirements, or business context.
- Separate known facts, assumptions, missing information, and next actions.
- Flag anything that needs requester, reviewer, leader, legal, compliance, LMS owner, or manager confirmation.
- Keep the output practical enough to review in a working meeting.
Source notes:
[paste approved notes here]
Return:
1. Working diagnosis
2. Known facts
3. Assumptions
4. Missing information
5. Likely non-training causes
6. Questions for the requester
7. Recommended next actionClaude 4 family
Use XML-style sections so context, source material, task, constraints, and output format stay separate.
<context>
I am working on Turn a vague request into triage questions for an L&D system problem.
Use this when a training request arrives as a format before the team knows the task, break point, or evidence.
</context>
<source_notes>
[paste approved notes here]
</source_notes>
<task>
Turn the source notes into a practical next move using these working fields: requested asset, audience, task, break point, current workaround, evidence, smallest useful move.
</task>
<constraints>
Use only the source notes provided.
Do not invent policy details, metrics, learner needs, compliance requirements, or business context.
Separate known facts, assumptions, missing information, risks, and next actions.
Flag anything that changes scope, ownership, evidence, risk, or decision rights.
</constraints>
<output_format>
1. Working diagnosis
2. Known facts
3. Assumptions
4. Missing information
5. Likely non-training causes
6. Questions for the requester
7. Recommended next action
</output_format>Gemini 3 family
Use a clear task, labeled input, and one example pattern. For Obsidian context, use approved excerpts, Drive exports, Google Docs, or NotebookLM source sets.
Task: Help me make progress on Turn a vague request into triage questions from the notes provided.
Context: Use this when a training request arrives as a format before the team knows the task, break point, or evidence.
Working fields:
- requested asset
- audience
- task
- break point
- current workaround
- evidence
- smallest useful move
Example pattern:
Field: Missing information
Good answer: Name the specific information to confirm, who can confirm it, and why it affects the next decision.
Rules:
- Use only the source notes provided.
- If information is missing, write "Needs confirmation".
- Keep the output concise and reviewable.
- End with the next best action.
Source notes:
[paste approved notes here]
Output format:
1. Working diagnosis
2. Known facts
3. Assumptions
4. Missing information
5. Likely non-training causes
6. Questions for the requester
7. Recommended next actionMicrosoft 365 Copilot
Use goal, context, source, expectations, and output. For Obsidian context, use approved excerpts, Word summaries, OneDrive files, SharePoint pages, Teams context, or Outlook threads.
Goal: Help me make progress on Turn a vague request into triage questions.
Context: Use this when a training request arrives as a format before the team knows the task, break point, or evidence.
Source: Use the selected document, meeting notes, spreadsheet, email thread, SharePoint file, or pasted notes as the only source.
Expectations:
- Work with these fields: requested asset, audience, task, break point, current workaround, evidence, smallest useful move.
- Mark uncertain items as "Needs confirmation".
- Do not add facts that are not in the source.
- Separate known facts, assumptions, missing information, risks, and next actions.
- Summarize the top review questions for the team.
Output:
1. Working diagnosis
2. Known facts
3. Assumptions
4. Missing information
5. Likely non-training causes
6. Questions for the requester
7. Recommended next actionThe research move is practical, not academic.
Systems thinking helps people identify problems, patterns over time, operating levers, boundaries, and feedback loops.
Performance support can be a better fit than training when people need help at the moment of work, when information changes, or when training is too heavy.
Performance improvement starts with the outcome that matters, not with training as the default intervention.
Use the six triage questions on one live request before you accept the requested format.