SPH Media WhatsApp Customer Engagement Platform

Technical Proposal

1. Executive Summary

SPH Media is establishing WhatsApp as a formal, AI-assisted customer communication channel across its portfolio of titles — including The Straits Times, Lianhe Zaobao, The Business Times, magazines, and student publications. Phase 1 targets AI-assisted inbound support and outbound transactional notifications. Phase 2 extends into marketing, lifecycle, and retention campaigns via MoEngage.

QUICKSALES.AI presents a purpose-built WhatsApp Orchestration Platform that sits between Meta's WhatsApp Cloud API and SPH Media's existing enterprise systems. ServiceNow CSM remains the agent workspace. The Commerce backend executes transactions. OneTrust governs consent. MoEngage orchestrates Phase 2 marketing.

QUICKSALES.AI proposes two commercial options tailored to SPH Media's pilot ambitions and budget positioning against the Singapore market:

Both options target measurable pilot outcomes: 50%+ AI resolution, 80%+ CSAT, and 30%+ chat channel share within three months of go-live.

Commercial pricing: Full quotation with implementation fees, milestones, add-ons, and ongoing costs is available in the Pricing section. Scope and delivery options are defined in Section 19.

Next step for SPH: Complete Technical Discovery to unlock real Commerce, ServiceNow, OneTrust, SMS, and MoEngage endpoints. See Section 16.1.1 and Appendix F.

Meta WABA assurance: Phase 1 is user-initiated customer support — the lowest-risk WhatsApp use case. See Section 14 for how we prevent number blocking, policy violations, and quality-rating drops.

What SPH Actually Gets (Plain English)

Simple analogy: QUICKSALES.AI delivers a managed cloud service (like Shopify, HubSpot, or MoEngage) — you subscribe, log in, and operate. The technical infrastructure behind the scenes is our responsibility, not SPH's.

QUICKSALES.AI leadership: Pei Han (CEO), Dave (CSO), Eddy (CPO), Andy (CAITO), and Zen (BD Manager) will oversee delivery alongside a dedicated project and engineering team.

What We Will Build (Summary)

This is a component summary only. For the single master diagram showing all actors, systems, flows, and where data lives, see Section 6.0 — Master Solution Diagram.

2. Understanding of SPH Media Requirements

2.1 Strategic Context

SPH Media's initiative is not a simple "add WhatsApp to ServiceNow" project. It is a lifecycle channel strategy spanning support, transactions, consent capture, and (in Phase 2) marketing retention.

Three Non-Negotiable Principles

What the Requirements Say About Data Storage

SPH does not say "store no WhatsApp data anywhere." The requirements are precise about where data lives:

2.2 Phase Overview

2.3 Complete Requirement Inventory

Phase 1 — Platform (Section A)

Phase 1 — AI (Section B)

Phase 1 — Notifications (Section C)

Phase 1 — ServiceNow (Section D)

Phase 1 — Consent (Section E)

Phase 2 — Marketing (Section F)

2.4 SPH Vendor Ecosystem — What We Know vs What Discovery Must Confirm

The RFP names six integration domains. Below is our current understanding of SPH's vendor landscape, what each system does in this architecture, and what we must validate in the discovery workshop before build starts.

Honest positioning: SPH's Commerce/subscription backend is not named in the RFP — it is treated as an internal system with REST APIs. Public sources confirm ServiceNow (implemented with SGITAL) and AWS cloud usage at SPH Media; OneTrust, MoEngage, and Google Workspace are named in the RFP but instance details are unknown until SPH responds to Business Discovery.

Why QUICKSALES.AI Sits in the Middle (Not ServiceNow Native WhatsApp)

ServiceNow offers Conversational Integration with WhatsApp (Twilio) and Cloud API store apps that pipe WhatsApp into Virtual Agent directly. SPH's RFP explicitly requires Commerce event notifications, OneTrust consent, MoEngage Phase 2, PCI redaction before SN sync, and Google KB — capabilities that require a primary orchestration layer:

Technical role: QUICKSALES.AI is the primary bot (isBotMessage: true on outbound). ServiceNow is the secondary system for live agent handoff (action: AGENT) and persistent records (Table API). This matches ServiceNow's documented bot-to-bot pattern (Yokohama VA API).

3. Why a Dedicated WhatsApp Platform (Not ServiceNow Alone)

ServiceNow offers a WhatsApp adapter (Twilio-based and Cloud API native) that pipes messages into Virtual Agent and Agent Workspace. This does not satisfy SPH's RFP for the following evidenced reasons:

ServiceNow's role in our architecture: agent workspace, case management, interaction records, knowledge source (one of two), and live agent handoff via Virtual Agent Bot-to-Bot API.

4. Proposed Solution Overview — What We Will Build

4.1 Platform Name & Positioning

QUICKSALES.AI WhatsApp Orchestration Platform — purpose-built for SPH Media

A fully managed cloud service (hosted in Singapore) comprising 9 platform components, a web-based Admin Portal for SPH operations teams, and 6 integration connectors to SPH's existing systems. SPH does not purchase or host any hardware.

See Section 4.4–4.7 for plain-English explanation of hosting, the three user interfaces, and screen-by-screen Admin Portal design.

4.2 Components We Will Build

Component 1: WhatsApp Gateway & Session Manager

Purpose: Single owner of the SPH Media WABA. Receives all Meta webhooks. Manages ephemeral conversation sessions (routing state only), message queuing, delivery receipts, and read receipts. All message content is written to ServiceNow and not archived in the vendor platform.

