RedeemSG

Paper vouchers are manual to distribute, track, collect and reconcile. It is labour intensive and error prone and it runs the risk of theft and fraud.

Based on a 2018 study by Ministry of Finance (MOF), the government has tried crediting money into the bank accounts. Many beneficiaries don’t realised the money is credited. The whole experience feels forgettable. And it is hard to track if there is direct effect on the economy.

In addition, many digital vouchers are also poorly implemented - hard to sign up for, redeem, track and use.

Vouchers are essentially a form of money, hence, it is important that it is properly accounted for in its entire journey, from printing, distribution and issuance, usage, merchant reimbursement and disposal.

Here is a high level view of a journey of the paper voucher corresponding to the steps numbered in the image above -

1. The government agency operations officer is in charge of planning, distributing, issuing the voucher booklets to recipients. Multiple people are involved in this phase as there are many distribution points and a campaign usually lasts for a few months.
2. The recipients will spend the voucher at a shop (e.g. a food stall)
3. The hawker at the food stall will collect all these vouchers. Regularly, an agency ops officer will go around the shops to collect and count the amount of paper vouchers collected and reimburse the hawker.

Each day, the ops officer carries around a large bag to collect paper vouchers and brings around a money counter to accurately count the number of vouchers collected at each stall. He manually updates his paper form after he confirms the amount collected at each stall. He does this twice a week for each stall so that the hawkers can receive their earnings more regularly. It takes him a few days to go through all the shops in the estate each week.

After returning to his office, someone has to manually enter these records into the finance system so that the money is reimburse to the hawkers' account directly. All these labour-intensive steps are prone to human errors and causes delay for the merchants to receive their earnings.

This also means it will be hard for any paper voucher scheme to scale to more shops and more denomination types for the voucher itself (e.g. $2, $5, $10).

• How might we improve the voucher distribution and redemption experience to make it easy to use for admins, beneficiaries and merchants?
• How might we reduce the operation overheads and make it easy to reconcile and reimburse the money back to merchants in a timely manner?
• How might we provide good audit trials and statistics to track the progress of a campaign?
• How might we allow government agencies to quickly set up campaigns?

I am the lead designer for this project. I worked on the service design, user research, prototyping, ux flows, user testing, user interface design, design system design and frontend development (CSS styling).

I work with a product manager, 3 software engineers and a product support officer for this project. We worked together with various agencies who wants to distribute vouchers to the community.

We designed a series of experiments to find out what is the best approach. These are prototypes ran at physical locations with intended users. I work with the product manager to design the test and work with the engineers to build them.

Is there even a need for a voucher, can we use other proof of claims to reduce overhead on issuing of vouchers?

One of our early ideas to prototype was the idea that people could use their identity card (NRICs) to redeem what they need. MUIS, the Islamic Religious Council of Singapore, wanted to distribute meals and came to us for help and we use the campaign as a opportunity to ask that question.

For the experiment, we build an web app that could scan NRICs to avoid the need for app downloads. The web app allows volunteers to scan the NRIC and allocate the number of meals the person is entitled to. We also need to onboard volunteers easily for the campaigns across many locations.

The biggest learning from that trial was that web app might not be the best technology vs native apps if we want to use hardware functions like the camera. Users are unfamilar with controlling camera permissions via the browser settings. It will cause the use to think that the app os not working when it is the hardware controls causing issues.