# M-Pass Postpaid POC — Operations & Citizen Experience Audit

**Reviewer:** Operations & Citizen Experience Expert (20 yrs Thai public service delivery)
**Date:** 17 June 2026
**Scope:** M-Pass Postpaid POC proposal (Discovery + Sandbox + Controlled POC — NOT national rollout)

---

## (a) Executive Summary — Operational Readiness Score: **4/10**

**Verdict: NOT YET READY FOR POC — substantial operational gaps exist that must be closed before live user testing.**

The pitch is well-structured in its policy positioning and legal/payment architecture thinking. The 7 Citizen Commitments show genuine intent. However, this is a pitch written by technology and finance experts, not operations people. The operational layer — the layer that touches the actual citizen — is the thinnest part of the proposal.

| Dimension | Score | Assessment |
|-----------|-------|------------|
| Call Center Readiness | 3/10 | Agent requirements outlined but no staffing model, no volume projections, no training curriculum, no language plan for migrant workers |
| Dispute Resolution | 4/10 | SLA mentioned, "evidence package" referenced, but no actual workflow, no investigation process, no escalation tiers |
| Citizen Accessibility | 3/10 | 7 Commitments are great principles but zero detail on unbanked (30%+), elderly, rural connectivity, disabled, or migrant non-Thai speakers |
| SOP Completeness | 2/10 | Critical lifecycle events (death, dormancy, vehicle sale, data breach, tag theft) completely unaddressed |
| Vendor/Integration | 5/10 | PSP gate well-identified, but Easy Pass data access question is the single biggest operational risk and is hand-waved |
| Timeline Realism | 3/10 | Gov procurement timeline ignored, BOT sandbox queue ignored, hiring/training timeline absent |
| Failure Mode Testing | 2/10 | Stop/pause criteria listed but no operational testing methodology described |
| **Overall** | **4/10** | **Comprehensive rewrite of operational sections needed before POC launch** |

---

## (b) Call Center & Support Operations Assessment

### What the Pitch Gets Right

The Call Center tab establishes a clear **must-show / must-not-show** split for agent screens. This is a solid starting point. They understand that:
- Agents need trip timeline, payment status, dispute case info, escalation workflow
- Agents must NOT see PAN, CVV, or unnecessary trip history
- Evidence packages should exist for every dispute

### What Is Missing (and These Are Dealbreakers)

**1. Staffing Model: No Volume Projection, No Headcount Plan**

A POC of 5,000-10,000 consumers + 5-10 fleets over 12-16 weeks will generate calls. How many?

- Estimated daily trip volume per active user: 2-4 trips
- 7,500 avg users × 3 trips/day = 22,500 trip events/day
- Even at 0.5% call rate (very optimistic for a new payment model), you're looking at ~112 calls/day
- First-week call rate will likely be 3-5% as users encounter registration friction, card declines, and confusion about billing

This means you need at least 6-8 bilingual (Thai/English) agents just for POC, working shifts. Where are they coming from? Existing Easy Pass call center? New hires? Outsourced BPO? The pitch says nothing.

**2. Training Requirements: No Curriculum Defined**

What training does an agent need before handling M-Pass Postpaid calls?

- **Day 1:** Postpaid billing model overview (MIT/UCOF, stored credential, daily threshold, fleet monthly) — half-day
- **Day 2:** System navigation — agent dashboard, trip timeline, payment status, consent records — half-day
- **Day 3:** Dispute handling workflow — evidence retrieval, chargeback process, refund authorization — half-day
- **Day 4:** Escalation protocol — tier 1 (agent resolution) → tier 2 (supervisor) → tier 3 (DOH/PSP) — half-day
- **Day 5:** Shadowing and supervised calls — minimum 8 hours

That's 5 days minimum per agent. If new hires, add 2 weeks for Easy Pass/M-Flow domain background. The 22-30 week timeline does NOT account for this ramp-up.

**3. Language Coverage: Thai + English Is Not Enough**

The Citizen Journey page references multilingual consent in EN, ZH, JA for the Foreigner tab. But the **real** language gap in Thai toll operations is:

| Language | Who Uses It | Priority for POC? |
|----------|-------------|-------------------|
| Thai (official) | All Thai citizens | ✓ Already covered |
| English | Tourists, expats | ✓ Partially (scripts exist) |
| Burmese | Migrant workers driving delivery/transport | ✗ NOT COVERED — significant population on Thai roads |
| Khmer (Cambodian) | Cross-border transport, migrant workers | ✗ NOT COVERED |
| Lao | Cross-border transport from Laos | ✗ NOT COVERED |
| Chinese (Mandarin) | Tourists | ✓ Mentioned (ZH) |
| Japanese | Tourists | ✓ Mentioned (JA) |
| Malay | Southern border travelers | ✗ NOT COVERED |

Migrant workers from Myanmar, Cambodia, and Laos are a significant user base of toll roads — especially in transport/logistics. They are among those who would benefit most from postpaid (no prepaid top-up friction). But the pitch has zero mention of how they will register, receive notices, or call support in their own language.

**4. Hours of Operation**

The pitch mentions "24/7 support" in the 6-step flow. A 24/7 call center for a POC with 7,500 users is operationally expensive. For a limited POC, the realistic model is:
- 8am-8pm: Full staffing (Thai + English)
- 8pm-8am: Call-back model or outsourced overflow, with critical-issue escalation path
- Language support during business hours only, with 24h callback for non-Thai/English

This operational model needs to be articulated and costed.

---

## (c) Citizen Accessibility & Inclusion Audit

The 7 Citizen Commitments are genuinely good policy framing. But they are **aspirations, not operational plans**. Here is where they break down for specific populations:

### 1. Unbanked Citizens (30%+ of Thai Adults)

The pitch relies on **card-on-file / stored credential** as the primary (and only POC-tested) payment method. This excludes:

- **30% of Thai adults** who do not have a credit or debit card
- **Rural poor** who rely on cash or government welfare cards
- **Informal sector workers** who may have income but no formal banking relationship

**What is needed:**
- A stated position that **PromptPay / direct debit will be added for unbanked access before any national rollout**
- A pilot within POC testing alternative payment: maybe 200 users on PromptPay-based auto-debit from savings accounts
- A pathway to cash-top-up or QR code payment at convenience stores (like TrueMoney Wallet or ShopeePay models)

Without this, "7 Citizen Commitments" is a promise available only to citizens who already have bank cards.

### 2. Elderly Users

The entire user journey assumes:
- Smartphone app usage (Login, consent, card verification, trip viewing)
- Digital literacy to navigate stored credential consent flows
- Understanding of billing model differences (daily threshold vs per-trip)

**What is missing:**
- **IVR-based registration:** Allow elderly users to opt in via phone call, not just app
- **SMS-based trip notifications:** Not just in-app — many elderly don't use apps regularly
- **Physical service counter at DOH offices:** An option for face-to-face registration during POC
- **Large-print/Thai-only mode:** The app needs a simplified Thai-only interface for elderly
- **Designated family member management:** An elderly person should be able to authorize a family member to manage their account

### 3. Rural Users with Poor Connectivity

Thailand's 4G coverage is good in cities but patchy in rural areas. Toll road users include:
- Inter-provincial buses and trucks
- Rural residents commuting to provincial centers
- Tourists visiting national parks and rural destinations

If the app requires network connectivity for consent, card setup, or trip viewing, rural users are second-class citizens in this system.

**What is needed:**
- **Offline-capable registration:** SMS-based consent; USSD for basic functions
- **SMS billing notifications** as primary channel, not backup
- **Low-bandwidth app mode** that works on 2G/3G connections

### 4. Disabled Users

Zero mention of accessibility anywhere in the pitch.

- **Visually impaired:** Does the app support screen readers (TalkBack, VoiceOver)? Are consent screens screen-reader accessible?
- **Hearing impaired:** Are notifications visual-only where they are currently audio? Is call center accessible via text chat/Line?
- **Mobility impaired:** Can all registration steps be done remotely without needing to visit a DOH office?

