EWA Pilot Plan Template and Expansion Decision Criteria

An EWA pilot plan needs to define, in advance, the objective, employee group, timeline, limit policy, integration data, responsibilities, budget, KPIs, and stop conditions. The reference process has six phases: preparation, design, integration, UAT, controlled operation, and evaluation. At the end of the pilot, a business doesn't just choose "expand" or "don't expand" — it can reach one of four decisions: Go, Adjust, Extend, or Stop. The decision must be based on employee value, HR impact, operational quality, cost, and risk.

> Note: This is a reference implementation framework, not a commitment regarding the timeline or features of the earned wage access service. The schedule, scale, KPI thresholds, legal roles, fee policy, funding source, and settlement flow must be confirmed by Nhan Kiet and the business in the official pilot documentation.

> Glossary: EWA (earned wage access) · pilot (trial rollout) · UAT (user acceptance testing) · RACI (responsibility matrix: Responsible – Accountable – Consulted – Informed) · KPI (key performance indicator) · cutoff (period cutoff point) · go-live (moving into official operation) · project charter (project mandate document) · baseline (reference data) · wave (expansion batch) · Go–Adjust–Extend–Stop (Expand – Adjust – Extend – Stop).

What Is an EWA Pilot?

An EWA pilot is a limited rollout phase meant to validate a set of hypotheses before scaling up. Its scope can be limited by legal entity, plant, employee group, timekeeping system, pay period, headcount, or duration.

A pilot should not be an "uncontrolled trial run." Employees are still making real transactions, pay and account data are still sensitive, and cash flow and payroll still need reconciliation. A pilot therefore needs all the essential controls of a full production environment, just scoped down so the team can learn quickly and limit the impact if something goes wrong.

A Good Pilot Must Answer Five Questions

1. Do employees understand and can they access EWA?

2. Are timesheet, pay, and employment-status data reliable enough?

3. Are transactions processed and reconciled correctly?

4. Does the program generate a signal of HR or benefits value?

5. Are cost, risk, and operational volume appropriate for expansion?

1. When Is a Business Ready to Pilot?

A business shouldn't start a pilot just because a contract has been signed or an app already exists. The minimum entry conditions include:

On Objectives

• a specific business or employee problem that needs solving;

• a measurable hypothesis;

• a sponsor at a sufficiently senior level;

• departments agree on what counts as pilot success and failure.

On Data

• a unified employee ID;

• employment status updated on time;

• timesheets or hours worked have a clear approval status;

• pay period, cutoff, and pay rules are defined;

• EWA transactions can be linked to payroll and payment;

• data quality has been checked against a real sample.

On Operations

• there's a process owner and a support contact point;

• there are processes for unapproved timesheets, wrong accounts, stuck transactions, and complaints;

• there's daily and period-end reconciliation;

• there's an authorized account lock/unlock mechanism;

• there's a plan for handling system or payment disruption.

On Legal and Security

• the contract model and each party's responsibilities have been reviewed;

• the information given to employees is clear;

• the scope of data, purpose of processing, storage, and sharing have been approved;

• access control, authentication, encryption, logging, and incident response are ready;

• all parties know the coordination contact point in case of an incident.

If these conditions aren't met yet, a business should treat this as a preparation phase rather than forcing real transactions in just to "stay on schedule."

2. Write the Pilot Hypothesis Before Choosing KPIs

A good hypothesis has four parts: the target group, the change, the expected outcome, and the measurement conditions.

Sample Structure

> For the eligible employee group at [unit], providing EWA under [policy] over [timeframe] is expected to help achieve [outcome], while maintaining [operational and risk thresholds].

Illustrative Example

> For production workers who have completed probation at Plant A, EWA is expected to increase their sense of control over short-term expenses and reduce manual advance requests, while transactions must still be processed, reconciled, and supported within approved internal targets.

This example doesn't state an assumed improvement percentage. Numeric targets need to be built from the business's own baseline, not copied from marketing material or another customer.

3. Choose a Pilot Scope Small Enough to Control, Large Enough to Learn From

Criteria for Selecting a Unit

• unit leadership is willing to cooperate;

• the timekeeping process is relatively stable;

• the employee group's needs match the objective;

• payroll and HR can supply data on time;

• there's an on-site or remote support team;

• too many systems/policies aren't changing at the same time;