Capabilities:
- Meta Cloud API webhook receiver (messages, statuses, template updates)
- Session state machine (NEW → AUTHENTICATED → IN_FLOW → ESCALATED → CLOSED)
- Real-time ServiceNow sync for every inbound/outbound message (A1, D2)
- Escalation routing to ServiceNow AWA queue (agent queue lives in ServiceNow, not vendor)
- If ServiceNow is temporarily unreachable: in-memory retry only (max 15 minutes) — not written to vendor database; message is never considered "stored" until SN confirms receipt
- Multi-title routing (ST, ZB, BT, magazines) based on subscriber profile
- Rate limiting aligned to Meta tier limits

Component 2: AI Virtual Agent Engine

Purpose: Resolve subscriber requests end-to-end without agent involvement.

Capabilities:
- LLM-powered intent classification and entity extraction
- Journey orchestration for 15+ subscriber flows (see Section 9)
- RAG retrieval from ServiceNow KB + Google Sites/Docs/Sheets/Slides
- Multilingual understanding (EN, ZH-CN, ZH-TW, MS, TA)
- Controlled response language (EN or ZH-CN per B5)
- Proactive follow-up scheduling (e.g., 7:30 AM delivery check)
- Confidence scoring with auto-escalation below threshold

Component 3: PCI Redaction & Security Layer

Purpose: Detect, warn, redact sensitive payment data before any downstream system receives it.

Capabilities:
- Real-time PAN/CVV/expiry pattern detection (Luhn validation for cards)
- Customer warning message with secure redirect
- Redacted transcript generation for ServiceNow
- AI handling notes for agent context
- Audit log of redaction events (metadata only, no raw PAN)

Component 4: Authentication Orchestrator

Purpose: Tiered customer verification proportional to action sensitivity.

Authentication tiers:

Component 5: Template Lifecycle Manager

Purpose: End-to-end WhatsApp template governance.

Capabilities:
- Template creation wizard (utility, authentication, marketing categories)
- Submission queue to Meta Business Manager
- Approval status tracking with webhook callbacks
- Version management (draft → submitted → approved → active → deprecated)
- Quality score monitoring dashboard
- A/B variant support for approved templates

Component 6: Notification Event Processor

Purpose: Receive Commerce backend events and dispatch transactional WhatsApp messages.

Event types supported:

Capabilities:
- Event webhook receiver from Commerce
- Subscriber WhatsApp capability check
- Template variable population from Commerce payload
- SMS fallback via configured SMS gateway
- Reply context token embedded in outbound message metadata
- Delivery/read/failure status as aggregated metrics only (counts) — no message content stored

Component 7: Consent Bridge (OneTrust)

Purpose: PDPA-compliant consent governance.

Capabilities:
- Opt-in prompt at conversation close (authenticated subscribers only)
- Opt-out keyword handling (STOP, UNSUBSCRIBE)
- Real-time sync to OneTrust Consent Receipt API
- Marketing frequency cap enforcement
- Admin toggles for consent capture on/off per journey
- Consent status lookup via OneTrust API; optional short-TTL cache (≤ 15 min) for pre-send validation — not a consent master record

Component 8: Analytics & WABA Health Dashboard

Purpose: Operational visibility and ROI reporting.

Dashboard modules:
- Conversation volume (inbound/outbound, by title, by language)
- AI resolution rate vs escalation rate
- CSAT scores and trend
- Notification delivery/read/click-through/conversion
- WABA quality rating, messaging tier, limit utilization
- Number warm-up progress tracker
- Agent handoff volume and first response time
- Consent opt-in rate

Component 9: Admin & Operations Portal (Web Application)

Purpose: The primary interface SPH supervisors, marketing, and IT use to manage the WhatsApp channel — accessed via web browser, no software installation.

Full screen-by-screen specification: See Section 4.6 for wireframes and descriptions of all 8 portal screens.

Capabilities:
- Home dashboard — KPIs, alerts, conversation volume at a glance
- Live conversation monitor — real-time read-only view of active chats (PCI-safe)
- Journey flow editor — drag-and-drop, no-code journey configuration
- Template management — create, preview, submit to Meta, track approval
- Analytics & ROI reports — exportable PDF/Excel for leadership
- WABA health centre — quality rating, warm-up playbook, tier monitoring
- Consent controls — OneTrust sync, opt-in/opt-out management
- Settings — user/role management, business hours, integration health panel

4.3 Integration Connectors (Not Built — Configured)

4.4 Cloud Hosting — No Special Hardware Required

Some architecture diagrams in this proposal show technical components (load balancers, databases, etc.). These are standard cloud services — not hardware SPH purchases or maintains.

What "Hosting" Means for SPH

Hosting Options (Both Are Cloud — No Hardware)

4.5 Three Interfaces — What Each Person Sees

Every stakeholder interacts through a familiar screen. There is no new desktop software to install.

Interface 1 — Subscriber: WhatsApp (Mobile)

Who: Newspaper subscribers, digital readers, parents (student publications)

Experience: Opens WhatsApp → messages SPH's verified business number → receives instant AI replies or speaks to a live agent → gets payment reminders and delivery updates as normal WhatsApp messages.

Example conversation flow:

No app download. No login portal for subscribers. WhatsApp is the customer interface.

Interface 2 — Agent: ServiceNow (Existing Workspace)

Who: SPH customer service agents (same team as today)

Experience: No new system to learn for core agent work. WhatsApp conversations appear in ServiceNow Agent Workspace as a channel — identical to how email or chat cases appear today.

