ZUSahabat Internal Operation Portal

Full Master Development Prompt

Build a professional internal web-based ZUSahabat Operation Portal for AIM Solutions Sdn Bhd.

This is an internal operations management system, not a public/customer-facing application.

The main objective is to replace scattered Excel/Google Sheets/manual tracking with one central operational database and workflow system where the Operation Team can register, process, verify, monitor and report ZUSahabat merchants from initial application until active operations.

⸻

1. CORE OBJECTIVE

The system must allow the Operation Team to manage the complete ZUSahabat lifecycle:

Registration → Location Screening → Document Collection → Verification → Onboarding → Merchant Activation → Sales → Settlement → Fund Allocation → Restock → Stock → Repayment → Issues → Finance Reporting → Monthly Closing

Every record must be connected using a unique:

Merchant ID / ZUSahabat ID

The system must avoid disconnected Excel files.

The principle is:

Excel/CSV = Data Input
Portal = Central Database + Workflow + Tracker + Dashboard + Reporting

⸻

2. IMPORTANT SYSTEM PRINCIPLES

Build the system so that it is:

* Internal-use only
* Multi-user
* Role-based
* Fully auditable
* Responsive
* Easy for non-technical Operation Team members
* Professional and clean
* Able to import/export Excel/CSV
* Able to support future API integration
* Able to track who performed every action
* Able to prevent unauthorised approval
* Able to maintain permanent audit history

Do NOT over-engineer the MVP.

There is currently:

* No ZUS POS API
* No ZUS ordering API
* No bank API

Therefore, the MVP should support manual Excel/CSV upload and manual data entry.

However, the architecture must be API-ready so future integrations can be added without rebuilding the entire system.

⸻

3. USER ACCESS & ROLE MANAGEMENT

The system must use individual user accounts.

Do NOT use shared accounts.

Every user must have:

* Name
* Company email
* Role
* Access level
* Active/inactive status
* Last login
* Created date

Main Users

Syafiqah

Email:

fatin.syafiqah@asgb.com.my

Access:

FULL ACCESS

Syafiqah can:

* View all modules
* Create records
* Edit records
* Upload documents
* Assign tasks
* Execute operational tasks
* Verify documents
* Approve/reject
* Manage merchants
* Manage onboarding
* Manage sales
* Manage settlement
* Manage fund allocation
* Manage restock
* Manage stock
* Manage repayment
* Manage issues
* Generate reports
* Verify Finance reports
* Lock operational/financial records
* Review audit logs
* Reassign PIC
* Perform corrections/adjustments with audit trail

⸻

Asyraff

Email:

asyraaf@asgb.com.my

Access:

FULL ACCESS

Asyraff has the same operational access as Syafiqah:

* View all modules
* Create records
* Edit records
* Upload documents
* Assign tasks
* Execute operational tasks
* Verify documents
* Approve/reject
* Manage merchants
* Manage onboarding
* Manage sales
* Manage settlement
* Manage fund allocation
* Manage restock
* Manage stock
* Manage repayment
* Manage issues
* Generate reports
* Verify Finance reports
* Lock operational/financial records
* Review audit logs
* Reassign PIC
* Perform corrections/adjustments with audit trail

⸻

Siti

Email:

siti@asgb.com.my

Access:

MANAGEMENT – FULL ACCESS

Management must have full visibility and access across the portal.

⸻

Ng Zhiyan

Email:

ngzhiyan@asgb.com.my

Access:

MANAGEMENT – FULL ACCESS

Management must have full visibility and access across the portal.

⸻

Other Operation Team

Each person must use their own company email.

Access:

Operational Execution Access

They can:

* View assigned merchants
* View assigned tasks
* Update assigned tasks
* Upload documents
* Upload Excel/CSV
* Enter operational data
* Create issues
* Update issue status
* Add remarks
* Submit records for verification
* Manage assigned operational activities

They CANNOT:

* Final-approve their own work
* Verify their own submitted documents
* Override verified financial records
* Lock financial records
* Delete audit history
* Permanently delete important operational records

⸻

Finance Team

Each Finance user must have their own company email.

Access:

Finance & Reporting Access

Finance can:

* View settlement
* View bank allocation
* View daily Finance reports
* View monthly reports
* View merchant financial records
* Review settlement differences
* Download reports
* Update Finance-specific fields where authorised

