Community-led monitoring in South Africa: feedback to evidence

What is community-led monitoring?

Community-led monitoring (CLM) is a recurring cycle in which the people affected by a service monitor it themselves, analyse what they find and use that evidence to press for change. It is not a once-off survey or a suggestion box: the same community comes back to the same questions, round after round.

UNAIDS describes it as a cyclical process in which people affected by health inequities "systematically monitor services, analyse the data they collect, and conduct evidence-driven advocacy to improve service delivery" (UNAIDS, Community-led monitoring in action, 2023). ITPC, which runs a CLM knowledge hub, describes a process where communities take the lead in routinely monitoring an issue that matters to them.

The definitions come from health, but the pattern applies to any public service. A practical cycle runs like this:

1. Define the issue and what decision the evidence should inform.
2. Collect evidence from service users and observation.
3. Analyse patterns across places and over time.
4. Validate findings with the community.
5. Take the evidence to the people responsible.
6. Track what they do about it.
7. Report back, then monitor again.

The community shapes what is monitored and how findings are read. The evidence still needs structure, review and a record of where each claim came from. That is the same discipline we describe for analysing public submissions, applied to a process that never really ends.

How is community-led monitoring different from M&E and public consultation?

Traditional monitoring and evaluation tracks a programme against its own indicators, public consultation gathers input at a decision point, and community-led monitoring tracks lived experience of a service over time. The three overlap, and a good evidence system can serve all of them.

Formal M&E can carry community evidence as one stream among several. If your team already runs a reporting cycle, the M&E reporting workflow shows where a coded feedback stream fits alongside indicator data.

The question is not which method is better. It is whether feedback becomes evidence that someone reviews, acts on and tracks.

What does South African law say about public participation in local government?

The Local Government: Municipal Systems Act 32 of 2000 requires municipalities to build a culture of participatory governance and to set up the mechanisms that make it work, including report-back. The legal basis exists; the gap is usually the system that handles what participation produces.

Section 16 requires a municipality to encourage, and create conditions for, the local community to participate in its affairs. That includes the integrated development plan, the performance management system, the monitoring and review of the municipality's performance, the budget and strategic decisions about municipal services.

Section 17(2) requires mechanisms, processes and procedures for:

• receiving, processing and considering petitions and complaints;
• notification and public comment procedures;
• public meetings and hearings;
• consultative sessions with locally recognised community organisations and, where appropriate, traditional authorities;
• report-back to the local community.

Section 17(3) adds that these mechanisms must take into account the special needs of people who cannot read or write, people with disabilities, women and other disadvantaged groups.

Read together, these sections describe a feedback loop: receive, consider, respond and report back. Meetings happen and submissions arrive. What often goes missing is a record that shows what was received, how it was considered and what was reported back.

What does the White Paper on Local Government process show about feedback loops?

The review of the White Paper on Local Government is a public participation process, not community-led monitoring, but it shows the same problem: public input that is not coded, reviewed and linked to decisions becomes noise. It also shows that participation can continue past drafting into implementation.

The public record, checked on 12 October 2026:

• Minister of Cooperative Governance and Traditional Affairs Velenkosini Hlabisa gazetted the Reviewed Draft White Paper on Local Government for public comment in May 2026, inviting comment from the public, civil society, organised local government, state institutions, traditional leadership, business and labour. The closing date was 28 May 2026 (SAnews, 9 May 2026).
• At its meeting of 23 September 2026, Cabinet approved the Revised White Paper on Local Government, 2026, and endorsed a time-bound Transition Management Body with a phased implementation programme led jointly by the Department of Cooperative Governance, The Presidency and National Treasury (Cabinet statement, 29 September 2026).

A process like this takes public input at more than one stage. A first round tells drafters what people see as wrong or missing. A second round, on the published draft, tests whether the draft understood the problem. Each round needs its own coded record, and the second needs to connect back to the first.

In our work on the White Paper on Local Government submissions, each submission was broken into claims, coded to shared themes and recorded with its quote and location, and consultation comments were coded into their own database so they stayed connected to the evidence. Policy decisions stayed with the drafting team and the department.

Once a policy moves into implementation, the useful question changes from "what should the policy say?" to "is it working where people live?" That is where public participation becomes implementation monitoring, and where community-led methods become relevant.

What South African examples of community-led monitoring exist?

South Africa has well-documented community monitoring in health, social services and sanitation. Each example below combines community ownership with a disciplined way of collecting and presenting evidence.

Ritshidze

Ritshidze is a community-led monitoring system for HIV services, implemented by the Treatment Action Campaign. Its national report of December 2025 covers data collected in October and November 2025 at 360 public health facilities in 19 districts across seven provinces, using patient, facility manager and observation surveys. The report explains that monitoring had run in 26 districts since inception and continued in 19 after PEPFAR funding cuts (Ritshidze, National State of Health, December 2025). Ritshidze publishes its data collection tools and a data dashboard on its website.

What makes it useful as a model is not only scale. The same questions are asked in repeated rounds, results are broken down by district and facility, and reports name specific problems that officials can be asked to fix.

Black Sash

