Citizen Information & Engagement Government Service Management SystemLegacy format

---

### 1.1 Dashboard Overview

Purpose: Give barangay officials/staff a real-time, at-a-glance summary of everything happening across the system.

What's inside:

• Summary/KPI cards

• Total registered citizens (with % change vs. last month)

• Pending approvals (registry + certificates combined, or split)

• Open/unresolved grievances

• Certificates issued this month

• Active surveys/consultations

• Visual analytics

• Line/bar chart: citizen registration trend (monthly)

• Pie/donut chart: grievance categories breakdown

• Bar chart: certificate types requested (most to least)

• Recent activity feed

• Latest 5–10 actions system-wide (e.g., "Juan Dela Cruz registered," "Certificate #2024-0512 issued," "New concern filed: Streetlight outage")

• Action shortcuts

• "X approvals need your attention" → jumps directly to that queue

• Role-based view

• Barangay Captain sees everything; a Clerk might only see modules relevant to their assigned tasks

---

Overall purpose: Digital replacement for the barangay's logbook/paper masterlist of residents.

### 2.1 Registered Citizens

Data fields per citizen record:

• Personal Info: Full name, alias/nickname, birthdate, birthplace, sex, civil status, citizenship, religion (optional)

• Contact Info: Mobile number, email (optional), landline (optional)

• Address: House no./street, Purok/Sitio, years of residency

• Household Info: Household ID/number, relationship to household head, household head name

• Government IDs: Voter's ID number, PhilSystem/National ID (optional, for reference only — not verification), other valid ID type + number

• Employment/Status: Occupation, employment status, PWD status, senior citizen flag, 4Ps beneficiary flag, solo parent flag

• System metadata: Date registered, registered by (staff name), status (Active / Inactive / Deceased / Transferred Out), last updated

Features:

• Search & filter (by name, Purok, age range, status, special classifications like PWD/senior)

• Sort columns (alphabetical, date registered, age)

• View full profile (modal or dedicated page)

• Edit record (with edit history log)

• Household grouping view (see all members of one household together)

• Export list (PDF/Excel) — e.g., for Purok-wide reports or COMELEC-style listings

• Bulk actions (e.g., mark multiple as "for validation")

### 2.2 Pending Approvals

Purpose: Queue for new registrations awaiting verification before becoming "official" records.

What's inside:

• List of submitted registrations (self-service or staff-encoded) not yet approved

• Each entry shows: submitted date, submitted by, proof of residency/ID uploaded (image preview)

• Actions: Approve (moves to Registered Citizens), Reject (with reason dropdown: incomplete info, invalid ID, duplicate, not a resident, etc.), Request more info (sends notification back to submitter if self-service)

• Assign reviewer (if multiple staff handle approvals)

### 2.3 ID Verification Logs

Purpose: Audit trail — proof that identity checks were actually done (important for accountability/thesis defense re: data integrity).

What's inside:

• Log entries: Citizen name, ID type checked, verifying staff, date/time, verification result (Verified / Failed / Flagged), remarks field

• Filter by staff, date range, or result

• Read-only historical record (cannot be edited, only appended — for audit integrity)

### 2.4 Duplicate Flags

Purpose: Prevent the same resident from having multiple registry entries.

What's inside:

• System auto-flags potential duplicates based on matching criteria (e.g., same name + birthdate, or same name + address)

• Side-by-side comparison table of the two/more flagged records

• Actions: Merge (combine into one record, choose which data to keep), Not a duplicate (dismiss flag, log reason), Delete duplicate

• Flag status: Pending Review / Resolved

---

Overall purpose: Digitized "hotline"/complaint desk — residents report issues, staff track and resolve them.

### 3.1 Incoming Concerns

Data fields per concern:

• Concern ID/ticket number

• Title/subject

• Description (full text)

• Category (Infrastructure, Peace & Order, Sanitation, Noise Complaint, Utilities, Other)

• Submitted by (name or "Anonymous" if allowed)

• Date/time filed

• Attachments (photo/video evidence)

• Location tag (Purok/Sitio, or optional pin on map)