Finance should not automatically have access to operational approval functions unless explicitly assigned.

⸻

4. AUDIT TRAIL

This is critical.

The system must track:

WHO DID WHAT.

Every important action must record:

* User name
* User email
* Date
* Time
* Action
* Module
* Merchant ID
* Previous value/status
* New value/status
* Remarks/reason

Example:

Intern uploads SSM
→ User: Intern Name
→ Email: intern@asgb.com.my
→ Action: Uploaded SSM
→ Date/Time recorded

Then:

Asyraff rejects SSM
→ Action: Rejected
→ Reason: Document expired

Then:

Intern resubmits
→ Action: Resubmitted

Then:

Syafiqah verifies
→ Action: Verified

Audit logs must be permanent.

Users must not be able to delete audit history.

⸻

5. MASTER MERCHANT DATABASE

Every applicant must have a unique:

Merchant ID / ZUSahabat ID

This becomes the central identifier.

All modules must connect to this ID.

Example:

Merchant ID
↓
Registration
↓
Location Approval
↓
Documents
↓
Onboarding
↓
Activation
↓
Sales
↓
Settlement
↓
Fund Allocation
↓
Restock
↓
Stock
↓
Repayment
↓
Issues
↓
Reports

Do not create disconnected records.

⸻

6. MAIN NAVIGATION

Create the following main modules:

1. Dashboard
2. Registration
3. Location Screening
4. Documents
5. Onboarding
6. Merchants
7. Sales
8. Settlement
9. Fund Allocation
10. Restock
11. Stock
12. Repayment
13. Issues
14. Reports
15. Users & Roles
16. Audit Log

⸻

7. REGISTRATION MODULE

This is the first stage.

Applicant submits the initial ZUSahabat registration form.

Store:

* Application ID
* Merchant ID
* Applicant name
* IC/company details
* Contact number
* Email
* AIM branch
* Proposed ZUS location
* Address
* State
* District
* Application date
* Registration status
* Assigned PIC
* PIC email
* Remarks

Initial status:

New Application

Then:

Under Initial Review

Then:

Ready for Location Screening

⸻

8. LOCATION SCREENING

Location screening must happen BEFORE full document collection.

Flow:

Applicant Registration

↓

Operation Initial Review

↓

Submit Proposed Location to ZUS

↓

Waiting for ZUS Decision

↓

If Approved

Proceed to applicant confirmation and full document collection.

If Rejected

Record:

* Rejection date
* Rejection reason
* ZUS remarks

Then allow:

New Location Submission

The merchant must not proceed to full onboarding until the location is approved.

Statuses:

* Pending Review
* Submitted to ZUS
* Pending ZUS Decision
* Approved
* Rejected
* Resubmission Required

Track:

* Submitted by
* Submitted date
* ZUS decision date
* Decision by
* Remarks

⸻

9. DOCUMENT MANAGEMENT

Once location is approved, the system should activate the full document checklist.

Documents may include:

* Application Form
* SSM
* Typhoid Certificate
* Food Handling Certificate
* 12-Month Repayment Record
* Signed AIM Application/Supporting Form
* Other Required Documents
* Fasspay Form
* Heydoc Documents
* Allianz Insurance Documents
* Agreement / Letter of Offer
* Payment Proof
* Other required supporting documents

Each document must have:

* Document type
* Merchant ID
* File
* Uploaded by
* Uploaded date
* Status
* Verified by
* Verification date
* Rejection reason
* Remarks
* Version

Statuses:

Missing

→

Submitted

→

Under Verification

→

Verified

OR

Rejected / Resubmission Required

⸻

10. DOCUMENT VERIFICATION

Other Operation Team members can collect/upload documents.

Syafiqah and Asyraff can verify.

Verification buttons:

* Verify
* Reject
* Request Resubmission

If rejected:

Mandatory rejection reason.

Example:

SSM rejected – document expired.

System sends notification to assigned PIC.

Once all mandatory documents are verified:

Document Status = Complete

Then merchant can proceed to onboarding.

⸻

11. ONBOARDING MODULE

After document completion, create onboarding workflow.

Track:

Agreement

* Agreement status
* Agreement date
* Signed date
* File

Payment

* Package amount
* Payment amount
* Payment date
* Payment proof
* Payment status

Fasspay