• a suitable comparison group can be formed if impact assessment is needed.

Don't Choose Purely Because It's the "Easiest Unit"

An overly ideal unit can make the pilot look successful without being representative of where it will actually expand. Conversely, choosing the hardest site right from the start can leave the project team unable to tell a product defect apart from an underlying data problem.

A balanced approach is to choose a scope with moderate complexity and clearly document how it differs from the wider business: shift type, pay method, receiving bank, location, tenure, contract type, and timekeeping system.

Scope Description Table

4. The Six-Phase Pilot Roadmap

(For a day-by-day version, see A 90-Day EWA Pilot Plan for Businesses.)

```mermaid
flowchart TD
A["1. Preparation"] --> B["2. Design"]
B --> C["3. Integration"]
C --> D["4. UAT and Drills"]
D --> E["5. Pilot Operation"]
E --> F["6. Evaluation and Decision"]
```

The duration of each phase depends on readiness. A business shouldn't commit to a generic schedule before surveying its data and systems.

5. Phase 1 – Preparation and Charter Approval

Key Activities

1. define the objective and hypothesis;

2. choose the scope and comparison group;

3. set up the steering committee and project team;

4. determine budget and resources;

5. build an initial risk register;

6. collect the baseline;

7. review legal, data, and contract matters;

8. agree on the end-of-pilot decision criteria.

Deliverables

• Project Charter;

• scope description;

• stakeholder list;

• RACI;

• KPI set and baseline;

• risk register;

• communication plan;

• entry/exit criteria for each phase.

Gate Conditions

Don't move into detailed design until a policy approver, a data owner, and a final decision-maker for payroll/reconciliation are all in place.

6. Phase 2 – Policy and Journey Design

Policies to Finalize

• eligible population;

• employment statuses allowed to participate;

• eligible work type or income;

• the formula and cap for the limit;

• number of transactions allowed;

• fee policy and who bears the fee;

• the applicable period/cutoff;

• how to handle resignation, leave, and timesheet adjustments;

• how to handle failed, unresolved, and refunded transactions;

• how transactions flow into payroll and accounting.

Employee Journey

1. receive information;

2. register/activate;

3. verify;

4. view limit;

5. choose an amount;

6. review full details before confirming;

7. authenticate the transaction;

8. receive the status;

9. receive the funds or guidance if there's an error;

10. view history and the related settlement.

Operational Journey

Separate flows need to be designed for HR, the supervisor who approves timesheets, Payroll, Finance, IT, Support, Risk, and the payment partner. A good employee-facing interface cannot make up for an internal process that has no owner.

7. Phase 3 – Data and Integration

(For data and architecture requirements, see Integrating EWA with Timekeeping, Payroll, and ERP and Reconciling EWA Transactions with Payroll and Accounting.)

Minimum Dataset

• employees and employment status;

• legal entity, unit, pay group;

• timesheet/hours worked and approval status;

• pay period, cutoff, and the necessary rules;

• receiving accounts within a secure processing domain;

• EWA transactions;

• payment status;

• payroll/ERP data for reconciliation.

Technical Decisions

• near-real-time API, batch/SFTP file, or another controlled method;

• identity keys and mapping tables;

• data versioning and handling of late-arriving data;

• idempotency and duplicate-file prevention;

• transaction status;

• retry, timeout, and alerting;

• reconciliation and discrepancy reporting;

• access control, logging, and storage.

Data Quality Checks Before UAT

Unprotected real data should not be used in a test environment. Test data needs to be properly simulated or masked.

8. Phase 4 – UAT and Drills

UAT must test both the happy path and the failure cases.

Employee-Scenario Group

• successful activation;

• incorrect or missing identity data;

• changing device, phone number, or receiving account;

• no limit available because the timesheet isn't approved;

• a request that exceeds the limit;

• successful, failed, and in-progress transactions;

• disputing a transaction the employee didn't initiate;

• an employee resigning or transferring units.

Data-Scenario Group

• timesheet corrected after approval;

• an older data version arriving late;

• duplicate or out-of-order files;

• partially corrupted records;

• incorrect employee-ID mapping;

• wrong pay period or cutoff;

• the source data feed going down temporarily.

Payment-Scenario Group

• resending with the same idempotency_key;

• a timeout before or after sending the payment instruction;

• a late, duplicate, or wrongly signed callback;