What agents see in ServiceNow:

Key message for SPH leadership: Agent training focus is "WhatsApp is a new channel in ServiceNow" — not a new platform.

Interface 3 — Operations: QUICKSALES.AI Admin Portal (New — We Build This)

Who: CS supervisors, marketing managers, platform administrators

Experience: Log in via web browser (Chrome/Edge/Safari) → modern dashboard with sidebar navigation → manage everything WhatsApp-related without touching code or servers.

Access URL (example): https://admin.sph-media.quicksales.ai

Roles:

4.6 Admin Portal — Screen-by-Screen Guide

This section describes the concrete screens we will design and build. These are the deliverables SPH supervisors and marketing can demo to leadership — not abstract architecture diagrams.

👉 Open the interactive Admin Portal prototype — click each sidebar item to explore all 8 screens below with live UI.

Screen 1: Home Dashboard (Operations Command Centre)

Purpose: One-page morning briefing for CS leadership.

Layout:

Key widgets:

Screen 2: Live Conversation Monitor

Purpose: Supervisor watches active WhatsApp sessions in real time (read-only, PCI-safe). This is a live stream — not a stored message archive. Closed conversations and full history are viewed in ServiceNow.

Layout:

What supervisor sees:

Transcript view (redacted):

Customer: My paper didn't arrive today
AI: I'm sorry to hear that. Please confirm your postal code.
Customer: 238801
AI: Thank you. I can see your subscription for The Straits Times. Would you like a redelivery tomorrow or a credit?
Customer: I want to speak to someone
AI: Connecting you to an agent. Expected wait: 3 minutes.
System: Escalated to ServiceNow — Agent: Sarah Tan

Privacy: Supervisors see masked phone numbers. Card details never appear — shown as [REDACTED_CARD_NUMBER].

Screen 3: Journey Builder (No-Code Flow Editor)

Purpose: Business users configure what the AI says and does — without developers.

Layout:

Example: "Delivery Complaint" journey

Visual editor: Drag-and-drop flowchart (similar to MoEngage journey builder or ServiceNow Flow Designer). Supervisors can adjust wording, add holiday messages, and enable/disable journeys per title (ST, ZB, BT).

Screen 4: Template Manager

Purpose: Create, submit, and track WhatsApp message templates for Meta approval.

Layout:

Template list view:

Create template wizard (4 steps):

1. Choose category — Utility / Authentication / Marketing
2. Write message — with variable placeholders: {{subscriber_name}}, {{amount_due}}, {{due_date}}
3. Preview — see exactly how it renders on WhatsApp (EN and ZH-CN side by side)
4. Submit to Meta — track approval status with email notification when approved/rejected

Screen 5: Analytics & ROI Reports

Purpose: Prove channel value to SPH leadership with exportable reports.

Layout:

Report modules:

Date filters: Today / 7 days / 30 days / custom range. Title filters: All / ST / ZB / BT / Magazines.

Screen 6: WABA Health Centre

Purpose: Prevent WhatsApp number suspension by monitoring Meta quality metrics.

Layout:

Key metrics:

Warm-up playbook (built in): Guided 3-week ramp schedule with daily send limits — supervisor sees checklist and progress bar.

Screen 7: Consent & Marketing Controls

Purpose: PDPA-compliant opt-in/opt-out management synced with OneTrust.

Layout:

Controls:

Screen 8: Settings & Integration Health

Purpose: IT administrator monitors connections — no server access needed.

Layout:

Integrations:

Also on this screen: User management (invite/remove users, assign roles), business hours calendar, holiday schedule, audit log.

4.7 Day-in-the-Life — How Teams Use the Platform

CS Supervisor — Morning Routine (8:30 AM)

1. Opens Admin Portal → Home Dashboard → checks overnight conversation volume and AI resolution rate
2. Reviews WABA Health → confirms quality rating is GREEN
3. Opens Live Monitor → sees 3 escalated chats → assigns priority in ServiceNow
4. Checks Analytics → exports weekly PDF for leadership meeting

Marketing Manager — Campaign Setup (Option B)

1. Opens Template Manager → creates Chinese New Year promo template → submits to Meta
2. Waits for Meta approval (tracked in portal) → status changes to ✅ Approved
3. Opens Consent dashboard → confirms 12,450 opted-in subscribers
4. Triggers campaign via MoEngage → portal shows real-time delivery/read metrics

CS Agent — Handling a WhatsApp Case

1. Works in ServiceNow (not Admin Portal) → new WhatsApp case appears in queue
2. Reads AI handoff summary → continues conversation in reply box
3. Reply automatically delivered to customer's WhatsApp
4. Closes case in ServiceNow → transcript already filed

IT Administrator — Monthly Check

1. Opens Settings → all integrations show 🟢 Connected
2. Reviews audit log for access and configuration changes
3. No server maintenance, patching, or backup tasks — all managed by QUICKSALES.AI

5. User Personas & Stakeholder Model

5.1 External Users (Customers)

Persona 1: Ah Beng — Print Subscriber (Lianhe Zaobao)

Persona 2: Priya — Digital Subscriber (The Straits Times)

Persona 3: Ahmad — Multi-Title Subscriber

Persona 4: Wei Ming — Payment-At-Risk Subscriber

5.2 Internal Users (SPH Staff)

Persona 5: Customer Service Agent (ServiceNow)

Persona 6: CS Supervisor

Persona 7: Marketing Operations (Phase 2)

Persona 8: Platform Administrator (IT)

6. Solution Architecture

