Your gap is Grievance and feedback system
A low score in Section 4 does not mean you have a broken system. It means the system has not yet demonstrated to communities that using it is worth the effort. And until it does, communities will route their concerns around it rather than through it. The register will show low numbers. The low numbers will be read as low concern activity. And the actual concern activity will be happening in barangay halls, in group chats, in conversations with contractors, in the spaces where communities have found it safer and more useful to talk than in your formal intake channel. These are the conditions that signal this gap is active in your project:
Your grievance register is showing few or no entries during a period when your team is actively hearing concerns through informal channels. The system exists but it is not where the concerns are going.
Community members who raised concerns three weeks ago cannot tell you what happened. They received an acknowledgment, or nothing at all, and have heard nothing since. They will not file again.
You have resolved individual cases but have never reviewed the register as a whole to look for patterns. The same category of concern has appeared six times from different people and no one has identified it as a systemic issue.
Your GRM was designed by your team. You have never asked community members whether the intake channel actually works for them, whether it is accessible, whether it feels safe, whether they believe it will produce a result.
A key ComRel or GRM staff member has recently changed roles or left the project. No structured handover of open cases, community relationships, or system knowledge took place. The new person is starting from scratch.
Concerns that involve more than one institution (a land issue that touches the LGU, an environmental concern that involves DENR, a livelihood impact that requires a response from both the developer and a regulator) have no clear single point of accountability. They are being referred from one institution to another without anyone taking ownership of the response.
Your register shows concerns being logged but the feedback closure column is consistently empty. Cases are being received and addressed but the person who raised the concern has not been told what happened. In the community, the experience is indistinguishable from a case that was ignored.
You are entering a new project phase (from construction to operations, or from pre-development to construction) and no review of open GRM cases or system design has been triggered by the transition. The system that was designed for one phase is being used unchanged in the next.
Toolkit response — protocols, tools, and skills
The following protocols, tools, and skills address the conditions identified in Section 4 of the self-assessment. They are designed to be used together: the skills build the practitioner capabilities needed to recognize signals; the tools provide the structures for capturing and monitoring them; the protocols define when and how to act on what is found.
Your immediate actions for Section 4
1 Open your grievance register today and look at every case without a confirmed feedback closure. Assign a named person and a specific deadline to each one before the end of this week. Do not open new intake channels, redesign the system, or brief new staff until the backlog of open cases without closure has been addressed. A community member who filed two months ago and has heard nothing is your most urgent GRM problem, not your next system design decision.
2 Set up T-20 Grievance Register as a shared log if one does not already exist, or audit your existing register against the template. Every concern received through any channel (text message, barangay relay, verbal report from a contractor, informal conversation) must have an entry within 24 hours. A concern that was received but not logged does not exist in your system. It exists in the community.
3 Activate P-04 Feedback Closure Protocol for every open case. The protocol defines exactly what closing a case requires: not an internal decision that the matter has been resolved, but confirmed receipt by the person who raised it. Until they have been told what happened and have acknowledged it, the case is not closed. This single step, closing the loop with the person who filed, is what transforms a grievance log into a functioning accountability system.
4 Run T-23 Grievance Trend Analysis on your current register. Even if the register is incomplete, review what is there for patterns: the same concern category appearing from different people, the same barangay consistently generating entries, the same type of issue recurring after it was supposedly resolved. Three or more entries in the same category within a 30-day period is a trend, it points to a systemic condition that case-by-case resolution will not fix.
If a key GRM staff member has recently left or is about to leave, trigger P-28 Contractor and Staff Offboarding Protocol and T-36 Phase Transition Review Checklist immediately. The relationships, the open cases, and the institutional knowledge that person carries do not transfer automatically. Without a structured handover, they leave with them.
Skills
SK-16 Active Case Management
What the Evidence Shows
Three GRM conditions appear across project contexts in the field research. One showing what a functioning but fragile system looks like, one showing what happens when no formal system exists, and one showing what reactive-only response produces over time.
Accessible but Undocumented
Concerns with No Institutional Home
Operational context — accessible but undocumented
In an operational context, a relatively stable pattern of grievance handling had developed over years. Community members and barangay officials knew they could contact the developer’s representatives directly (by phone, by text message, by in-person visit) and that doing so would typically produce a response. The system worked, in the sense that issues were raised and addressed. But it worked almost entirely through informal channels, personal relationships, and the accessibility and goodwill of specific individuals. There was no formal grievance register capturing all concerns, no pattern analysis to identify recurring issues, and no documentation of what was raised, how it was responded to, and when it was closed. When the individuals who made the system work were reassigned or departed, the community’s primary point of access departed with them.
“Come to the people. Assure the people that fishing and the environment will not be harmed."
Community member
Pre-development context — concerns with no institutional home
In a pre-development context, stakeholders who had concerns about the project’s implications for fishing access, water conditions, and livelihood security faced a structural problem. They were uncertain which institution was responsible for receiving and acting on those concerns. Each institution referred them to the next. At the time of fieldwork, no grievance mechanism was operational. From the community’s perspective, concerns that entered this referral chain simply disappeared. The absence of a GRM was not experienced as a regulatory gap to be resolved at a future policy level. It was experienced as an absence of recourse.
Concerns with No Institutional Home is what happens when governance complexity (overlapping mandates, novel technology, unresolved jurisdictional questions) produces a situation where a community member with a legitimate concern cannot find a single institution willing and able to receive it. The concern is not filed. It is not logged. It is not tracked. It circulates in community conversations instead, growing in significance with each retelling and each failed referral, until it becomes part of the accumulated grievance against the project rather than a resolved case within the system.
Development context, active construction phase, formal GRM in place
A formal grievance register existed. Intake channels had been established and communicated. The design was adequate. But during a period of active construction (when community members had direct daily experience of disruption, dust, noise, changed access routes, and employment uncertainty) the register showed almost no entries.
This was not because concerns were absent. Field staff were hearing them. Barangay officials were receiving them. They were traveling through every informal channel available. They were simply not entering the formal system. When community members were asked why they had not used the GRM, the answers were consistent: they did not believe anything would happen; they had heard from others that concerns raised through official channels were acknowledged and then forgotten; and the process felt designed for the project's records rather than for their benefit.
The register was closed. The community was not.
The Closed Register is what happens when a GRM exists in form but has not yet demonstrated in practice that it delivers. Communities make rational decisions about whether to invest effort in a process based on evidence of what that process has produced. A GRM that acknowledges receipt and then goes silent has already taught communities not to use it. The register shows low numbers. The low numbers are read as low concern activity. The actual concern activity is happening somewhere else entirely.
The Closed Register
“They can be texted, they can be messaged.”
Municipal official describing the GRM
This quote captures the strength and the fragility of the system simultaneously. Accessibility through direct messaging is genuinely valuable, it lowers the threshold for raising concerns and produces faster responses than formal intake processes. But accessibility through personal contact is not a GRM. It is a relationship. And relationships do not survive personnel changes, phase transitions, or the organizational dynamics that move key people out of their roles.
WHAT NEEDS TO SHIFT
Developer / ComRel Officer: Your GRM is only as strong as its weakest link, and in most projects, the weakest link is not intake. It is closure. A community member who files a concern and receives no response has been taught, concretely and permanently, that the system does not work. Every concern that enters your register without a documented closure and a confirmed feedback loop is eroding the trust your engagement activities are trying to build. The shift most within your reach: review every open case in your register this week. For every case without a closure date and a confirmed feedback step, assign a responsible person and a deadline today.
LGU / Barangay You are receiving concerns that are not reaching the formal GRM, and you may be the only actor who knows it. Constituents bring things to you that they do not bring to the developer, and when they ask you what happened, you often cannot tell them. The shift most within your reach: start treating what you receive as GRM input that deserves a formal entry. Ask the developer how concerns relayed through you are being logged and responded to. If you cannot get a clear answer, that is a governance gap worth naming.
Community / CSO A concern that stays in community conversation has not entered the system that can act on it. You have every right to ask, directly: is this concern logged? What is the response timeline? Who is responsible for responding? CSOs who accompany community members in GRM interactions (helping them document concerns, tracking response timelines, and following up when responses do not arrive) are performing a function the system depends on. That function is not supplementary. In low-trust contexts, it is often the only thing that makes the formal system work.
NGA / Regulator A GRM with low grievance numbers during active construction phases should trigger scrutiny, not satisfaction. Your monitoring framework should ask not just how many concerns were filed, but whether the conditions for filing exist: whether communities know the system, trust it, and have experienced it delivering results. A GRM that is formally compliant but functionally unused is a compliance risk, not a sign of community acceptance.
This website shared to the public for free courtesy of the
THE CONFLICT RESOLUTION GROUP FOUNDATION, INC.
www.coregroup.org.ph * info@coregroup.org.ph
through our SustainABILITIES Lab Project
© Pixelhaze 2024. A Hostinger Website Builder Template by Pixelhaze Studio
This toolkit is provided for general guidance and informational purposes only. It is not intended as legal, technical, or professional advice. While efforts have been made to ensure accuracy and relevance, users are encouraged to exercise their own judgment and consult appropriate experts when necessary. The developers of this toolkit assume no liability for any decisions or actions taken based on its use.