**Minimum requirements before POC:**
- WCAG 2.1 AA compliance for all customer-facing interfaces
- Text-based (chat/Line) support channel alongside phone
- Accessibility audit as part of DPIA

### 5. Non-Thai Speakers — Migrant Workers

As noted in the Call Center section, Burmese, Khmer, and Lao speakers are not addressed at all. This is especially problematic because:
- Many migrant workers drive delivery trucks, taxis, and transport vehicles on toll roads
- They are often unbanked or underbanked
- They are highly vulnerable to billing errors and would have no way to dispute

**Minimum:**
- Registration and consent materials in Burmese, Khmer, Lao
- Call center triage capability for these languages (perhaps outsourced interpreter line)
- SMS notifications in these languages

---

## (d) SOP Gap Analysis — Missing Operational Procedures

The pitch lists **stop/pause criteria** and **key controls** (one payer per vehicle, tag-first, duplicate detection, DPIA). These are technical controls, not operational SOPs. Here are the SOPs that would be needed for a real POC but are entirely absent:

### SOP 1: Card Expiry Handling
- What happens when a saved card expires?
- Does the Account Updater (VAU/ABU) automatically update the network token?
- If auto-update fails, how is the customer notified? SMS? Email? App notification?
- Grace period before suspending postpaid service? (Recommend: 14 days)
- What if the vehicle passes a toll during the grace period — still allowed or blocked?

### SOP 2: Account Dormancy
- When is an account considered dormant? (Recommend: 90 days of zero toll activity)
- Notification cycle before suspension: Warning at day 75, final notice at day 85
- Data retention: When is the token deleted?
- Can a dormant account be reactivated, or does the user restart the registration flow?

### SOP 3: Death of Account Holder
- How does DOH learn of an account holder's death?
- Family notification process
- Outstanding balance handling: Waived for POC? Charged against estate?
- Vehicle/tag de-linkage
- Token/card deletion
- This is sensitive and must have a clear, compassionate policy.

### SOP 4: Vehicle Sale or Transfer
- Seller has postpaid account linked to plate/tag
- Buyer may or may not have their own account
- Transfer process: Existing user removes vehicle → new owner registers (if Postpaid) or reverts to default prepaid
- Time window: Liability for tolls incurred during transition period
- DLT integration: Does DOH have real-time vehicle ownership data?

### SOP 5: Stolen Tag
- How does a customer report a stolen tag? (Call Center priority queue)
- Tag suspension — immediate or within SLA?
- Liability for tolls incurred between theft and report: Waived for POC
- Replacement tag process
- Fraud investigation handoff to DOH/PSP

### SOP 6: System Outage (Toll Ledger / Payment Orchestrator / PSP)
- Toll lanes continue to work (confirmed by pitch — good)
- But: Trip events stored in ledger queue — what if queue fills up?
- Billing delay: If PSP is down for 4 hours, do we still attempt same-day billing?
- Customer communication during outage: Proactive SMS or reactive only?
- Recovery SLA: How fast must the system be restored before it triggers POC pause criteria?

### SOP 7: PSP Switch or Re-procurement
- What happens to network tokens (VTS/MDES) when switching PSPs?
- Network tokens are portable; gateway tokens are not — good that the pitch specifies network tokens
- But: Does the new PSP have the same acquirer relationships?
- Migration window: How long can billing be paused during switch?
- Customer impact: Will customers need to re-consent or re-verify cards?

