FUNAE – MGQR (Grievance Redress Mechanism)

FUNAE – Fundo de Energia runs electrification projects funded by Enabel. The funder requires a grievance redress mechanism (GRM): anyone affected by a project must be able to complain, and the complaint must be answered within set deadlines.

TechSolutions won the development contract and put together a team of nine developers. I opened the repository with the documentation, milestones and issues, and was the developer who delivered the most work between November 2025 and April 2026.

The citizen chooses to be identified or anonymous, describes the case and attaches evidence. The system generates a public reference in the GRM-YYYY-XXXXXXXX format so they can track its status.

From there the submission moves through explicit states: under review, assigned, in progress, pending approval and finally resolved, rejected or closed. The officer cannot close it alone: they request closure and the manager approves or sends it back. Every change is kept in the submission's history.

I wrote the service that decides who handles each submission. It is not a complex algorithm, on purpose. It looks for an available officer on the same project whose current workload plus the new submission's weight fits their capacity, and who is below 50% of it. If there is one, it assigns inside a transaction and fires an event to send notifications.

If nobody meets the rule, the submission stays "under review" and goes to the manager. We preferred a human decision to piling work on someone who is already busy. Two scheduled commands complete the service: one retries pending submissions and the other rebalances workload.

The notification service emails the officer and the manager on assignment and on closure requests, using nine email templates. Every send is logged, and a command retries the failed ones. SMS integration was left for later.

Many citizens do not use email. The login accepts an email, a phone number or a username, detects which one was typed and normalises the phone number before looking it up.

Access uses spatie/laravel-permission with seven roles: Citizen, Officer, Manager, Deputy Manager, Director, Board Chair and Admin. I built the Deputy Manager role end to end (migration, seeders, controllers, middleware and screens) and merged the old Super Admin and Admin into one role.

Each role has its own dashboard. I did much of the Vue frontend: dashboards, attachment gallery, submission form and dark mode, plus production fixes such as the 419 error on first login and project location by province, district and administrative post.

The Laravel scaffold was set up by a colleague. The legal deadlines (10 working days to acknowledge and 20 to respond, with "overdue" and "due soon" states) were implemented by another colleague. The GitHub Actions CI/CD pipeline (lint, build and tests) is also a colleague's work. The PDF and Excel reports were mostly by other authors.

In the same period, TechSolutions ran a training programme for FUNAE staff on managing systems and web platforms, so the in-house team can operate and maintain them. I took part as a trainer; TechSolutions' public news item is in the links.

In numbers: 214 Vue components, 50 migrations, 7 roles and 11 PHPUnit test files. The production address no longer responds, so there is no link to the application.