* Fasspay registration status
* Form
* Submission date
* Terminal status
* Bank settlement details

Heydoc

* Registration status
* Verification status
* Required documents
* Completion date

Allianz

* Insurance status
* Policy/document
* Completion date

Training

* Training date
* Training status
* Attendance
* Trainer
* Remarks

Starter Kit

* Starter kit status
* Dispatch date
* Tracking number
* Received date
* Received by

Activation

* Activation date
* ZUS branch
* Merchant status

Final status:

ACTIVE

⸻

12. MERCHANT MASTER PROFILE

Each merchant should have one profile page.

Display:

* Merchant ID
* Merchant Name
* Contact
* Email
* AIM Branch
* ZUS Branch
* Location
* Registration Date
* Location Approval
* Document Status
* Onboarding Status
* Activation Date
* Current Status
* Assigned PIC
* PIC Email
* Sales
* Settlement
* Fund Allocation
* Restock Balance
* Stock
* Repayment
* Issues

Use tabs:

Overview | Documents | Onboarding | Sales | Settlement | Fund | Restock | Stock | Repayment | Issues | Audit

⸻

13. SALES MODULE

Because ZUS POS currently has no API:

Sales data must initially be uploaded manually.

Support:

Excel / CSV Upload

Required fields:

* Sales date
* Merchant ID
* Merchant name
* ZUS branch
* Sales amount
* Number of cups/items
* POS reference
* Uploaded by
* Upload date

The system should validate:

* Merchant ID exists
* Date format
* Duplicate records
* Missing values
* Invalid amounts

Do not allow duplicate sales records.

⸻

14. DAILY SETTLEMENT

Settlement must be handled daily.

Every day the system should create a:

Daily Settlement Batch

Fields:

* Settlement date
* Merchant ID
* Merchant name
* POS sales
* Expected settlement
* Allocation percentage
* Expected amount
* Destination bank account
* Actual amount received
* Bank transaction/reference
* Difference
* Settlement status
* Remarks

Statuses:

* Matched
* Partial
* Unmatched
* Missing
* Adjustment Required

Main objective:

Identify whose money is this.

Every bank receipt should be traceable to:

Bank Receipt → Merchant → Sales → Allocation

If money cannot be matched:

Unmatched / Investigation Required

⸻

15. DAILY FINANCE REPORT

A daily report must be prepared for Finance.

Dashboard should show:

Today’s Finance Report

* Not Prepared
* Draft
* Verified
* Sent to Finance

Daily report should include:

* Total POS Sales
* Expected Settlement
* Actual Bank Receipts
* Difference
* Merchant breakdown
* Bank account breakdown
* Unmatched amount
* Adjustments
* Remarks

Process:

Draft

↓

Syafiqah/Asyraff Verify

↓

Verified

↓

Send to Finance

↓

Sent to Finance

Record:

* Report ID
* Report date
* Prepared by
* Verified by
* Sent to Finance date/time
* Status

No business day should silently skip a Finance report.

⸻

16. FUND ALLOCATION

Support the existing:

40:20 allocation structure

However, DO NOT hard-code the percentage.

Make allocation configurable.

For each merchant:

* Sales
* Allocation %
* Allocation amount
* Destination bank account
* Allocation date
* Status

Example:

Sales = RM5,000

40% = RM2,000

20% = RM1,000

Store exactly where the money is allocated.

The system must maintain a merchant-level running balance.

⸻

17. RESTOCK FUND TRACKING

The portal must answer:

Which merchant’s money is ready for restock?

For every merchant:

Opening Restock Balance

New Funds Available

−

Restock Amount Used

=

Available Restock Balance

Example:

Allocated = RM1,500

Restock used = RM900

Available = RM600

Status:

Ready for Restock

⸻

18. RESTOCK STATUS

Use:

* Not Ready
* Ready for Restock
* Restock Requested
* Order Submitted
* Awaiting Delivery
* Received
* Completed

Workflow:

Funds Available

↓

Ready for Restock

↓

Operation Creates Order

↓

Order Submitted to ZUS

↓

Awaiting Delivery

↓

Stock Received

↓

Verify Quantity

↓

Deduct Restock Balance

↓

Update Stock

↓

Restock Completed

⸻

19. RESTOCK ORDER

Because ZUS ordering system currently has no API:

Support:

* Manual entry
* Excel/CSV upload