6.0 Master Solution Diagram (One View)

This is the single reference diagram for the entire solution. It shows every actor, every system, the five main flows, and where data lives. All other diagrams in this proposal zoom into a part of this picture.

Legend: light blue = people · green = Meta/WhatsApp · Harmony blue = our platform (build) · navy = SPH systems where data persists · dashed blue = Phase 2. Letters A–E on the arrows are the five flows explained below.

How to Read the Master Diagram

Data residency at a glance: the QUICKSALES.AI box processes and routes — it stores no conversations, no subscriber records, no consent. Every 📁 icon marks where customer data actually persists: ServiceNow, Commerce, OneTrust — all SPH systems (Principle 2).

Diagram Index (All 31 Diagrams)

6.1 High-Level Architecture

6.2 Data Flow Architecture

6.3 Hosting & Deployment (How the Platform Runs)

For SPH leadership and business stakeholders: You do not buy servers, install software, or manage infrastructure. QUICKSALES.AI hosts the entire platform in Singapore cloud (AWS or Azure). Your team accesses it through a web browser — the Admin Portal for operations, and ServiceNow for agents. The diagram below is included for SPH IT review only.

6.3.1 What SPH Needs to Provide

6.3.2 Hosting Options (Cloud Only)

6.3.3 Technical Reference (For SPH IT — Optional Reading)

The platform runs on standard cloud infrastructure. SPH does not procure or manage any of these components — they are provisioned and operated by QUICKSALES.AI as part of the hosting fee.

Deployment options:
- Option A (Essential): QUICKSALES.AI-managed cloud (Singapore region), VPN to SPH systems
- Option B (Professional): Dedicated cloud tenant with enhanced isolation and SLA — still fully hosted, still browser access only

Optional add-on: "Dedicated Singapore private cloud hosting" (Section 19.6) means an isolated cloud environment for enhanced data residency — not on-premise hardware.

6.4 Security Architecture

6.5 Data Architecture — What We Store vs What We Don't

This section answers: "If customer data must live in SPH systems, why do you have databases?"

Requirement-to-Architecture Mapping

What Each Database Is For (Not Customer Data)

Message Lifecycle (End to End)

Live Monitor & Analytics — No Message Archive

The Admin Portal Live Conversation Monitor shows active chats via real-time stream (not a stored archive). Historical transcripts are viewed in ServiceNow — where SPH already manages retention and access control.

7. Detailed Requirement Compliance Matrix

Legend: ✅ Included | ⚠️ Partial/Basic | ❌ Not included (available as add-on)

8. Functional Design by Module

8.1 Module A1 — Self-Service & Intelligent Routing

Routing Decision Logic

Offline Message Handling

8.2 Module A3 — PCI Redaction Pipeline

Redaction rules:

8.3 Module B2 — Tiered Authentication

8.4 Module C1/C2 — Notification & Contextual Reply

9. Use Cases & Customer Journeys

This section is cross-checked against Requirements - WhatsApp.pdf (22 requirement IDs A1–F3) and SPH Media WhatsApp Customer Engagement Platform - RFP.pdf (4 reference journeys + PCI control). See Appendix B for full traceability.

9.0 RFP Audit Summary

Audit note: UC-05 through UC-14 are derived from requirement IDs (C1, A1, B4, F1, etc.) — they are not separate RFP journey documents but are required for full compliance. All 4 RFP reference journeys are fully covered in both options.

9.1 RFP Reference Journeys (Mandatory)

9.1.0 Mandatory Conversation Close Pattern (All RFP Journeys)

Per RFP, every resolved conversational journey (Journeys 1–3) must end with this sequence before the session closes:

9.1.1 C1 Transactional Notification Catalogue

Requirements PDF Section C1 mandates these Commerce-triggered outbound types. Each uses an approved Utility WhatsApp template; SMS fallback when subscriber has no valid WhatsApp number (UC-11).

UC-01: Newspaper Delivery Complaint (RFP Journey 1)

UC-02: Vacation Suspension (RFP Journey 2)

UC-03: Payment Update Support (RFP Journey 3)

UC-04: Sensitive Data Redaction (RFP Journey 4)

9.2 Extended Use Cases (Derived from Requirements)

These use cases are not illustrated as separate journeys in the RFP PDF but are required by requirement IDs A1, C1, B4, E1, F1–F3, etc. They complete full compliance beyond the 4 RFP reference flows.

UC-05: Subscription Renewal Reminder Reply

UC-06: Multi-Language Enquiry (Tamil)

UC-07: Live Agent Escalation (Complex Dispute)

UC-08: Offline Message Capture

UC-09: Marketing Opt-In at Close

UC-10: Opt-Out Handling

UC-11: SMS Fallback for Non-WhatsApp Subscriber

UC-12: Phase 2 — Winback Campaign (Professional Only)

UC-13: Address Change Request

UC-14: Digital Access Issue

UC-15: Student Publication Parent Query

9.3 Option A vs Option B — Journey Coverage

Option A delivers all 4 RFP reference journeys + A1 escalation/offline + E consent + C1 sends. Option B adds full C2 contextual flows, Malay/Tamil, Google KB, extended journeys, and Phase 2 marketing.

9.4 Requirement Compliance Scorecard (22 IDs)

RFP journeys: 4/4 covered in both options. Full 22/22 compliance: Option B only. Option A: 16 full + 6 partial = pilot-ready per SPH scope.

10. Process Flows & Sequence Diagrams

10.1 End-to-End Inbound Support Flow

10.2 Outbound Notification Flow