• Status (New / Under Review / Routed / In Progress / Resolved / Closed)

• Priority level (Low / Medium / High / Urgent)

Features:

• List/table view with filters (status, category, date, Purok)

• Detail view per concern with full thread of updates

• Option for anonymous submission (with abuse-prevention consideration — worth discussing in your thesis limitations)

### 3.2 AI Analysis Results

Purpose: This is your system's "smart" feature — likely a key selling point of the capstone.

What's inside:

• Auto-categorization: AI suggests category based on description text (e.g., detects "streetlight," "walang ilaw" → Infrastructure)

• Sentiment/urgency scoring: Flags concerns with urgent/distressed language for priority handling

• Duplicate/similar concern clustering: Groups multiple reports about the same issue (e.g., 5 people reporting the same pothole) so staff don't handle them as separate cases

• Suggested routing: Recommends which department/official should handle it

• Confidence score/explanation (optional, for transparency — "flagged as Urgent due to keywords: fire, danger")

• Staff can accept or override AI suggestions (important to include — shows human-in-the-loop design, good for thesis defense)

### 3.3 Concern Routing

Purpose: Assign and track ownership of each concern.

What's inside:

• Assign concern to specific staff/official/department (dropdown)

• Status tracker: Assigned → Acknowledged → In Progress → Resolved

• Internal notes/comments thread (staff-only, not visible to citizen)

• Due date/SLA tracking (e.g., "should be addressed within 3 days")

• Notification trigger to assigned staff

### 3.4 Resolved Concerns

Purpose: Archive + accountability record.

What's inside:

• Resolution summary (what was done)

• Resolved by, date resolved

• Time-to-resolution metric (auto-calculated)

• Citizen satisfaction rating (optional — star rating or thumbs up/down if you build a feedback loop)

• Searchable archive for reporting/analytics

---

Overall purpose: Digitizes the most common barangay transaction — requesting and releasing official documents.

### 4.1 Certificate Requests

Data fields:

• Requester name (linked to Citizen Registry record if possible — auto-fill)

• Certificate type: Barangay Clearance, Certificate of Residency, Certificate of Indigency, Business Permit Clearance, Certificate of Good Moral Character, First-Time Jobseeker Certificate (RA 11261), etc.

• Purpose (dropdown: employment, school requirement, loan application, government transaction, etc.)

• Date requested

• Supporting documents uploaded (valid ID, proof of address)

• Status (Pending / Approved / Ready for Release / Released / Rejected)

Features:

• Request form (citizen-facing if self-service is included) or staff-encoded (walk-in)

• Auto-populate requester details from registry to reduce encoding errors

### 4.2 Pending Approvals

What's inside:

• Queue of requests awaiting Barangay Captain/authorized official's approval

• Document preview before approval

• Approve → generates certificate for printing; Reject → reason required, notifies requester

### 4.3 Issued Certificates

What's inside:

• Log of all released certificates: Control/reference number, type, requester, date released, released by (staff name)

• Downloadable/printable copy (PDF with barangay letterhead, official seal placeholder, signature line)

• Reprint option (for lost copies, with reprint tracking)

### 4.4 Payment Records

What's inside:

• Fee per certificate type (configurable in Settings)

• Payment status: Paid / Waived (e.g., for indigents) / Pending

• OR (Official Receipt) number

• Daily/monthly revenue summary

• Exportable financial report (useful for barangay treasurer reconciliation)

---

Overall purpose: Digital tool for gathering community input — replaces paper surveys/town hall sign-up sheets.

### 5.1 Manage Surveys

What's inside:

• Survey builder: title, description, question types (multiple choice, checkbox, rating scale, open text)

• Target audience filter (all residents, specific Purok, specific demographic like senior citizens)

• Open date / close date (auto-closes after deadline)

• Anonymous vs. identified responses toggle

• Draft / Published / Closed status

### 5.2 Live Results

What's inside:

• Real-time response count and completion rate

• Auto-generated charts per question (bar chart for multiple choice, word cloud for open text — optional)

• Filter results by Purok/demographic

### 5.3 Participation Analytics

What's inside:

• Turnout rate (% of eligible residents who responded)

• Breakdown by age group, gender, Purok

• Comparison across multiple surveys (trend over time)

• Non-response tracking (who hasn't participated, for follow-up reminders)

### 5.4 Published Consultations

What's inside:

• Public-facing archive of past consultations and their outcomes

• Summary report per consultation (findings + how it informed a barangay decision — good for transparency/accountability)

• Downloadable results (PDF)

---

Overall purpose: Mass communication tool for the barangay (emergency alerts, event reminders, advisories).

### 6.1 Compose Alert

What's inside:

• Message title + body text

• Category (Emergency, Health Advisory, Event, General Announcement, Curfew/Ordinance Notice)

• Target recipients: All residents / Specific Purok / Specific group (e.g., senior citizens only)

• Delivery channel selection (SMS, in-app/push notification, email)

• Schedule send (immediate or scheduled for later)

• Attach image/document (optional, e.g., event poster)

### 6.2 Broadcast History

What's inside:

• Chronological log of all alerts sent

• Sender, date/time, recipient count, channel used

• Ability to view full message content of past broadcasts

### 6.3 Delivery Reports

What's inside:

• Per-recipient delivery status: Sent / Delivered / Failed / Read (if trackable per channel)

• Failure reason (e.g., invalid number, no internet)

• Delivery rate summary (e.g., "92% delivered successfully")

### 6.4 Alert Templates

What's inside:

• Pre-written reusable templates for common scenarios: Typhoon Warning, Vaccination Schedule, Curfew Notice, Barangay Assembly Reminder, Garbage Collection Schedule Change

• Create/edit/delete templates

• One-click "use template" when composing a new alert

---

Overall purpose: Cross-module reporting for decision-making and official accountability (e.g., for Sangguniang Barangay reports, COMELEC-related submissions, DILG compliance).

What's inside:

• Registry reports: population growth, demographic breakdown (age, sex, PWD count, senior citizen count, 4Ps beneficiaries)

• Grievance reports: resolution rate, average resolution time, most common concern categories, staff performance (concerns resolved per staff)

• Certificate reports: most requested certificate types, revenue generated, turnaround time

• Survey/consultation reports: participation trends over time

• Custom date-range filters for all reports

• Export formats: PDF (for printing/filing), Excel/CSV (for further analysis)

• Visual dashboard summarizing all of the above (could double as an extended Dashboard Overview)

---

### 8.1 User Management

What's inside:

• List of all staff/admin accounts (name, role, status: active/deactivated)

• Add new user (assign initial role, send login credentials)

• Deactivate/reactivate account

• Password reset trigger

• Activity log per user (optional — who did what, when)

### 8.2 Role & Permissions

What's inside:

• Predefined roles, e.g.:

• Barangay Captain — full access, final approver

• Barangay Secretary — registry + certificate management

• Kagawad (Council Member) — view-only or assigned module access

• Clerk/Staff — data encoding, limited to assigned modules

• IT Admin — system settings, user management only

• Permission matrix per role (view / create / edit / delete / approve, per module)

• Custom role creation (if you want a more flexible system)

### 8.3 Settings

What's inside:

• Barangay profile info: official name, address, contact info, logo/seal upload (for certificates)

• Certificate fee configuration

• Notification channel setup (SMS gateway API credentials, email SMTP settings)

• System preferences: date format, default language (English/Filipino toggle if applicable)

• Backup/data export settings

### 8.4 Logout

• Simple session termination, redirect to login screen

---

• Consider mapping each submodule to a user role (who can access/edit what) — this becomes your Role & Permissions matrix and is often required in Chapter 3 (System Design) of capstone papers.

• The AI Analysis Results submodule under Feedback & Grievance is likely your most "novel" contribution — worth a dedicated section explaining the model/approach (rule-based NLP vs. ML classifier vs. API-based like using an LLM).

• Keep scope realistic: since this is barangay-level (not city/national), you may want to explicitly state in your thesis limitations that PSA civil registry integration, COMELEC voter validation, and national ID verification are out of scope — the system only handles barangay-level records.