Fields:

* Merchant ID
* Order date
* Order number
* Item
* Quantity
* Unit price
* Total amount
* Funding source
* Restock balance used
* Order status
* Expected delivery
* Actual delivery
* Received quantity
* Remarks

System must prevent:

Restock amount > Available Restock Balance

⸻

20. STOCK MODULE

Order and Stock must be separate.

Order

Tracks:

What was ordered?

Stock

Tracks:

What is physically available?

Stock formula:

Opening Stock + Stock Received – Stock Used = Current Stock

Track:

* Merchant
* Item
* Opening quantity
* Received quantity
* Used quantity
* Current quantity
* Minimum stock level
* Reorder status

If:

Current Stock < Minimum Stock

show:

LOW STOCK ALERT

⸻

21. REPAYMENT MODULE

Current package:

RM16,200

Repayment:

RM675/month × 24 months

Track:

* Merchant ID
* Package amount
* Monthly expected repayment
* Repayment period
* Payment received
* Outstanding amount
* Payment date
* Payment reference
* Status

Statuses:

* Paid
* Partial
* Outstanding
* Overdue

Dashboard should show merchants with outstanding/overdue repayments.

⸻

22. ISSUE MANAGEMENT

Every issue must have:

* Issue ID
* Merchant ID
* Category
* Description
* Assigned PIC
* PIC email
* Date raised
* Due date
* Priority
* Status
* Action taken
* Resolution
* Resolved date
* Verified by

Workflow:

Open

↓

Assigned

↓

In Progress

↓

Resolved

↓

Verified

↓

Closed

Syafiqah/Asyraff can verify and close issues.

⸻

23. TASK MANAGEMENT

Every operational task must have:

* Task ID
* Merchant ID
* Task
* Assigned PIC
* PIC email
* Assigned date
* Due date
* Status
* Completed date
* Completed by
* Verification status
* Verified by
* Remarks

Statuses:

* Not Started
* In Progress
* Submitted
* Pending Verification
* Completed
* Rejected
* Overdue

Important:

Executor ≠ Verifier

unless the user is Syafiqah or Asyraff.

⸻

24. EMAIL NOTIFICATIONS

System should send email notifications for:

* New task assigned
* Task reassigned
* Document submitted
* Document rejected
* Document requires resubmission
* Verification requested
* Task overdue
* Location approved
* Location rejected
* Merchant ready for onboarding
* Low stock
* Restock ready
* Settlement mismatch
* Unmatched bank transaction
* Finance report reminder
* Finance report sent
* Issue assigned
* Issue overdue

Example:

New Task Assigned

Subject: New ZUSahabat Task Assigned

Merchant: ZS-00123
Task: Verify SSM
Assigned To: Asyraff
Due Date: 14 Nov 2026

Please login to the ZUSahabat Operation Portal to complete the task.

⸻

25. DASHBOARD

Dashboard should provide a real-time operational overview.

Registration

* Total applications
* New
* Under Review
* Location Pending
* Location Approved
* Location Rejected

Documents

* Pending
* Under Verification
* Complete
* Rejected

Onboarding

* Pending
* In Progress
* Ready for Activation
* Active

Merchants

* Total
* Active
* Inactive
* Suspended

Sales

* Today’s Sales
* Monthly Sales
* Sales by Merchant

Settlement

* Matched
* Partial
* Unmatched
* Missing
* Total Difference

Fund Allocation

* Total Allocated
* Available
* Used

Restock

* Ready for Restock
* Restock Requested
* Awaiting Delivery

Stock

* Normal
* Low Stock
* Out of Stock

Repayment

* Paid
* Outstanding
* Overdue

Issues

* Open
* In Progress
* Overdue
* Closed

Finance

Show:

Today’s Finance Report

🟢 Sent

🟡 Draft

🔴 Not Prepared

⸻

26. MANAGEMENT DASHBOARD

Management users should have full visibility.

Show high-level KPIs:

* Total Applications
* Approval Rate
* Active Merchants
* Total Sales
* Settlement Accuracy
* Unmatched Funds
* Restock Funds Available
* Low Stock Merchants
* Outstanding Repayment
* Overdue Issues
* Finance Report Status

Allow filtering:

* Date
* State
* AIM Branch
* ZUS Branch
* PIC
* Merchant Status