10.3 Live Agent Handoff Flow

10.4 Consent Lifecycle Flow

10.5 Template Lifecycle Flow

10.6 Phase 2 Marketing Campaign Flow

11. Integration Design — Technical Specification

This section is the integration engineering specification — protocols, endpoints, payloads, ServiceNow table mappings, and discovery dependencies. Generic descriptions are replaced with implementable detail.

11.0 End-to-End Integration Topology

11.1 Meta WhatsApp Cloud API

SPH owns the WABA. QUICKSALES.AI registers as Meta Tech Provider / solution partner and configures webhooks on SPH's WABA.

Webhook Subscription (Platform Receives)

Inbound Webhook Payload (Simplified — Meta Cloud API)

{
  "object": "whatsapp_business_account",
  "entry": [{
    "id": "WABA_ID",
    "changes": [{
      "field": "messages",
      "value": {
        "messaging_product": "whatsapp",
        "metadata": { "phone_number_id": "PHONE_NUMBER_ID", "display_phone_number": "65XXXXXXXX" },
        "contacts": [{ "wa_id": "6591234567", "profile": { "name": "Customer" } }],
        "messages": [{
          "from": "6591234567",
          "id": "wamid.HBgLN...",
          "timestamp": "1720412345",
          "type": "text",
          "text": { "body": "I have not received my newspaper today" },
          "context": { "id": "wamid.OUTBOUND_REF", "from": "6598765432" }
        }]
      }
    }]
  }]
}

Processing steps: (1) Verify HMAC signature → (2) PCI redaction on text.body → (3) Resolve context.id for C2 notification reply → (4) Lookup subscriber via Commerce API using from (MSISDN) → (5) Sync redacted message to ServiceNow interaction → (6) AI process → (7) POST /{PHONE_NUMBER_ID}/messages reply.

Outbound Send (Utility Template — Payment Failed, RFP Journey 3)

POST https://graph.facebook.com/v21.0/{PHONE_NUMBER_ID}/messages
{
  "messaging_product": "whatsapp",
  "to": "6591234567",
  "type": "template",
  "template": {
    "name": "payment_failed_v1",
    "language": { "code": "en" },
    "components": [{
      "type": "body",
      "parameters": [
        { "type": "text", "text": "07/07/26" }
      ]
    }]
  }
}

Context token for C2: Platform stores wamid of outbound message as context_token in ephemeral session (Redis TTL) — when customer replies, messages[].context.id links to payment_failed event payload from Commerce.

11.2 ServiceNow CSM — Primary Integration (D1, D2, B3, A1)

Architecture Decision: Primary Bot = QUICKSALES.AI

Per ServiceNow Virtual Agent Bot Integration API (Yokohama+), QUICKSALES.AI is the primary bot. ServiceNow CSM is the secondary system for live agents and persistent records.

SPH IT Configuration Checklist (Week 1–2)

VA Bot-to-Bot — Escalate to Live Agent (RFP Journey 1, UC-07)

POST https://{sph-instance}.service-now.com/api/sn_va_as_service/bot/integration
Authorization: Bearer {oauth_token}
Content-Type: application/json

{
  "requestId": "qs-uuid-001",
  "clientSessionId": "wa-6591234567-20260708",
  "appInboundId": "{SPH_PROVIDER_INBOUND_ID}",
  "emailId": "tan.wei.ming@email.com",
  "action": "AGENT",
  "isBotMessage": false,
  "message": {
    "type": "text",
    "text": "Customer disputes delivery after 3 AI attempts. Needs agent.",
    "displayName": "Customer"
  },
  "history": [
    { "isBotMessage": false, "type": "text", "value": "My paper wasn't delivered", "displayName": "Customer" },
    { "isBotMessage": true, "type": "text", "value": "I can help check delivery...", "displayName": "Bot" }
  ],
  "contextVariables": {
    "requester_session_language": "en",
    "live_agent_only": "true",
    "topic": "{AWA_QUEUE_TOPIC_SYS_ID}"
  },
  "customPayload": {
    "sph_subscriber_id": "SUB-123456",
    "sph_title": "Lianhe Zaobao",
    "sph_intent": "delivery_complaint",
    "pci_redacted": "true"
  }
}

Note: history[] contains redacted messages only (A3). Raw card data never included.

ServiceNow Async Callback (Agent Reply → Platform → WhatsApp)

When agent types in Agent Workspace, SN POSTs to our outbound webhook:

{
  "requestId": "sn-response-uuid",
  "clientSessionId": "wa-6591234567-20260708",
  "message": {
    "type": "text",
    "text": "I've contacted our delivery partner to expedite.",
    "displayName": "Sarah Tan"
  },
  "isBotMessage": true,
  "agent": true
}

Platform maps clientSessionId → WhatsApp to number → sends via Meta Graph API.

Table API — Persist Transcript (D2, B3)

PATCH https://{sph-instance}.service-now.com/api/now/table/interaction/{sys_id}
{
  "work_notes": "[REDACTED] Customer: missed delivery\nAI: verified postal code 238801\nAI: offered redelivery\nCustomer: requests agent",
  "channel": "whatsapp",
  "u_pci_controls_applied": true
}

All messages (inbound, outbound, offline) written to interaction / linked sn_customerservice_case — not to vendor database.

11.3 SPH Commerce Backend — API Contract (Discovery-Dependent)

Critical dependency: Commerce is SPH's proprietary subscription system. Endpoints below are the contract we will finalize in Week 1 discovery against SPH's OpenAPI documentation. Journey mapping is from RFP verbatim.