• an invalid receiving account;

• the partner reporting an unresolved outcome;

• a transaction that succeeds and is later reversed.

Payroll and Accounting-Scenario Group

• posting transactions into the correct period;

• blocking an already-posted transaction;

• totals and individual transactions matching;

• handling adjustments after cutoff;

• discrepancies creating a case with an assigned owner;

• ERP/vouchers being traceable back to the transaction.

Incident Drills

At minimum, drill for:

• employee account takeover;

• a wrong transfer or suspected duplicate payout;

• a widespread timekeeping-sync failure;

• a data-file leak;

• a service disruption close to a pay period;

• the payment provider becoming unresponsive.

Every drill must record who decides to lock a flow, who is notified, what data is preserved, and the criteria for reopening it.

9. Pilot Go-Live Conditions

Mandatory Conditions

• [ ] The scope and eligibility list have been approved.

• [ ] The limit, fee, cutoff, and exception-handling policies are finalized.

• [ ] Business, integration, security, and reconciliation UAT have passed.

• [ ] Critical defects have been fixed and re-tested.

• [ ] The initial data has been reconciled.

• [ ] Support and escalation contacts are ready.

• [ ] Daily reporting and alerting are operating.

• [ ] The rollback or pause plan has been drilled.

• [ ] Employee-facing information has been approved.

• [ ] The authorized person has signed off on go-live.

A critical defect shouldn't be waved through just because the pilot group is small. A small pilot reduces the blast radius, not the responsibility to protect employees and their money.

10. Phase 5 – Controlled Pilot Operation

Early-Period "Hypercare"

In the early period, all parties should monitor at a tighter cadence:

• checking timesheet data and limits;

• tracking failed/unresolved transactions;

• same-day reconciliation;

• quick stand-ups to clear blockers;

• maintaining a single shared issue list;

• transparent notification to affected users;

• recording temporary fixes and root-cause solutions.

There's no need to announce a fixed hypercare duration. The cadence can ease off once data, transactions, and support have stabilized against the approved criteria.

Decision Log

Every policy change during the pilot needs to record:

• the issue;

• supporting data;

• the option chosen;

• the approver;

• the effective date;

• the affected group;

• how it will be measured afterward;

• the rollback option.

If too many variables change at once, a business won't know which change actually produced the result.

11. Sample RACI for an EWA Pilot

Legend: R – Responsible; A – Accountable; C – Consulted; I – Informed.

This is a template. A business needs to adapt it to its real organization and make sure every activity has exactly one clear accountable role.

12. A Balanced Pilot KPI Set

(For the full indicator set, see Which KPIs Measure EWA Effectiveness? and How to Calculate ROI When Implementing EWA.)

Access and Usage KPIs

• eligibility rate;

• information-reach rate;

• activation-start and activation-completion rates;

• rate of visible limits;

• active-user rate;

• transaction frequency and value by cohort.

Experience KPIs

• transaction success rate;

• time to receive funds, by median and percentile;

• drop-off rate at each step;

• tickets per 1,000 transactions;

• response and resolution time;

• satisfaction level and understanding of fees/terms.

HR KPIs

• manual advance requests;

• absenteeism and no-shows;

• turnover by cohort;

• attendance rate of new hires;

• awareness and perceived value of the benefit.

Operational KPIs

• on-time timesheet approval;

• data freshness;

• automation rate;

• automated reconciliation rate;

• data errors by source;

• post-cutoff adjustments;

• time to close discrepancies.

Financial and Risk KPIs

• total cost of ownership;

• cost per eligible employee / active user / transaction;

• unresolved-outcome transactions;

• discrepancy rate and value;

• confirmed fraud;

• false-positive rate;

• security or data incidents;

• access rights and overdue exceptions.

13. Outcome KPIs and Guardrail KPIs

Outcome KPIs show what value the program creates. Guardrail KPIs stop the project team from hitting a target by creating a different risk.

A business shouldn't expand if the business KPIs are met but the guardrail KPIs exceed the acceptable level.

14. How to Set KPI Targets

Step 1: Establish the Baseline

Measure pre-pilot data using the same definitions: turnover, absenteeism, advance requests, payroll tickets, processing time, and cost.

Step 2: Define the Mandatory Minimum