⸻

27. MONTHLY CLOSING

At month-end:

Operation Team must complete:

* Sales upload
* Settlement reconciliation
* Bank matching
* Fund allocation
* Restock records
* Stock records
* Repayment records
* Outstanding issues

Then:

Syafiqah / Asyraff Verify

↓

Month Locked

Once locked:

Normal Operation Team users cannot edit financial records.

⸻

28. ADJUSTMENT PROCESS

If a locked record needs correction:

Create:

Adjustment Request

Fields:

* Original value
* Correct value
* Reason
* Requested by
* Requested date
* Approved by
* Approval date
* Remarks

Never overwrite financial history silently.

⸻

29. EXCEL / CSV IMPORT

Support Excel/CSV upload for:

* Sales
* Settlement
* Orders
* Stock
* Repayment
* Merchant data

Upload process:

Upload File

↓

Validate

↓

Show Errors

↓

Preview

↓

Confirm Import

↓

Import

↓

Create Audit Log

Display:

* Total rows
* Successful rows
* Failed rows
* Duplicate rows
* Invalid rows
* Error reason

Allow downloadable error report.

⸻

30. SEARCH & FILTER

Global search should support:

* Merchant ID
* Merchant name
* Phone
* Email
* AIM Branch
* ZUS Branch
* Location
* State
* PIC
* Status

Date filters:

* Today
* This Week
* This Month
* Custom Date Range

Module-specific filters should also be available.

⸻

31. REPORTING

Create:

Registration Report

Location Screening Report

Document Status Report

Onboarding Report

Merchant Report

Sales Report

Settlement Report

Fund Allocation Report

Restock Report

Stock Report

Repayment Report

Issue Report

Daily Finance Report

Monthly Finance Report

Audit Report

Export:

Excel / CSV

PDF where appropriate.

⸻

32. DATA VALIDATION

The system must validate:

* Duplicate Merchant ID
* Duplicate sales
* Duplicate settlement
* Invalid merchant ID
* Missing mandatory fields
* Invalid dates
* Invalid amounts
* Negative values where not allowed
* Restock amount exceeding available balance
* Missing required documents
* Duplicate uploads

⸻

33. SECURITY

Implement:

* Individual login
* Role-based permissions
* Secure password/session management
* Email-based user identification
* Access control
* Audit trail
* No audit deletion
* Financial record locking
* Approval controls
* File upload validation
* Secure database
* Backup strategy

⸻

34. RESPONSIVE DESIGN

The portal must work properly on:

* Desktop
* Laptop
* Tablet
* Mobile

Primary users will use desktop/laptop, but mobile responsiveness is required.

Use clean business UI.

Avoid excessive decoration.

Use:

* Dashboard cards
* Tables
* Filters
* Search
* Status badges
* Tabs
* Side navigation
* Modal forms
* Confirmation dialogs
* Clear action buttons

⸻

35. STATUS COLOURS / VISUAL LANGUAGE

Use clear visual status indicators.

Examples:

* Green = Completed / Approved / Active
* Yellow = Pending / In Progress
* Red = Rejected / Overdue / Critical
* Blue = Submitted / Under Review
* Grey = Draft / Inactive

Keep the design professional and suitable for corporate internal use.

⸻

36. DATABASE STRUCTURE

Design a relational database.

Suggested core tables:

users

* id
* name
* email
* role
* access_level
* status
* created_at

merchants

* merchant_id
* name
* contact
* email
* branch
* location
* status
* assigned_pic
* assigned_pic_email
* created_at

applications

location_screening

documents

document_verifications

onboarding

tasks

sales

settlements

bank_transactions

fund_allocations

restock_funds

restock_orders

stock

repayments

issues

finance_reports

monthly_closing

adjustment_requests

audit_logs

⸻

37. PIC TRACKING

Do not only store one merchant PIC.

Every task must have:

PIC Name + PIC Email

Example:

Merchant:

ZS001

Task 1:

Collect SSM
PIC: Intern A
Email: internA@asgb.com.my

Task 2:

Verify SSM
PIC: Asyraff
Email: asyraaf@asgb.com.my

Task 3:

Submit to Fasspay
PIC: Staff B
Email: staffB@asgb.com.my

This allows management to identify exactly:

Who was responsible for what.

⸻

38. WORKFLOW CONTROL

