The Dashboard That Nobody Trusted
A national agency has launched an online service portal that lets citizens apply for a certification, upload documents, pay a fee, and track status. After eight months: 61,000 accounts created, 22,000 applications started, 14,000 completed, and 3,100 fee payments recorded. Average completion time is 19 days against a 7-day service standard. The help desk logs 4,800 tickets, 70% about upload failures on mobile. Field offices report that walk-in applicants still outnumber online ones three to one. The agency's IT unit proposes a PHP 25,000,000 rebuild on a new platform. The undersecretary asks you, as the digital governance adviser, to assess whether a rebuild is the right answer and to propose a sequenced plan for the next 12 months.
1. Evaluate the portal's performance using the figures given, and identify where the real bottleneck most likely lies.
Read the worked answer
Funnel analysis. Of 61,000 accounts, 22,000 started an application (36%), and 14,000 completed (64% of starts, 23% of accounts). The steep drop is between account creation and application start, with a second drop at completion. Payments recorded (3,100) are far below completions (14,000), which suggests either that payment is recorded outside the portal or that many completions are not truly complete.
Service standard. 19 days against 7 days means the process is slow even for those who finish.
Support signal. 70% of 4,800 tickets concern mobile uploads. That is about 3,360 tickets, a concentrated, reproducible defect rather than diffuse dissatisfaction.
Channel signal. Walk-ins outnumber online users three to one, indicating that the portal is not the path of least resistance.
Inference. The dominant bottleneck is likely the document-upload step on mobile, compounded by a slow back-end review. A platform rebuild would not fix a broken upload component or a manual review queue; those are configuration and process issues. The evidence does not support a PHP 25,000,000 rebuild as the first move.
2. Propose a sequenced 12-month plan with decision gates, and state what would justify the rebuild later.
Read the worked answer
Months 1–2: Diagnose and fix the upload path. Reproduce the mobile upload failure across common devices and file types; fix file-size limits, format handling, and session timeouts. Target: upload-related tickets down by half within 60 days. Gate: if the fix works, the rebuild case weakens considerably.
Months 3–4: Instrument the funnel. Add event tracking at each step so drop-off is measured, not guessed. Reconcile payment records against completions to find the 14,000-versus-3,100 gap.
Months 5–7: Attack processing time. Map the review step. Introduce status notifications, a queue dashboard, and a rule that applications idle beyond three days escalate. Target: median completion at or below 10 days.
Months 8–10: Shift the channel mix. Simplify the online form, add assisted-digital kiosks at field offices, and train front-desk staff to onboard walk-ins to the portal. Target: online share rising from 25% toward 50%.
Months 11–12: Decide on the platform. Reassess with data. A rebuild is justified if the current platform cannot support required security, interoperability, or volume even after the fixes, or if maintenance costs exceed a defined threshold. Otherwise, invest in incremental improvement and reserve the capital for later.
Report to the undersecretary at each gate with the metric and the decision.
3. What governance safeguards should accompany whichever technical path is chosen?
Read the worked answer
- Data protection: a documented privacy impact assessment, defined retention periods for uploaded documents, encryption in transit and at rest, and a named data protection officer with authority to halt processing.
- Accessibility and inclusion: compliance with accessibility standards, a low-bandwidth mode, and a maintained assisted channel so citizens without smartphones are not excluded.
- Procurement integrity: requirements written around outcomes rather than a preferred vendor, independent cost estimates, and milestone-based payments tied to verified performance.
- Change control: a configuration log so that fixes are traceable and reversible, and separation between the team that builds and the team that accepts.
- Service-level reporting: publish completion time, uptime, and ticket resolution monthly, so performance is visible outside the agency.
- Continuity: a fallback manual procedure and tested backups, so a system outage does not stop service.