Black Sash runs a Community Based Monitoring programme for public services. It describes the model as recognising communities, citizens and public service users as active holders of rights, gathering and analysing information from the service user's point of view, and taking that evidence back to government and, where necessary, into the public domain (Black Sash, Learn about CBM). It describes its data gathering as annual, over a three-month period.

Social Justice Coalition

From 22 to 26 April 2013, the Social Justice Coalition and Khayelitsha residents ran a social audit of the chemical toilets provided under a City of Cape Town contract in four informal settlements. Participants analysed the service agreement, interviewed residents and physically inspected the toilets, then presented the evidence at a public hearing on 27 April 2013 to which officials and the contractor were invited (Social Justice Coalition, Report of the Khayelitsha 'Mshengu' Toilet Social Audit, 2013). The example is dated, but the method still holds: compare what the contract promises with what residents experience, and put the evidence in front of the people responsible.

How do you design a community-led monitoring workflow?

Design the evidence workflow before the form, survey or dashboard. Decide what you are monitoring, who sets the questions, which fields every record needs and how a record moves from submission to report-back.

1. Define the issue and the decision. Name what is being monitored, such as clinic access, grant office service, ward infrastructure or a policy implementation commitment, and what the evidence is for: drafting, advocacy, resource allocation or service fixes.
2. Co-design the questions. Ask the community what it experiences, what the policy or programme promises, what would count as progress, what should be escalated and what can be fixed locally. Without this step, the system measures what institutions want to report.
3. Build the data structure before the form. Agree the fields, categories, required fields, privacy rules, reviewer roles and outputs first. A form builder comes last.
4. Collect mixed evidence. Surveys, structured forms, interviews, public comments, meeting notes, observation checklists, complaint logs and service records can all feed one structure. Photos only where it is ethical and consented.
5. Code and review. Tag each record by place, theme, service issue, severity, source type and response status, so repeated issues and differences between places become visible.
6. Take findings to decision-makers. Issue matrices, response tables, briefing notes and escalation logs work better than a dashboard alone, because each line names an owner.
7. Track action and report back. Record what was heard, what was accepted, what changed, what needs investigation and what falls outside the mandate, then tell the community.

Step 7 is where most processes stop. Report-back is the part people remember, and the part that decides whether they take part next time. It also needs someone to keep the record current between rounds. Some teams do that in-house; others use a managed data service with a named reviewer who is answerable for what the record says.

What should a community feedback evidence matrix include?

A feedback evidence matrix gives every submission one row and the same fields, from intake to report-back. It lets anyone trace a finding back to the original comment and see how it was coded and answered.

Keep the original text unedited and separate from the code. The code is your interpretation; the original is the evidence. If the two are merged, nobody can later check whether the coding was fair.

How should you handle narrow, duplicated or conflicting comments?

Preserve every comment, code the issue rather than only the sentiment, and record why each one was accepted, deferred or not taken forward. Public input is not a vote and is not automatically representative, but that does not make it disposable.

Expect duplicate campaigns, narrow self-interest, misinformation, contradictory views, demands outside the mandate, local issues framed as national ones, and serious concerns raised by only a few people from groups that are rarely heard. A fair review process:

• keeps the original source intact;
• separates lived experience from policy preference;
• tags whether a comment is individual, organisational, technical or institutional;
• counts frequency without treating it as the only measure of importance;
• flags evidence gaps in a reviewer note;
• keeps low-volume concerns visible;
• distinguishes "needs a response" from "needs adoption".

Response categories make those decisions visible:

Accepted                      - leads to a clear change
Partially accepted            - part of the comment is taken forward
Already addressed             - covered in the current draft, plan or policy
Requires implementation action - not a drafting issue; needs follow-up in delivery
Requires further evidence     - important, but needs more information
Outside current scope         - real, but outside this mandate
Not adopted, with reason      - reviewed and not taken forward, reason recorded
Duplicate or merged           - repeats another coded comment

For a formal consultation, these categories become the backbone of the published response. Our guide to what a public consultation response matrix should include covers that document in detail.

Where does AI fit in community feedback analysis?

AI can help group comments, suggest themes and draft first-pass summaries. It should never decide what a comment means or how it is answered. People review its output against the original text, using the same coding rules as for manual work.

In practice that means every AI-suggested code points back to the original comment, a reviewer confirms or corrects it, and the reviewer's decision is what goes into the record.

Common mistakes

• Treating consultation as a once-off event. Accountability depends on what happens after the meeting or comment period closes.
• Collecting comments without a coding structure. Without codes for theme, place and issue, comments cannot be reviewed fairly or compared across rounds.
• Publishing a dashboard without a response process. A dashboard shows problems; someone still has to review, assign, respond and track.
• Treating every comment as representative. One comment does not speak for a whole community. Source type, evidence quality and context matter.
• Dropping low-volume concerns. A few comments can point to a serious problem, especially for marginalised groups.
• Editing the original comment into the code. Keep the words as submitted and the interpretation in separate fields.
• Letting feedback lapse once the policy is adopted. Input used only during drafting misses the chance to monitor implementation.
• Skipping report-back. Report-back is part of the accountability loop, and it is what the Municipal Systems Act asks municipalities to provide for.