RFP Journey → Commerce API Mapping

Inbound Webhook — Commerce → Platform (C1)

POST https://api.sph-media.quicksales.ai/v1/webhooks/commerce
X-SPH-Signature: sha256={hmac_of_body}

{
  "event_id": "evt_uuid",
  "event_type": "payment_failed",
  "timestamp": "2026-07-08T09:00:00+08:00",
  "subscriber": {
    "subscriber_id": "SUB-123456",
    "msisdn": "6591234567",
    "email": "tan.wei.ming@email.com",
    "title": "Lianhe Zaobao Digital"
  },
  "payload": {
    "amount": 28.90,
    "currency": "SGD",
    "due_date": "2026-07-07",
    "payment_update_url": "https://sph.sg/updatecc"
  }
}

Platform actions: (1) Idempotency check on event_id → (2) WA capability check on msisdn → (3) Send Meta utility template → (4) Store context_token in ephemeral session → (5) Log outbound record to ServiceNow via Table API → (6) If no WA, SMS fallback (C1).

Outbound Lookup — Platform → Commerce (B2 Auth)

GET /api/v1/subscribers/lookup?msisdn=6591234567
→ { subscriber_id, titles[], delivery_address_masked, auth_tier_required }

POST /api/v1/subscribers/verify
{ "subscriber_id": "SUB-123456", "postal_code": "238801" }
→ { "verified": true, "auth_tier": "T1" }

Data handling: Response used in-memory during session. Not persisted in vendor PostgreSQL (Principle 2).

11.4 OneTrust — Consent Integration (E1, E2, E3)

E1 requirement: "These information would be kept within OneTrust" — platform writes consent; does not store master record.

Opt-In at Conversation Close (E2) — Consent Receipt API

POST https://privacyportal.onetrust.com/request/v1/consentreceipts
Content-Type: application/json

{
  "identifier": "6591234567",
  "identifierType": "Phone",
  "requestInformation": "{JWT_FROM_SPH_COLLECTION_POINT}",
  "purposes": [{
    "Id": "{SPH_WHATSAPP_MARKETING_PURPOSE_GUID}",
    "TransactionType": "CONFIRMED"
  }],
  "interactionDate": "2026-07-08T07:52:00+08:00",
  "dsDataElements": {
    "sph_subscriber_id": "SUB-123456",
    "sph_title": "Lianhe Zaobao",
    "channel": "whatsapp"
  }
}

Pre-Marketing Consent Check (F2, E1)

GET https://app.onetrust.com/api/consent/v2/datasubjects/6591234567/purposes
→ Check {SPH_WHATSAPP_MARKETING_PURPOSE_GUID} status == OPT_IN

Optional short-TTL cache (≤ 15 min) for batch campaign sends — not consent master record.

Opt-Out (E3) — STOP Keyword

{
  "purposes": [{
    "Id": "{SPH_WHATSAPP_MARKETING_PURPOSE_GUID}",
    "TransactionType": "OPT_OUT"
  }],
  "withdrawnDate": "2026-07-08T10:00:00+08:00"
}

Discovery required: SPH OneTrust tenant hostname (prod/UAT), collection point JWT, purpose GUIDs for marketing vs utility.

11.5 Knowledge Integration — ServiceNow KB + Google Workspace (B4)

ServiceNow Knowledge Base

GET /api/now/table/kb_knowledge?sysparm_query=active=true^workflow_state=published^language=en
&sysparm_fields=sys_id,short_description,text,kb_category,meta

Indexed into vector DB (embeddings of article text only). Sync schedule: daily + on-demand re-index from Admin Portal.

Google Workspace (Option B)

Exclusion list: SPH provides internal-only doc IDs to exclude from index (Discovery Q6.5).

11.6 MoEngage — Phase 2 Connected Channel (F1, F2)

Why not MoEngage native WhatsApp BSP connector? MoEngage's native connectors (Exotel, MSG91, etc.) send WhatsApp directly from MoEngage, bypassing our PCI redaction, OneTrust pre-check, and DNC scrub layer. SPH's RFP requires our platform to own WABA orchestration; MoEngage triggers campaigns into our platform.

Integration Pattern: MoEngage Connected App → QUICKSALES.AI

MoEngage Campaign Webhook (Inbound to Platform)

POST https://api.sph-media.quicksales.ai/v1/webhooks/moengage
X-MoEngage-Signature: {hmac}

{
  "campaign_id": "winback_lapsed_30d",
  "template_name": "cny_promo_2026",
  "segment_id": "seg_uuid",
  "recipients": [
    { "subscriber_id": "SUB-123456", "msisdn": "6591234567", "attributes": { "title": "ST", "lapse_days": 30 } }
  ]
}

Platform processing: For each recipient → OneTrust marketing consent check → PDPC DNC scrub → Meta marketing template send → aggregate delivery metrics back to MoEngage.

11.7 SMS Fallback + DNC (C1, F3)

SMS Fallback Interface (Provider TBD — Discovery Section 8)

POST {SMS_PROVIDER_URL}/messages
{
  "to": "+6591234567",
  "from": "SPHMedia",
  "body": "[Action required] Your subscription payment failed. Update at https://sph.sg/updatecc by 07/07/26"
}

Triggered when: Commerce event fires AND Meta GET /{phone_number_id}/contacts returns no WhatsApp capability OR delivery fails after retry.

DNC Registry Scrub (F3)