### SOP 8: Data Breach Response
- The pitch mentions DPIA and PDPA audit, but has no incident response plan
- If trip data is leaked: Who notifies citizens? Within what timeframe? Under PDPA Section 37, within 72 hours
- If card tokens are leaked (lower risk since DOH doesn't store PAN, but tokens can still be misused)
- PR crisis communications plan — who speaks for DOH/MOT?
- Legal liability: Is there cyber insurance?

---

## (e) Vendor & Integration Risk Assessment

### 1. The Easy Pass Data Question — SINGLE BIGGEST OPERATIONAL RISK

The pitch states: **"No immediate Easy Pass integration dependency"** under "Not Approving Yet."

This is misleading and I believe it is the biggest operational gap in the entire proposal.

**The Problem:**
Toll events on DOH-controlled M-Pass/M-Flow corridors still originate from toll lanes. Those toll lanes are:
- Operated by EXAT (Expressway Authority of Thailand) on some corridors
- Operated by BEM (Bangkok Expressway and Metro) on others
- Operated directly by DOH on M-Pass/M-Flow sections

For the POC to work, DOH needs **toll event data** — the record that a specific vehicle passed through a specific lane at a specific time. Where does this data come from if not from the existing Easy Pass system that processes the current prepaid billing?

**Possible answers (none provided in the pitch):**
1. **Direct DOH toll lane feed:** DOH may have its own raw lane event data from M-Pass/M-Flow plazas. If so, this needs to be confirmed and documented.
2. **Easy Pass data dump:** Periodic (daily/weekly) data export from Easy Pass systems — feasible but introduces latency and reconciliation complexity.
3. **Parallel collection:** The POC could install its own tag readers or plate cameras — completely duplicative and expensive.
4. **Manual upload:** Absolutely not workable for any volume.

**Without this answer, the POC cannot function.** The toll ledger needs trip events to create billing records. If there's no integration path to toll event data, the entire account-based tolling model collapses.

This must be resolved in the Discovery phase **before** the POC is approved.

### 2. Vendor Lock-in Risk

The pitch explicitly states "No vendor lock-in award" — good. But:
- The PSP chosen for the sandbox/POC inevitably develops deep knowledge of DOH's toll data structures, billing models, and reconciliation workflows
- Switching PSPs post-POC carries real cost and risk
- Recommendation: The POC contract must include:
  - All source code for integration layers owned by DOH
  - Open API specifications as deliverable
  - Data dictionary and data model documentation
  - Knowledge transfer and transition assistance

### 3. PSP Evaluation Criteria (Not Defined)

The pitch says PSP/acquirer selection is a Discovery gate. But what are the evaluation criteria?

Minimum criteria the POC should define:
- **UCOF/MIT capability:** Does the acquirer support Visa POS Entry Mode 10 + Environment C, Mastercard DE 48 SE 43 SF1=M+U?
- **Tokenization:** Network tokens (VTS/MDES) or proprietary gateway tokens?
- **Account Updater:** Visa VAU 2.0 or Mastercard ABU?
- **3DS readiness:** For CIT setup
- **Settlement speed:** T+1 or T+2?
- **Reconciliation reporting:** Settlement file format and granularity
- **Cross-border capability:** BIN coverage for US, EU, CN, JP, ASEAN
- **Pricing:** MDR rates for domestic and cross-border, monthly minimums, setup fees

### 4. PSP Failure During POC

What if the PSP goes down during the 12-16 week Controlled POC?
- Toll lanes continue (good — confirmed in Q&A)
- Payment attempts queue and retry (good — confirmed)
- But: What is the maximum acceptable queue depth? How long before the POC pause criterion triggers?
- Is there a backup PSP? For a limited POC, probably not (cost). So the POC must have a defined "PSP unavailable for X hours" pause criterion.
- Customer communication plan when billing is delayed.

---

## (f) Timeline Realism Check

### The Pitch Claims: 22-30 Weeks Total (Mobilization → Discovery → POC → Assessment)

| Phase | Pitch Estimate | Realistic Estimate with Gov Procurement |
|-------|---------------|----------------------------------------|
| Mobilization | 1-2 wks | 2-4 wks (working group approval, charter, inter-agency coordination) |
| Discovery & Sandbox | 6-8 wks | 8-12 wks (legal memo alone takes 2-3 weeks, PSP selection 2-4 weeks, sandbox setup 2-4 weeks) |
| Controlled POC | 12-16 wks | 12-16 wks (this is reasonable IF above phases complete on time) |
| Assessment & TOR | 2-4 wks | 4-8 wks (government TOR drafting must go through procurement review) |
| **Total** | **22-30 wks** | **26-40 wks** |

### Key Timeline Risks Not Addressed

1. **BOT Sandbox Evaluation (30-day evaluation per the pitch itself):** The BOT Enhanced Regulatory Sandbox requires an application, documentation review, and evaluation. If the BOT determines that stored-credential toll billing requires a license (not a sandbox registration), the timeline extends by months, not weeks.

2. **Government Procurement for PSP:** Even for a sandbox/POC, government procurement rules typically require:
   - TOR drafting and internal approval: 2-4 weeks
   - Publication and proposal period: minimum 30 days by regulation
   - Evaluation and selection: 2-4 weeks
   - Contract negotiation and signing: 2-4 weeks
   - **Total: 10-16 weeks** — and the pitch schedules this inside 6-8 weeks.

3. **PSP Technical Integration:** Even after selection, technical integration of the PSP's payment orchestration with DOH's toll ledger takes 4-8 weeks minimum. This includes:
   - API development and testing
   - Token vault integration
   - Reconciliation file format
   - Stored credential flow certification
   - Security penetration testing

4. **Call Center Setup:** Hiring 6-8 agents (as estimated above), training them, setting up the CRM/agent dashboard, and running a pilot test: 4-6 weeks.

5. **100-Day Timeline:** The 100-day Minister milestone shows legal/sandbox/readiness by week 8, then POC running weeks 11-24. The 100-day mark is roughly week 14 — the POC would just be starting. The Minister's "announcement" at week 14 would be "POC has launched" not "POC produced results." This needs to be set in expectation.

### Recommended Revised Timeline

| Phase | Duration | Notes |
|-------|----------|-------|
| Mobilization + BOT Consultation | 4 wks | Parallel track: legal + BOT pathway |
| Discovery + PSP Selection | 8-10 wks | Including procurement exemption or fast-track |
| PSP Integration + Call Center Setup | 6-8 wks | Start call center in parallel |
| Controlled POC | 12-16 wks | |
| Assessment + TOR Drafting | 4-6 wks | |
| **Total** | **34-44 wks** | **12-14 weeks more than pitch estimate** |

---

## (g) Failure Mode & Resilience Testing

The pitch lists stop/pause criteria:
- Legal authority blocker
- Payment success below threshold
- Unpaid exposure over cap
- Complaint rate over threshold
- Reconciliation variance
- Critical PDPA/cyber finding
- Call center SLA failure
- Media/public risk unacceptable

These are good **criteria**. But the pitch provides zero plan for **how to test that these criteria work** before real users are impacted.

### Operational Testing That Must Be Done Before POC Launch

1. **Payment Gateway Outage Simulation**
   - Take the PSP sandbox offline for 30 minutes
   - Verify: Toll lane events still recorded? Queue builds correctly? Retry logic fires? On restoration, is billing backlog cleared within 24 hours?
   - Measure: Maximum acceptable outage duration before queue overflow

2. **Mass Card Expiry Simulation**
   - Expire 100 tokens in bulk (simulating a batch of cards expiring)
   - Verify: Account Updater is called? Notification generated? Grace period enforced? Postpaid auto-suspension triggers?
   - Measure: Account Updater success rate, notification delivery rate

3. **Fraud Ring Simulation**
   - Simulate a single card used for 20+ vehicles in one day
   - Verify: Duplicate detection and fraud flag triggers? One-payer-per-vehicle rule enforced? Automated notification to account holder?
   - Measure: Detection latency, false positive rate

4. **Data Breach Tabletop Exercise**
   - Assume toll trip data has been exposed (unencrypted database backup discovered)
   - Walk through: Detection → containment → notification (PDPA 72-hour requirement) → media response → regulator reporting
   - Identify: Who has authorization to declare a breach? What is the communication tree? Is there a pre-approved media statement?

5. **Call Center Surge Test**
   - Simulate a one-day spike to 5x normal call volume (e.g., after first batch of billing statements goes out)
   - Verify: Queue handling, wait times, escalation triggers, abandonment rate
   - Measure: Average speed to answer, first-call resolution rate

6. **Reconciliation Breakage Simulation**
   - Introduce a mismatch between toll event count and billing ledger records (simulating data loss at a lane)
   - Verify: The 8-layer reconciliation model catches it at Layer 1? Alert generated? Correction workflow triggered?
   - Measure: Detection time, correction time

**None of these tests are described in the pitch. They must be built into the POC plan.**

---

## (h) Red Flags — What Would Make Operations Say NO

If I were the operational director sitting in a DOH meeting room, these are the points where I would put my pen down and say "We are not ready."

### 🚩 RED FLAG 1: "No immediate Easy Pass integration dependency" is dangerously misleading
The POC **requires** toll event data. If that data comes from Easy Pass, there IS an integration dependency — it just might not be a real-time API integration. The pitch needs to be honest about what data is needed, where it comes from, and what the integration mechanism actually is. Right now, this looks like a handwave.

### 🚩 RED FLAG 2: Zero call center staffing or cost model
A POC with 7,500 users and 5-10 fleets will generate calls. How many agents? What shifts? Language coverage? Outsourced or in-house? Training time? Budget? This is not a minor detail — call center failure is one of the listed pause criteria, but there's no plan to prevent that failure.

### 🚩 RED FLAG 3: Unbanked citizens are functionally excluded
30%+ of Thai adults are unbanked or underbanked. The pitch is card-first (even if "not card-only" in philosophy). A citizen commitment that only serves 70% of citizens is not a genuine commitment. Before any POC expands, there must be a concrete plan for PromptPay and direct debit.

### 🚩 RED FLAG 4: Accessibility for disabled and elderly is entirely absent
WCAG compliance, screen reader support, IVR alternatives, SMS-based notifications — none of this is mentioned. The pitch's user journey assumes a young, sighted, digitally literate user with a smartphone and a bank card. Real public service cannot make this assumption.

### 🚩 RED FLAG 5: No SOPs for the real-life events that cause the most citizen pain
Card expiry, vehicle sale, death of account holder, stolen tag, system outage — these are the events that generate calls, complaints, media attention, and political pressure. The pitch has zero operational response for any of them. A Citizen Journey should show what happens when things go wrong, not just when they go right.

### 🚩 RED FLAG 6: Migrant worker language gap
Burmese, Khmer, Lao speakers are significant users of Thai toll roads. The pitch supports Thai, English, Chinese, and Japanese. The absence of support for Thailand's neighboring-country migrant workers is a real omission — and one that would generate complaints that escalate.

### 🚩 RED FLAG 7: Timeline underestimates government procurement by 8-12 weeks
The 22-30 week timeline is achievable in a private sector POC. In a government context with procurement laws, BOT sandbox evaluation, and inter-agency coordination, 34-44 weeks is more realistic. Promising a Minister a 100-day milestone that relies on procurement timelines not yet defined is setting up a public failure.

### 🚩 RED FLAG 8: No failure testing plan
Stop/pause criteria without a plan to test them operationally means you won't know the criteria are working until real users are harmed. The first reconciliation breakage will be discovered by a citizen's phone call, not by an automated alert — because no one simulated it.

---

## Final Assessment

The M-Pass Postpaid pitch is a **well-structured, thoughtful policy and technology proposal** written by people who understand payment architecture, legal gates, and international benchmarking. It deserves credit for:
- The 7 Citizen Commitments (even if they need operational backing)
- The risk controls and stop/pause criteria
- The 8-layer reconciliation model
- The clear scope boundary (POC, not national rollout)

**However, the operational layer is dangerously thin.** The operations and citizen experience team joins the project at Discovery, not at pitch time. The project needs:

1. An **operational workstream** alongside the legal and payment workstreams in Discovery
2. A **call center staffing and cost model** before the Controlled POC gate
3. An **accessibility and inclusion plan** covering unbanked, elderly, rural, disabled, and migrant users
4. **SOPs for all lifecycle events** (not just the happy path)
5. A **toll data access plan** that honestly addresses the Easy Pass integration question
6. **Revised timeline** that accounts for government procurement realities
7. **Operational failure testing** built into the POC preparation phase

**Recommendation to the Minister: Approve the Discovery and Payment Sandbox with the condition that the Operations & Citizen Experience workstream is fully funded alongside it, and that the Controlled POC gate requires a completed operations readiness review — not just payment and legal gates.**