Member and Request Management System

A district organisation holds three things that never meet: a member registry, a stream of citizen requests, and what the field actually knows. A request arrives as free text with no category and no owner, someone reads it and forwards it by phone, and whether it was ever resolved is nobody’s record. Meanwhile the data involved — identity, contact details, location — is exactly the kind that authorisation and retention rules have to be designed around rather than added to.

The AI layer is the interesting part and it is kept on a short leash. A citizen writes in plain language; the model returns a structured result against a fixed schema, behind guardrails, rate limiting and bot verification. Classification is all it does. Deterministic code then finds the head of the responsible commission, assigns the request, writes an audit event naming the assignment as automatic, and pushes a notification — and if no responsible person exists, the request stays unassigned rather than being sent somewhere plausible. Underneath, authorisation is enforced at the database with row-level security across more than thirty migrations, so a member sees their own queue and nothing else. Around it sit the field cadre on a map, duty rosters, activity reporting, bulk member import and consent records.

A request stops depending on who happened to read it: it is classified, owned, timed and visible, and management can see workload and resolution time instead of asking for it. Because the model only proposes a category and code performs the assignment, an AI mistake costs a re-routing rather than a lost citizen.

A management system on Next.js and Supabase with row-level security, unit-based authorisation, AI request classification and routing, a map view of field cadres, duty rosters and web push.