Before Phase 2 marketing batch:
1. Extract MSISDN list from MoEngage payload
2. Submit to SPH's DNC check service (PDPC registry API or SPH internal scrub — TBD in discovery)
3. Exclude DNC-flagged numbers; audit log scrub result count (metadata only)

11.8 Integration Readiness Matrix

12. Security, PCI & Sensitive Data Controls

12.1 PCI DSS Alignment

While WhatsApp chat is not a card processing channel, SPH's requirement (A3) mandates PCI-aligned handling:

12.2 Data Classification

12.3 Encryption

13. PDPA & Regulatory Compliance

13.1 Personal Data Protection Act (Singapore) Compliance

PDPA Obligation Mapping

Consent Model

Data Processing Agreement (DPA)

We will execute a DPA with SPH Media covering:
- Data processor obligations under PDPA
- Sub-processor disclosure (cloud hosting, SMS gateway)
- Data residency in Singapore
- Right to audit
- Data return/deletion on contract termination
- Breach notification procedures

Do Not Call (DNC) Registry — Phase 2

Requirement F3 compliance.

13.2 Data Residency & Storage Locations

Principle 2 compliance: Customer data resides exclusively in SPH Media systems. The vendor platform is a transient processing layer — it routes, redacts, and orchestrates, then persists conversation records to ServiceNow and discards message content from its own systems.

14. WhatsApp Business Policy Compliance

SPH and QUICKSALES.AI share a common concern: will Meta restrict or block the SPH WhatsApp Business Account (WABA)? This section explains the risk honestly, why Phase 1 support is a policy-safe use case, and the controls we build to protect the number.

14.1 Plain English — Will Meta Block SPH?

14.2 Why Phase 1 Support Is Low Risk

Meta treats messaging differently depending on who started the conversation and what category the message falls under:

Key point for SPH stakeholders: When a subscriber messages SPH for support, Meta expects SPH to reply. That is not spam — it is the intended use of WhatsApp Business API for customer service. Risk increases only when SPH (or a vendor) sends messages the customer did not ask for, uses the wrong template category, or ignores opt-out requests.

14.3 What Meta Can Restrict — and Why

14.4 Platform Enforcement (Before Meta Sees a Message)

QUICKSALES.AI acts as a policy gate between SPH operations and Meta's API. Messages that would violate policy are blocked in software with a clear error to the agent or admin — not sent and then penalised by Meta.

14.5 WABA Warm-Up and Pilot Ramp

New or reactivated numbers must not jump to full volume on day one. Our built-in 21-day warm-up playbook (Admin Portal → WABA Health Centre) guides SPH through a safe ramp:

14.6 If Quality Rating Drops — Escalation Playbook

14.7 Policy Requirement Matrix

Honest caveat: Meta retains final authority over any WABA. No vendor can guarantee zero restrictions. What we guarantee is policy-by-design architecture, pre-send enforcement, continuous quality monitoring, and a documented escalation playbook — so SPH is never surprised and never dependent on hope alone.

15. Analytics, KPIs & Pilot Success Metrics

15.1 Dashboard Modules

Executive Dashboard

• Total conversations (daily/weekly/monthly)
• AI resolution rate trend
• CSAT score trend
• Channel shift (% of digital support on WhatsApp)
• Cost per resolution (AI vs agent)

Operations Dashboard

• Live queue depth and wait times
• Escalation rate by journey type
• Agent handoff volume
• Offline message backlog (from ServiceNow queue metrics)
• First response time (AI and agent)

Notification Dashboard

• Delivery rate (WA and SMS)
• Read rate
• Click-through rate (link clicks)
• Conversion rate (payment updated after notification)
• SMS fallback rate

Compliance Dashboard

• Consent opt-in rate
• Opt-out volume
• Redaction events
• DNC scrub results (Phase 2)
• Template quality scores

WABA Health Dashboard

• Quality rating (Green/Yellow/Red)
• Messaging tier and limit utilization
• Phone number status
• Warm-up progress
• Blocked/flagged alerts

15.2 Pilot Targets (3 Months)

16. Implementation Methodology & Project Plan

16.1 Methodology

We follow an Agile delivery model with 2-week sprints, fortnightly demos to SPH stakeholders, and a 3-month pilot measurement window.

16.1.1 Week 1 — Technical Discovery Workshop (Removes All TBDs)

Before development starts, SPH completes Technical Discovery (included in this package). QUICKSALES.AI runs a structured workshop to convert SPH inputs into signed integration contracts.

Critical inputs SPH must provide (Integration Pack sections)

Until SPH returns the Integration Pack, Section 11 endpoints marked TBD or illustrative remain contract proposals — not production URLs. This is intentional and technically honest.

Post-discovery deliverables (QUICKSALES.AI → SPH)

16.2 Project Timeline — Option B (Professional)

Total duration: ~7 months to pilot go-live (Option B); ~5 months (Option A)

16.3 Sprint Plan Summary — Option A (Essential)

16.4 Sprint Plan Summary — Option B (Professional)

17. Project Team & Governance

17.1 QUICKSALES.AI Leadership Team

QUICKSALES.AI brings a dedicated executive and delivery team with deep expertise in WhatsApp automation, AI-powered customer engagement, and enterprise system integration.

17.2 Proposed Delivery Team Structure

17.3 Governance Model

17.4 SPH Media Responsibilities

18. Competitive Landscape & Vendor Background

This section provides a concise overview of the competing solution vendors who submitted proposals to SPH Media for this engagement, as well as the technology ecosystem partners that form part of SPH's existing or planned stack. Understanding both dimensions helps SPH evaluate total cost of ownership, integration fit, and delivery risk.

