
What if ops teams could build AI chatbots that collect documents, verify, and close citizen cases? No code visual builder for any government eService.
Citizens perform household updates through the HOMES system, generating cases that officers
must process manually. In FY25, 7,794 such cases were created. Officers call citizens back to
clarify actions, collect supporting documents, and verify submissions. Many of these calls go
unanswered because citizens cannot tell them apart from scam calls. Volume is projected to
triple as more schemes which are onboarded to HOMES direct their applicants to update their
household. 30 MOHH officers manage this entire caseload manually today.
Citizens log into HOMES eService via Singpass and update their household: adding a
member, editing a relationship, removing a member, or declaring a member as overseas
based. The system accepts the action but cannot process it without supporting
documents. A Means Test Construct (MTC) case is created and assigned to an
operations officer who must now reach out to the citizen, clarify what they did, explain
what documents are needed, and collect them.
By the time the officer calls, the citizen has moved on. They see an unknown number
and do not answer because they cannot distinguish it from a scam call. The officer
sends an SMS, then an email, then waits. Cases sit unresolved. When citizens
eventually respond, many are frustrated or suspicious about being contacted.
The citizen was authenticated, in context, and in the system at the moment they
performed the action. The system had their full attention. It let them walk away, then
spent days trying to get it back.
There is a fundamental mismatch between when the system needs information from the
citizen and when it asks for it. The citizen is ready at the moment of action. The system
asks days later through a channel citizens no longer trust. Every case follows the same
sequence regardless of complexity: action performed, case created, officer chases
citizen, officer explains requirements, citizen eventually submits documents, officer
verifies. The entire sequence is manual, sequential, and dependent on a phone call that
increasingly does not get answered.
Cases take 3 to 5 working days to resolve after the citizen has already performed the
action. Each case costs the agency $19.90 in processing, rising to $34 in the coming
year. At current volume this is $155K annually. As volume triples with more schemes
onboarding, annual cost will exceed $748K. Citizens experience delays in subsidy
eligibility decisions while their cases wait in a queue. Officers are consumed by routine
outreach and verification instead of complex cases that genuinely require human expertise.
The operating model cannot absorb volume growth without proportional headcount increases.
We embedded with the MT Ops team directly. We shadowed officers processing cases
from initial outreach through to closure and conducted structured interviews about their
workflow and pain points.
Each case takes 15 to 20 minutes of officer time. The largest variable is whether the
citizen answers the phone. When they do not, the case enters a holding pattern with no
guaranteed resolution timeline.
Officers repeat nearly identical explanations across every case. The same clarifying
questions, the same document requests, the same verification checks. The work is
predictable and rule-based for routine cases.
Citizens routinely ignore government calls. They cannot distinguish them from scam
calls. This is a systemic behavioural shift affecting all government phone-based
outreach, not only MOH.
Officers want to focus on genuinely complex cases involving disputes, mismatches, and
edge situations. Routine volume prevents this. The most critical insight: the citizen is already authenticated and fully in context at the
moment they perform the action. The system has their attention and has everything it
needs to engage them immediately. Instead, it creates a case and sends it to a human
queue.
Our approach rests on three validated assumptions:
First, citizens will complete the process immediately if engaged at the right moment.
The current failure is timing and channel, not willingness. The citizen is already logged
in, has just performed the action, and understands what they did. Engaging them with a
bot in that same session eliminates every friction point: no unknown phone number, no
confusion about why they are being contacted, no need to context-switch days later.
Second, AI can handle structured verification workflows reliably. We validated this
through a working proof of concept using OCR document extraction and cross-checking
against existing records. The bot follows a constrained workflow with fixed steps,
defined retry limits, and automatic escalation to a human after three failures. This is
structured automation with guardrails, not open-ended AI.
Third, the pattern is reusable beyond MOH. The sequence of citizen performs action,
system needs supporting information, officer chases citizen exists in agencies across
government. Building a configurable platform ensures the investment compounds rather
than remaining a one-off solution.
The MOH system owner has endorsed the project and approved development. The
MOHH operations lead, who manages the 30-officer team, has committed to supporting
the build and making officers available for testing. The initiative aligns with the HOMES
digital transformation roadmap.
VICA handles FAQ queries but cannot process documents, run multi-step verification
workflows, or close cases. OPUS automates internal decision logic but does not face
citizens. Pair is an internal officer productivity tool. FormSG collects data through static
forms but offers no conversational AI, no verification logic, and no ability to write
resolved data back to case management systems.
Commercial platforms such as Voiceflow, Botpress, and Dify are not hosted on GCC,
have no government system connectors, no PDPA compliance controls, and no
document verification pipelines integrated with government databases. Citizen-sensitive
data must remain within government infrastructure, which rules out commercial SaaS
entirely.
No platform in Singapore government today enables operations teams to visually build
citizen-facing AI chatbots that verify documents, cross-check records, and write
resolved cases back to source systems. ARCO addresses this directly.
The citizen is in the system at the moment of action. Instead of letting them leave and
chasing them later, ARCO engages them immediately with a bot that clarifies the action,
collects supporting documents, verifies everything, and closes the case in that same
session. The case never reaches the ops queue. The citizen resolves in minutes what
previously took days.
ARCO enables this by letting operations teams compose this entire workflow visually on
a canvas. Teams build the conversation flow, verification logic, and API integration
without writing code. The bot is embedded into the existing eService portal through the
application vendor with minimal code changes. Citizen-sensitive data stays within
government infrastructure because AI inference runs on a government-approved AI
service.
What citizens experience:
A citizen logs into HOMES eService via Singpass and performs a household action,
such as adding a spouse. Immediately, a chat widget appears within the same session.
The bot acknowledges the action, asks clarifying questions about why they are adding
this member, and requests the relevant supporting document such as a marriage
certificate. The citizen uploads the document directly in the chat. OCR extracts the data
and the system cross-checks it against HOMES records. If everything matches, the
citizen reviews a summary, confirms, and the case is closed with a reference number.
Total time: under 10 minutes in a single session. If verification fails after three attempts,
the case escalates to a human officer with full context attached.
What operations teams experience:
Teams open the ARCO workflow builder and see a canvas with a palette of pre-built
nodes: Chat Agent, Classifier, Upload Document, OCR Extract, Validator, Conditional
Logic, Guardrail, Loop, Human Escalation, and API Connector. They drag nodes onto
the canvas and connect them to define the conversation flow, verification logic, and
case submission back to HOMES.
Teams configure their government-hosted AI key, then test the bot directly from the
builder as they build it. ARCO provides built-in testing capability so teams can validate
the entire conversation flow, verify node logic, and confirm the bot behaves correctly
before deployment. The only component requiring separate validation is the API
integration with HOMES, which involves coordination with the application vendor.
Once testing is complete, the bot is deployed into the HOMES eService through the
vendor with minimal code changes. The bot is live.
For citizens, the experience is seamless. They are already logged in and have just
performed the action. The bot appears in context and the conversation is directly
relevant to what they just did. There is no confusion about why they are being asked for
documents because the request happens immediately after their action. It is available at
any time because the engagement happens the moment the citizen acts, regardless of
business hours.
For operations teams, the builder uses plain language node names and visual
connections. Workflows are visible, testable, and editable. The built-in testing means
teams can iterate on the flow without deploying to production. When the underlying
process changes, teams update the flow and re-test within ARCO before coordinating a
deployment update.
What feedback did users give about the product? What worked well and what required improvement?
We plan to conduct user testing in the next phase with MT Ops officers. This includes
usability testing of the workflow builder, an end-to-end pilot with a controlled set of real
household update cases, and measurement of completion rates, resolution times, and
reduction in cases reaching the ops queue.
Our North Star metric is the percentage of household update cases that resolve at point
of action without ever reaching the ops queue.
Cost projection:
Platform hosting is estimated at approximately $200 per month. AI inference runs on a
government-approved AI service within government cloud infrastructure, ensuring
citizen data never leaves the government boundary. Based on comparable AWS
Bedrock pricing for a typical 5-turn conversation with 2 document verifications, per-case
inference cost is projected well under $1. All cost figures will be validated during the
pilot. Even at conservative estimates, the combined platform and inference cost
represents a 95%+ reduction from current manual processing.
In the short term, over the next three months, we will complete the working prototype of
the household update bot on ARCO and demonstrate the full loop: citizen performs
action, bot engages, documents collected and verified, case written back to HOMES via
API. We will conduct user testing with MT Ops officers and refine based on feedback.
In the medium term, over six to twelve months, we will pilot with real cases on the
HOMES eService. The target is to resolve 70% of cases at point of action so they never
enter the ops queue. Officers shift focus entirely to complex cases that require human
expertise.
In the long term, ARCO becomes the standard platform for citizen-facing AI workflows
across MOH and beyond. Within MOH, we will extend to every HOMES workflow type
as new schemes come online, covering the full range of household actions and case
types that currently require manual officer intervention. Beyond MOH, ARCO is
available to any government agency facing the same structural problem: a citizen
performs an action in an eService, the system needs supporting information, and today
an officer chases them manually. MOM, HDB, CPF, ICA, and any agency running citizen
document workflows can build on ARCO, configure their own government-hosted AI,
and deploy into their existing eService. One platform. Every agency. Every citizen
workflow that should have been resolved at the point of action but today sits in a queue
waiting for a phone call that will never be answered.