The system must prevent users from skipping required stages.

Example:

Do not allow:

Location Rejected → Onboarding

Do not allow:

Documents Incomplete → Activation

Do not allow:

Restock > Available Fund

Do not allow:

Unverified Settlement → Month Locked

Do not allow:

User to approve their own submitted document/task, except authorised full-access users Syafiqah and Asyraff where permitted.

⸻

39. CURRENT ZUSAHABAT END-TO-END WORKFLOW

Implement this exact operational flow:

STAGE 1

Applicant Registration

↓

STAGE 2

Operation Initial Review

↓

STAGE 3

Submit Location to ZUS

↓

STAGE 4

Wait for ZUS Location Decision

↓

IF REJECTED

Record reason

↓

New Location

↓

Resubmit to ZUS

IF APPROVED

↓

STAGE 5

Contact Applicant

↓

STAGE 6

Collect Full Documents

↓

STAGE 7

Upload Documents

↓

STAGE 8

Syafiqah / Asyraff Verification

↓

IF REJECTED

Resubmission

↓

IF COMPLETE

↓

STAGE 9

Onboarding

Agreement
Payment
Fasspay
Heydoc
Allianz
Training
Starter Kit

↓

STAGE 10

Activation

↓

ACTIVE MERCHANT

↓

STAGE 11

Daily Operations

Sales
Settlement
Bank Matching
Fund Allocation
Restock
Orders
Stock
Repayment
Issues

↓

STAGE 12

Daily Finance Reporting

↓

STAGE 13

Monthly Closing

↓

STAGE 14

Management Reporting

⸻

40. IMPORTANT BUSINESS QUESTION THE SYSTEM MUST ANSWER

At any point, management should be able to answer:

Registration

“Which applicants are currently pending?”

Location

“Which locations are waiting for ZUS approval?”

Documents

“Whose documents are incomplete?”

Onboarding

“Who is ready to activate?”

Tasks

“Who is responsible for this task?”

Sales

“How much did each merchant sell?”

Settlement

“Which sales have been settled?”

Bank

“Whose money is this?”

Fund

“How much money belongs to each merchant?”

Restock

“Which merchant has enough money to restock?”

Stock

“Which merchant is running low?”

Repayment

“Who has outstanding repayment?”

Issues

“What issue is still unresolved and who owns it?”

Finance

“Has today’s report been sent to Finance?”

Audit

“Who changed this record and when?”

⸻

41. MVP PRIORITY

Build the MVP around these modules first:

1. Login & User Management
2. Dashboard
3. Registration
4. Location Screening
5. Documents
6. Onboarding
7. Merchant Master
8. Tasks & PIC
9. Sales Upload
10. Daily Settlement
11. Fund Allocation
12. Restock
13. Stock
14. Repayment
15. Issues
16. Finance Reports
17. Audit Log
18. Excel/CSV Import & Export

Do not build POS API, ZUS Order API or Bank API in MVP.

But structure the backend so these can be added later.

⸻

42. FUTURE API READINESS

Create integration-ready architecture for future:

ZUS POS API

Automatic sales retrieval.

ZUS Order API

Automatic order submission/status.

Bank API

Automatic bank transaction retrieval and matching.

When APIs become available, they should replace manual upload without redesigning the entire database.

⸻

43. IMPORTANT UX REQUIREMENT

The system must be usable by a new staff member without needing to ask:

“What do I do next?”

Every merchant page should clearly display:

Current Stage

Current Status

Next Action

Assigned PIC

Due Date

Pending Documents

Pending Verification

Outstanding Issues

Example:

Merchant: ZS001

Status:

🟢 Location Approved

Current Stage:

Document Collection

Next Action:

Upload Typhoid Certificate

PIC:

Staff A

Due:

14 Nov 2026

⸻

44. FINAL SYSTEM OBJECTIVE

The completed system should become the single source of truth for ZUSahabat Operations.

It should eliminate dependency on multiple disconnected Excel sheets.

The portal must provide:

Visibility + Accountability + Verification + Financial Tracking + Operational Control + Reporting

The most important principle is:

Every merchant has one master record. Every task has an owner. Every financial transaction has an owner. Every approval has a verifier. Every important action has an audit trail.

Build the system with a clean, scalable architecture so the MVP can later evolve into a fully integrated ZUSahabat Operations Platform.