Purpose and fit

Use this when an AI-enabled change affects responsibilities, service expectations or day-to-day work across teams. The aim is to understand what people need to make the change workable, including concerns that may justify changing or stopping it. Avoid treating hesitation as a communication defect before checking whether people have identified a real operational problem.

Before you start

Use existing authorised consultation summaries and the actual change description. If consultation has not happened, supply the known affected groups and produce a question plan, not invented feedback. Remove identifying personal or confidential details.

If your available data uses different fields or terminology, adjust the prompt to match it. State the intended decision, audience and acceptance criteria; ask for essential missing information, and label any non-essential working assumptions. Do not fill factual gaps with invented information.

Required inputs

  • A plain-language description of the proposed change, its scope and unresolved decisions
  • A map of groups affected directly or through downstream work
  • Approved consultation routes, including a way to raise concerns privately
  • Existing evidence about workload, accessibility, decision rights and support arrangements

Practical workflow

  1. Map groups by how their work changes: people doing the task, reviewing results, receiving the service and supporting the systems. Include less visible shifts, temporary staff and downstream teams where relevant.
  2. For each group, record the proposed change, possible benefit, added responsibility and open question. Label these as assumptions until people confirm them. Do not infer attitudes from role, age or usage data.
  3. Ask a small set of neutral questions through approved channels: What becomes easier or harder? What could go wrong? What information or support is missing? What should remain under human control?
  4. Group concerns by issue rather than by named individual. Separate observed problems, stated preferences, unanswered questions and rumours. Preserve materially different views instead of reducing them to a single sentiment score.
  5. Assign a response to each consequential issue: investigate, change the design, provide support, explain a confirmed decision or refer it to an authorised specialist. Identify who owes an answer and by when.
  6. Return a clear summary to the affected groups through the agreed route. Check whether the proposed response addresses their concern and record unresolved disagreement for the accountable decision owner.

Expected output

Expect a draft concern map and follow-up questions with evidence labels, not a sentiment score, proof of consent or evidence that everyone has been consulted.

A concern map and response log, suitable for a cross-functional review:

Affected group | work change | concern in their words or approved summary | evidence status | consequence if unresolved | response needed | owner | due date | feedback/closure

Use four evidence labels: directly reported, observed, inferred and unknown. Avoid labels such as resistant or low commitment, which can obscure the substance of the concern.

For every unresolved issue, complete: “We heard [concern]. We know [evidence]. We still need [answer]. [Owner] will [approved next step]. The decision remains [open/confirmed with source].” Keep confidential employment or personal matters out of the shared map and route them appropriately.

Human checks

Representatives of affected groups confirm that summaries are fair and that minority views remain visible. The change owner checks power differences and whether people can disagree without retaliation. HR, accessibility, legal or worker representatives review issues within their remit. Obtain the necessary permission before recording, sharing identifiable feedback or putting it into an AI tool; use sanitised summaries where possible.

Limitations

A consultation map is not consent, agreement or proof that everyone has been heard. People may withhold concerns, and those who respond may not represent the whole group. The exercise cannot resolve employment obligations or substitute for required consultation. Maintain a route for concerns that emerge after implementation.

Starter prompt

Structure a stakeholder concern map for [proposed change] using only these approved, sanitised consultation notes: [notes]. The affected groups and decisions still open are [details]. Separate directly reported concerns from observations, assumptions and unanswered questions.

Group issues by their effect on the work and identify missing perspectives. Produce a log with affected group, work change, concern, evidence status, consequence if unresolved, response needed, owner, due date and feedback/closure. Add neutral follow-up questions. Leave owners, dates and commitments blank unless supplied. Do not assign psychological labels, infer support from silence, identify anonymous respondents or invent assurances about jobs, monitoring or future decisions.

Adapt the structure to the information I actually provide. First identify essential missing inputs and ask targeted questions. If a useful partial draft is possible, produce it with explicit unknowns and labelled assumptions. With sparse notes, retain the few reported concerns and mark missing perspectives unknown. Proposed concerns must remain inferred hypotheses until people confirm them.

Every directly reported concern must be grounded in supplied notes; inferred concerns must be labelled. Owners, commitments and dates stay unknown unless supplied, and silence cannot be classified as support.

Responsible use

Use relevant data that exists or that you provide, with accuracy and completeness sufficient for the task. Different AI models and versions may produce different results, and responses may vary between runs. You are responsible for checking and validating the output against your own requirements, source information and acceptance criteria before relying on it.