Delivery and analysis are usually treated as two jobs: run the sessions, then work out what was said. In practice they are one job. The way activities are run decides what evidence exists, and the way that evidence is recorded decides what analysis can honestly claim. Most of the problems that surface in the report-back were set up weeks earlier, in a workshop with no note-taker or a survey whose responses never joined the rest of the record.
This guide covers the delivery and analysis stage of the engagement lifecycle: running activities so they produce usable evidence, keeping one record across channels, tracking coverage, avoiding engagement theatre, coding feedback defensibly and keeping the thread from submission to decision while it can still be kept. It draws on the delivery posts in our practice blog and links to them where they go deeper.
How do you run engagement activities so they produce usable evidence?
Decide before each activity what record it will leave behind, who will capture it and in what form. Photographed sticky notes can preserve evidence, but only if you keep the question asked, the activity context and enough detail to interpret them. The test is simple: could someone who was not in the room later find what was said, by whom (or by which group), and in response to which question?
That test pushes a few habits into delivery. Ask questions that map to the decisions actually open for input, so responses can be connected to something. Assign a recorder for every live session and agree a capture format in advance. Note context that the words alone will not carry, such as which option was on the table when a comment was made. And log each activity as it finishes rather than at the end of the program, when memory has already started to smooth things over.
Evidence starts in the plan
If the plan never named the decisions open to influence, delivery has nothing to anchor responses to. The planning guide covers setting that up before the first activity runs.
How do you record input from every channel in one record?
Bring every input into a single project record as it arrives, with its channel, date and source attached, so nothing is analyzed in a silo. Engagement rarely runs through one channel. Comments come in through online engagement tools, survey forms, drop-in sessions, workshops, formal written submissions, emails, phone calls and conversations at a market stall. Each tends to land somewhere different: a survey export, a facilitator's notes, an inbox, a scanned letter in a shared drive.
When those sources stay separate, analysis quietly favors whichever is easiest to work with, usually the online survey. The detailed written submission from a residents' group and the comment captured at a pop-up stall get read later, or summarized loosely, or not at all. One record does not mean one format. It means every input has a home, a stable reference and enough metadata to be counted, coded and traced later.
- Source and channel: where it came from and how it arrived.
- Date and activity: which session, survey or submission period it belongs to.
- Participant or group: at whatever level of detail your privacy commitments allow.
- The original text or note: kept intact, so later summaries can be checked against it.
How do you know whether you reached the people you set out to reach?
Compare who actually took part against the stakeholder groups your plan said you needed to hear from, and do it during delivery while there is still time to close gaps. Participation counts on their own say little. A thousand responses can still miss the renters, the young people or the businesses most affected by a decision.
Coverage tracking turns the stakeholder map into a working checklist. After each activity, update which groups have been reached and through which channels. Where a group is thin or absent, change tactics: a different venue, a trusted intermediary, a format that suits them. The silence of a group is often the most important finding in a consultation, and it is invisible in the response data by definition, so it has to be tracked against the plan rather than discovered in the analysis.
Before moving to decisions, check the coverage record once more and document why any group remains under-represented. That note belongs in the report-back too.
What is engagement theatre, and how do you spot it during delivery?
Engagement theatre is a process that has the form of engagement without the substance: it collects input and hosts conversations, but that input has little real influence on the decision it implies it will shape. It is rarely deliberate. As we set out in engagement theatre warning signs, it usually comes from well-intentioned people making reasonable decisions in the wrong order.
During delivery, the warning signs are recognizable. A preferred option has already been committed to informally. Nobody can describe how input will reach the people with decision-making authority. The engagement level promised more openness than the project can honor. There is no plan for telling participants what happened. Genuine consultation within real, disclosed limits is not theatre. Theatre is the gap between the implied promise and the actual influence.
Undisclosed constraints are one of the ways that gap opens. As the smallest undisclosed constraint describes, communities can accept a fixed site, budget or legal requirement. What they cannot accept is discovering it after several sessions that implied it was open. The anger is out of proportion to the constraint because it is really about the process.
If you see it mid-process
There are two honest options: reset the conversation with communities about what is genuinely open, or escalate internally that the process is misrepresenting what is on offer. Carrying on as designed is not one of them.
What is the difference between reading and coding engagement feedback?
Reading establishes what each response says; coding applies a stated set of categories consistently across all of them so patterns can be counted, compared and defended. Between a submission arriving and a finding appearing in a report, four things happen: someone reads it, interprets it, codes it and analyzes the result. Collapsing those steps into the single word analysis is where the trouble starts, as we explain in reading is not coding.
An experienced practitioner reading five hundred responses is doing far more than reading. They are working out what each response implies, holding the project history alongside it, noticing ambiguity rather than resolving it too early, deciding whether a comment is a new idea or another instance of an existing one, and staying consistent with a call they made hundreds of responses earlier. Those are analytical decisions. Coding is where they get written down.
Where engagement analysis uses a structured codebook, the test of the coding framework is whether another competent analyst, working separately, would code the same material in roughly the same way. If not, the findings are more fragile than the report suggests. Other qualitative approaches, such as reflexive thematic analysis, judge quality differently.
How do you build and govern a coding framework?
Start from the decisions and objectives the engagement was designed to inform, let the material refine the categories, and keep a written record of what each code means and why it changed. A coding framework encodes a point of view. Is a comment about construction noise about amenity, about trust in the delivery agency or about a project that went badly years ago? Two analysts can answer differently and both be defensible. A frame nobody can articulate is not.
- Draft the frame from the decisions open for input and the questions asked, before reading everything.
- Test it on a sample of responses from different channels and groups, and note where it strains.
- Define each code in a sentence or two, with an example of what belongs and what does not.
- Refine as the material pushes back, and log each change with the reason and the date. When a code definition changes, review and recode the earlier material it affects.
- Check consistency by having a second person code a sample and comparing results.
Governance means someone owns the frame. They decide when a category has stopped fitting, approve changes and can explain the structure to a decision maker or a community member who challenges it.
How do you weigh and interpret themes before they are reported?
Treat every theme as a claim that must point back to the specific comments behind it, then weigh it with judgment rather than by counting alone. Volume is not significance. A small number of well-informed submissions from people directly affected can matter more than a large number of brief, similar comments, and a campaign can generate many near-identical responses. Identify the shared campaign wording while keeping the response count, the number of distinct contributors where known, and any individual arguments.
Interpretation is also where context matters most. A cluster of angry comments about parking might point to a design problem, a communications failure or leftover distrust from an earlier project. The data alone will not say which. Before anything is reported, a named practitioner should review each theme against its source comments, confirm the interpretation and sign it off. A synthesis nobody can retrace is not evidence; it is an assertion with a chart attached.
- Traceable: every theme links to the comments that support it.
- Weighed: volume, who said it and how directly they are affected are all considered and noted.
- Interpreted: the reading of ambiguous themes is written down, not left implicit.
- Signed off: a named person stands behind each finding before it leaves the team.
Why does the thread from submission to decision have to be kept as you go?
Because the connection between what people said and what was decided is clearest at the moment of decision, and it fades fast once the project moves on. Analysis tells you what communities said. Only a running record tells you how what they said changed what was decided. As we describe in the thread you can't reconstruct, teams that try to rebuild the link months later from session notes can find themes, but not the specific input behind specific decisions.
The fix is a discipline rather than a system. Keep a decision log alongside the engagement. After each activity, add the emerging themes and the decisions they bear on. When a decision is made, record the input that informed it, the outcome and the person accountable for considering it. Before implementation, review the log against the stakeholder map and note any group whose input appears nowhere.
This is what makes the report-back possible. A general summary that could have been written before the decisions were made tells experienced participants their input was not tracked, and over time that is how community trust slowly erodes. The closing the loop guide picks up from here.
Where does AI help in community engagement analysis, and where does judgment stay human?
AI helps most with volume and consistency; people stay responsible for the framework, the interpretation and the conclusions. A model can hold thousands of responses at once, group comments by meaning, notice that hundreds of people are circling the same concern in different words and propose codes at scale. Analysts should check those codes for accuracy and consistency against the agreed framework. It can also tag themes against decisions as delivery runs and surface where traceability is starting to break.
What does not transfer is designing and governing the frame, weighing a few informed voices against many brief ones, noticing which silence matters and being accountable when a finding is challenged. The risk is a model asked to find the themes that designs the framework invisibly, with nobody on the record for its assumptions. The AI in community engagement guide covers this in more depth.
How CE Canvas supports delivery and analysis
CE Canvas keeps evidence from every channel in one project record, so survey responses, submissions, meeting notes and conversations sit alongside each other with their sources attached. The CE Canvas AI assistant clusters responses into topics, and each topic stays linked to the comments behind it. Nothing is reported until a practitioner has reviewed it.
The same record tracks coverage, comparing the participants you intended to reach with those you actually heard from, and holds the project's tasks and delivery timeline, so the work and the evidence stay together. You can see the flow on how it works. If you want an outside view of how your current delivery and analysis workflow handles this, an Engagement Workflow Review looks at where evidence is lost between channels, analysis and decisions.
Last reviewed October 19, 2026 by the CE Canvas practice team.