18.1 Competing Solution Vendors (RFP Quotes)

The following vendors have submitted commercial proposals for the WhatsApp Customer Engagement Platform. Profiles below are based on publicly available positioning and typical delivery models.

Vendor X — Enterprise Full Suite

Vendor Y — Mid-Range Platform

QUICKSALES.AI — Positioning vs. Competitors

Note: Vendor X and Vendor Y are labelled as submitted in SPH's commercial evaluation. QUICKSALES.AI recommends SPH's procurement team map these labels to named vendors in the internal scorecard. This proposal focuses on capability and value alignment rather than disparagement of any competitor.

18.2 SPH Technology Ecosystem — Integration Summary

Full technical specification: Section 11 (API endpoints, JSON payloads, ServiceNow table mappings, discovery checklist).

Public context: SPH Media uses ServiceNow (with SGITAL) for ITSM and contact centre operations, and AWS for cloud workloads (iTnews, 2024). CSM module usage for customer support is per RFP; instance details confirmed in discovery.

18.3 Vendor Landscape Summary

Key takeaway for SPH: Vendor X optimises for enterprise breadth; Vendor Y optimises for speed and simplicity with integration gaps; QUICKSALES.AI optimises for SPH's specific architecture — ServiceNow-centric agents, Commerce-backed journeys, OneTrust compliance, and AI orchestration.

19. Commercial Proposal — Scope & Delivery Options

Note: This section defines scope and delivery structure. Full commercial pricing is in the Pricing quotation (SGD, exclusive of GST). Final contract value may be adjusted after discovery workshop if scope changes.

19.1 Delivery Options Overview

19.2 Option A — Essential

Scope Summary

Phase 1 pilot-ready platform with 8 priority AI journeys, core integrations, and 3-month hypercare.

Included

Excluded (Available as Add-On)

• Google Workspace knowledge connector
• Malay + Tamil language support
• MoEngage / Phase 2 marketing
• DNC scrubbing
• Full template lifecycle manager
• Full WABA warm-up automation
• Extended journeys beyond 8

Effort Breakdown — Option A

19.3 Option B — Professional

Scope Summary

Full RFP compliance for Phase 1 and Phase 2 foundation. All 15+ journeys, all integrations, all languages, MoEngage marketing, DNC scrubbing.

Included

Effort Breakdown — Option B

19.4 Side-by-Side Comparison

19.5 Payment Milestones (Structure)

Payment amounts will be confirmed in the separate quotation. Milestone structure:

Option A

Option B

19.6 Optional Add-Ons (Scope)

Clarification: Dedicated cloud tenant means an isolated cloud environment for enhanced data residency — not on-premise hardware. Access remains via web browser.

19.7 Ongoing Costs (Post-Implementation — Categories)

Specific monthly figures will be provided in the commercial quotation.

20. Service Level Agreement & Support

20.1 SLA — Pilot Period (Included in Both Options)

20.2 Hypercare (3 Months Post Go-Live)

20.3 Post-Hypercare Support (Optional)

Monthly fees to be quoted separately.

21. Risk Management

22. Assumptions & Dependencies

22.1 Assumptions

1. SPH Media owns the WhatsApp Business Account and Meta Business Manager
2. ServiceNow instance is Zurich release or later with CSM and Agent Workspace licensed
3. Commerce backend exposes REST APIs for subscriber, billing, and delivery operations
4. OneTrust is SPH's system of record for consent; API access will be provisioned
5. SPH provides test environments for ServiceNow, Commerce, and OneTrust within 2 weeks of kickoff
6. SPH CS team provides journey content (prompts, business rules) within sprint timelines
7. Meta template approval timelines (24–72 hours) are outside our control
8. SMS gateway account is provisioned by SPH or jointly
9. All persistent customer data (conversations, subscriber records, consent) remains in SPH systems (ServiceNow, Commerce, OneTrust); vendor platform stores only ephemeral session cache and operational configuration
10. SPH web chat channel remains unchanged

22.2 Dependencies

23. Appendices

Appendix A: Glossary

Appendix B: RFP Requirement Traceability Index

Appendix C: Technology Stack

Note for business readers: The table below is a technical reference for SPH IT. SPH operations teams interact only with the Admin Portal (web browser) and ServiceNow — not these underlying technologies.

Appendix D: Commercial Quotation

Full commercial pricing is provided in the dedicated Pricing quotation document, aligned to the scope below.

Currency: Singapore Dollars (SGD), exclusive of GST. Valid for 90 days from quotation date.

Appendix E: Data Storage & Residency — Requirement Audit

This appendix maps every data-related requirement from Requirements - WhatsApp.pdf and the RFP against our proposed architecture. Use this for SPH Legal, IT, and procurement review.

Three Non-Negotiable Principles

Phase 1 — Data & Storage Requirements (A–F)

What the Vendor Platform May Hold (Non-Customer Data)

Common Misreadings — Clarified

Appendix F: Technical Discovery (SPH Action Required)

To replace all TBD integration placeholders with production endpoints, SPH must complete:

Technical Discovery — included in this package

Return to: proposals@quicksales.ai within 10 business days of contract signing.

QUICKSALES.AI will publish Integration Specification v1.0 and an updated Section 11 within 7 days of receiving completed Sections A + B.

End of Proposal

Document prepared by QUICKSALES.AI for SPH Media Limited. Private & Confidential.
For questions regarding this proposal, please contact: proposals@quicksales.ai