Group AI support requests without rating the people
Several teams have asked for AI help. A useful support plan starts with what they couldn't do, rather than a league table of confidence.
What you'll make
a support list that links each proposed intervention to a stated task obstacle.
What you'll need
ChatGPT in your work account and a few team-level requests about tasks. Allow 15 minutes. Exclude private chats, personal assessments and employment matters; this is support planning, not an assessment of staff.
Example result — illustrative support list:
| Request | Support to consider |
|---|---|
| Route notes aren’t accessible | Resolve the source-access issue |
| Draft dates need checking | Demonstrate the source-to-date check |
| A reusable format is needed | Agree a short update template |
1. Gather descriptions of the work
Open Chat › New chat in ChatGPT. Give each request a short reference so you can trace the summary. Keep the wording of the obstacle.
Group these requests by the practical support they need. For each group show the request references, the stated obstacle and one possible response. Do not infer confidence, competence or willingness. Do not rank people or teams.
R1: We cannot open the current visitor-route notes in the tool.
R2: We need a reliable way to check whether the AI copied exhibition dates correctly.
R3: We want the monthly update to use the same headings each time.
R4: We also cannot open the visitor-route notes.Why this works: the references make grouping checkable, while the instruction keeps the analysis about task needs.
What you should see: an access group containing R1 and R4, plus separate checking and format requests.
2. Check the grouping before planning support
Read the requests in each group. Check whether they describe the same obstacle. Similar wording doesn’t make access, training and lack of a source the same problem.
Why this works: a general training session won’t repair a missing source connection.
What you should see: groups narrow enough to support different practical responses.
3. Turn the groups into a next-action list
For each checked group, write one next action and a question to confirm that the action addresses the request. Keep owners unassigned unless the requests name them. Do not claim the action will improve adoption or save time.Why this works: the confirmation question links the proposed support back to what the requestor needed.
What you should see: an access check, a demonstration of date checking and agreement on an update format.
Check the result
- Can you trace every group to its request references?
- Are access and checking treated as different needs?
- Does the output avoid personal labels and invented owners?
The usual failure: the summary calls the access group “low AI confidence”.
Replace "low AI confidence" with the recorded obstacle: inability to open the visitor-route notes. Keep R1 and R4 in that access group. Remove personal judgements and propose a source-access check rather than confidence training.Worked example
Fictional example.
R1: cannot reach the work account.
R2: needs help comparing an event date with its source.
R3: needs a decision on the recurring update format.
R4: cannot open the source folder.A heritage centre receives four requests: two about access, one about checking dates and one about a recurring format. A weak summary assigns confidence levels and recommends the same training for all four.
The repaired list preserves three different needs. Access support answers R1 and R4; date checking answers R2; a format decision answers R3. The original requests remain visible beside the proposed actions.
Go deeper
Check whether support answered the request
After trying the action, ask the team whether it removed the named obstacle. Keep that response beside the original request. Attendance at a session tells you who attended; it doesn’t tell you whether the work became possible.