For example: no duplicate payouts, no unresolved critical security defects, unresolved transactions have an assigned owner, and payroll can be reconciled. These are control conditions, not growth targets.

Step 3: Set Improvement Targets

Base these on the baseline, system capability, and scope. Every target needs a data source, a formula, an owner, and a measurement point.

Step 4: Set Alert and Stop Thresholds

An alert threshold triggers an investigation; a stop threshold triggers pausing a flow, or the entire pilot, under proper authority.

Step 5: Approve Before Go-Live

Don't change the end-of-pilot criteria just to fit results that have already happened. If a change has a legitimate reason, it must be recorded in the decision log.

15. Criteria for Stopping or Pausing the Pilot

The plan must define in advance when to stop accepting new transactions, pause one group, or stop the entire program.

Events that can trigger an urgent review:

• suspected widespread duplicate payouts or wrong-recipient transfers;

• incorrect timesheet/pay data making limits unreliable;

• UNKNOWN transactions piling up beyond control capacity;

• a critical security vulnerability that hasn't been contained;

• data leaked or used outside its approved scope;

• payroll cannot be reconciled before period close;

• the funding source or payment partner is disrupted;

• an abnormal spike in complaints;

• fraud controls falsely blocking many legitimate users;

• the project team can no longer support the pilot safely.

Specific numeric thresholds should stay in the internal plan and not be published if doing so could weaken controls.

Pausing Is Different from Ending

Pausing protects users and allows investigation while preserving data, transactions, and evidence. Ending the pilot is a governance decision made after evaluation. The process must clearly state who has the authority to pause, who approves reopening, and how employees are notified.

16. Phase 6 – End-of-Pilot Evaluation

The evaluation should use both quantitative data and qualitative evidence.

Quantitative Data

• KPIs before, during, and at the end of the pilot;

• comparison against the baseline;

• comparison against a comparable group, if available;

• results by cohort, unit, and journey;

• total cost and benefit assumptions;

• incidents, discrepancies, and remaining risk.

Qualitative Data

• interviews with users and non-users;

• feedback from supervisors, HR, Payroll, Finance, and Support;

• reasons for funnel drop-off;

• manual steps that are hard to scale;

• issues not yet visible on the dashboard;

• lessons from incidents and exceptions.

Don't Rush to Causal Conclusions

If turnover falls, seasonality, order volume, pay, bonuses, management, and other policies all need to be considered. If EWA users show higher turnover, it may simply be that a group already under financial pressure carried higher risk to begin with. Reports should use language like "an observed difference/signal" when the design isn't strong enough to establish causation.

17. The Go – Adjust – Extend – Stop Decision Matrix

Suggested Go Conditions

• the primary value objective is met, or has sufficiently strong evidence;

• no unresolved critical defects remain;

• transactions, payroll, and accounting can be reconciled;

• support volume per person/transaction is trending toward being manageable;

• the cost of expanding has been fully calculated;

• employees understand the policy and have a support channel;

• remaining risk has an owner and has been accepted by an authorized person;

• the architecture can handle a larger scale;

• the next unit's differences from the pilot have been assessed.

Meeting the usage KPIs while falling short on security, reconciliation, or transparency to employees is not yet enough for a Go.

18. Phased Expansion Plan (Waves)

A business shouldn't jump from a small pilot straight to company-wide rollout in one step if units, systems, or policies differ significantly.

Wave Design

Each wave should group units with similar characteristics:

• the same timekeeping/payroll system;

• the same legal entity or policy;

• the same shift group and pay calculation method;

• a similar level of HR/supervisor readiness;

• the same support channel;

• a similar level of payment complexity.

Gate Before Each Wave

• data and mapping have been checked;

• the support team has sufficient capacity;

• defects from the prior wave have been resolved;

• reconciliation and dashboards have been extended;

• access rights for the new scope have been reviewed;

• communications have been adapted to the employee group;

• rollback is ready;

• the authorized person has approved.

Monitoring After Each Wave

Don't compare only against the original pilot. Each unit can have a different activation rate, data-error profile, receiving banks, and usage behavior. Compare wave by wave and watch for performance degrading as scale grows.

19. Condensed Project Charter Template

1. Project Name

EWA/earned wage access pilot at [unit].

2. Problem to Solve

Describe the baseline data, the affected group, and the current impact.

3. Objective and Hypothesis

Record the desired outcome and the guardrail KPIs.

