Feedback and complaints mechanisms

Three flows, three pipes

The single word “feedback” hides three flows with different stakes, and the foundational design error is forcing them through one pipe [1][3]:

• Feedback — observations, suggestions, questions, thanks. It needs acknowledgement and aggregation more than individual redress: its value is mostly in the pattern.
• Complaints — a claim that something owed was not delivered, or was delivered wrongly: exclusion from a distribution list, a damaged item, disrespectful treatment. A complaint creates an obligation to the individual: investigation, a decision, and a response to the person who complained.
• Sensitive complaints — reports of sexual exploitation and abuse, safeguarding violations, fraud or corruption. These carry risk to the reporter and others, engage dedicated protocols and specialist staff, and must be separated from routine flows at the very first moment of intake — not after triage by whoever opens the inbox [3].

The Core Humanitarian Standard makes the entitlement explicit: people affected by crisis should be able to safely report concerns and complaints and get them addressed, and should experience programmes that adapt in response to feedback [2]. The IASC commitments add the system-wide floor for SEA reporting channels [3].

Channels: community-preferred beats organisation-preferred

ALNAP and CDA’s field research on feedback mechanisms reached a finding that has held up ever since: mechanisms succeed when they are built around how the affected community already communicates and whom it trusts, and fail when the organisation installs the channel it finds administratively convenient [1]. A hotline serves the phone-owning and the confident; a suggestion box serves the literate and those who can approach the office unobserved; a community meeting serves those whose voices carry in public. None is wrong — the point is that every channel excludes someone, so a working mechanism runs several channels chosen with the community, and checks who is not appearing in the stream: women, older people, people with disabilities, minority-language speakers, children [1][2].

Design questions worth answering in writing: Which channels did the community actually ask for? Can each channel be used privately? In which languages? What does it cost the user (fare, airtime, a day’s queue)? And who staffs it — because a complaint about a staff member cannot be receivable only by that staff member’s team.

The loop, operationally

“Closing the loop” is the defining test of an FCM: the person who gave feedback learns what happened because of it [1]. Operationally the loop is a sequence of named steps, each with an owner and a clock:

acknowledge → categorise → route → resolve → respond to the person → aggregate → adapt the programme

The step where mechanisms die is respond to the person. Acknowledgement is easy to automate; aggregation flatters dashboards; but returning to the individual with “here is what we found and what we did” is unglamorous work that belongs to programme managers, not MEAL — and where it is skipped, communities notice and the channel goes quiet. Silence in a feedback channel is far more often a verdict on the mechanism than evidence of satisfaction [1].

Two ownership rules keep the loop honest: every category of item has a named resolver outside the team being complained about, and MEAL owns the pipework (logging, routing, clocks, aggregation) while operations own the answers.

Sensitive complaints

Reports of sexual exploitation and abuse, other safeguarding violations, and fraud follow different physics [3]:

• Separation at intake. Every channel — hotline operator, help-desk clerk, box-opener — has an unambiguous instruction for the moment a sensitive report appears: no local investigation, no wide logging; direct, immediate transfer to the designated focal point through the confidential pathway.
• Confidentiality by architecture. Sensitive cases live in restricted-access records with minimal identifying detail, not in the general feedback log. The data-protection duties that apply to any identifying records are covered under data protection.
• Survivor-centred handling. The reporter’s safety, wishes and access to support services lead the process; referral pathways to medical, psychosocial and protection services are mapped before the mechanism launches, not after the first report [3].
• Separate statistics. Sensitive cases are counted and overseen separately, at senior level. Publishing them inside routine feedback dashboards both breaches confidentiality and buries a governance signal in operational noise.

Designing the intake and routing is MEAL work; investigation is specialist work under dedicated protocols. The mechanism’s job is to make sure a report reaches the right hands fast, and provably.

Feedback as monitoring data

An FCM is also a sensor. Categorised and trended, the stream tells a programme things its indicators cannot: which sites generate exclusion complaints, which activity’s quality slid this quarter, what rumour is circulating ahead of registration. Making the sensor work takes three habits [1][4]:

• A governed taxonomy — a small, stable category set (entitlement/exclusion, quality, conduct, information request, suggestion, thanks) with definitions, so trends survive staff turnover; the same definitional discipline as any indicator (see data quality dimensions).
• A standing agenda slot — feedback trends tabled in the same programme meetings that review indicator results, with decisions minuted; the connection to adaptive management is covered under learning and adaptive management.
• Honest interpretation — the stream over-represents those with access and confidence, and under-represents the most excluded; read it as a biased but fast signal, triangulated against monitoring and perception data, never as a prevalence estimate [1].

Metrics — and how each one is gamed

Metrics of a working feedback and complaints mechanism, with gaming risks

Metric	What it shows	How it gets gamed	Honesty check
Awareness rate	Share of community who know how to complain	Measured only at distribution points, among those already reached	Ask in household perception surveys, disaggregated
Use volume	Whether channels are trusted enough to be used	Read as satisfaction when low; padded with thanks when high	Compare across channels and groups; investigate silence
Response time	Speed of acknowledgement and answer	Clock stopped at acknowledgement, not at answer	Time-to-substantive-response, sampled and verified
Closure rate	Whether cases reach resolution	Cases closed as 'resolved' without the person's confirmation	Callback sample: did you get an answer? was it fair?
Adaptation count	Whether feedback changes the programme	Relabelling planned changes as feedback-driven	Decision log linking each change to the trend that prompted it

The pattern is general: every throughput metric needs a paired perception check from the people the mechanism serves — which is the measuring-AAP agenda described under accountability to affected populations [2][4].

Checklist before launching an FCM

• Channels were chosen with the community, cover the least-connected groups, and at least one allows private, low-literacy use.
• Every intake point has the sensitive-report instruction, and the confidential pathway with mapped referral services is live before launch.
• Each loop step has a named owner and a clock; “respond to the person” belongs to programme management.
• The category taxonomy is defined, and feedback trends have a standing slot in programme reviews.
• Metrics pair throughput with perception, and sensitive cases are counted separately at senior level.
• The community was told what the mechanism is for, what it cannot do, and what happens to their information.