4. Scope

Legal entity, unit, employees, systems, pay period, duration, and transaction type.

5. Out of Scope

Employee groups, systems, or features not yet rolled out.

6. Deliverables

Integration, documentation, training, UAT, dashboards, reconciliation, and the end-of-pilot report.

7. RACI

Who is accountable, who is responsible, who is consulted, and who is informed.

8. Risks and Dependencies

Data, payroll, payment, security, legal, resources, and the pay-period calendar.

9. Budget

Vendor cost, integration, staffing, support, security, communications, and contingency.

10. Decision Criteria

Go, Adjust, Extend, Stop, and the authorized approver.

20. Post-Pilot Evaluation Report Template

A. Executive Summary

• which objectives were met/not met;

• the recommended decision;

• material risks;

• resources and conditions going forward.

B. KPI Results

C. Financials

Total cost, substantiated benefits, assumptions, cost of scaling, and sensitivity scenarios.

D. Risk

Incidents, fraud, false positives, discrepancies, personal data, remaining risk, and who accepted it.

E. Lessons Learned

What to keep, fix, or drop; the conditions for applying this to other units.

F. Decision

Go/Adjust/Extend/Stop; scope; budget; the responsible owner; the next review date.

21. Common Mistakes When Piloting EWA

Not Defining Success Before Starting

By the end of the pilot, each department picks whichever metric favors its own point of view.

Choosing Scale Without Representativeness

The headcount is large enough, but it all comes from one shift, one manager, or one system, so it doesn't reflect the wider business.

Not Running Through a Full Payroll Cycle

The app gets evaluated, but reconciliation, settlement, and period-end adjustments are never actually validated.

UAT-ing Only the Happy Path

There's no idea how to handle timeouts, late timesheet corrections, wrong accounts, refunds, or payroll-posting errors.

Measuring a Lot but Having No Baseline

There's a dashboard after rollout, but no way to know what the program actually improved.

Expanding While Operations Is Still Manual

The pilot looks fine because the project team is "babysitting every transaction," but the model can't actually scale.

Constantly Changing Policy

It becomes impossible to tell apart the impact of policy, communications, data, or the product itself.

No End Plan

When it stops, transactions haven't been reconciled, data hasn't been deleted, employees haven't been told, and responsibility is unclear.

22. Protecting Data and Employees During the Pilot

(For the full security framework, see Data Security and Privacy When Implementing EWA and Risk Governance and Fraud Prevention in EWA.)

A pilot still has to follow data-protection and information-security principles. A business needs to limit data to its stated purpose, grant access by role/duty, use safe test data, keep logs, manage vendors, and have an incident-response plan.

In Vietnam, Personal Data Protection Law No. 91/2025/QH15 takes effect on January 1, 2026. The pilot's design needs to be reviewed against each party's role, the type of data involved, the scope of sharing, and employees' rights.

For HR measurement, ISO 30414:2025 provides requirements and recommendations for human-capital reporting. For information-security risk governance, the NIST Cybersecurity Framework 2.0 is a reference framework for organizing governance, identification, protection, detection, response, and recovery activities. These are reference sources; the pilot's criteria still need to be designed around the actual business and the real EWA model.

Conclusion

An EWA pilot is a controlled governance decision, not just a technology trial. A trustworthy pilot needs a hypothesis, a baseline, a representative scope, clear policy, good-enough data, worst-case UAT, guardrail KPIs, and pre-approved stop criteria.

At the end of the pilot, a business needs to choose Go, Adjust, Extend, or Stop based on evidence. If your business wants to build an earned wage access pilot plan that fits your existing timekeeping system, payroll, and workforce, learn more about Earned Wage Access for Businesses to discuss the survey scope and the rollout documentation set.

References

• ISO 30414:2025 – Human capital reporting and disclosure

• NIST Cybersecurity Framework 2.0

• Personal Data Protection Law No. 91/2025/QH15 (Vietnam)

• Decree No. 356/2025/ND-CP Guiding the Personal Data Protection Law (Vietnam)

---

Author: Tran Van Tai — Deputy General Director's Assistant, in charge of development strategy, Nhan Kiet Manpower Supply Co., Ltd.

Consultation on earned wage access solutions for businesses: Hotline 0937.022.655 · Email info@nhankiet.vn · Earned Wage Access for Businesses