This release brings the Voucher portal to the Studio. An organisation runs its voucher programme there: the partners who honour its vouchers, the voucher offers for its members and the codes behind them. Its frontends, such as a Community Portal, show the offers as their own content, and the Studio decides which code a member gets and how often.
Partners and voucher offers
- The sidebar has a new group, "Vouchers", with "Voucher offers" and "Partners". It shows for "Owner" and "Administrator" and for the new permission sets "Voucher manager" and "Voucher viewer". A voucher viewer sees everything without changing it, with the codes masked.
- A partner has its name, a redemption address for members' messages, a website, up to 20 contact persons and an internal note. "Archive" shows once every voucher offer of the partner has ended, and a partner without voucher offers can be deleted.
- A voucher offer names its partner and its validity, in days of your time zone. Its voucher source for new customers, and optionally one for existing customers, is a static code or a voucher pool.
- The redemption limit says how often one person may redeem an offer: "Once per person", a number per calendar month or year, or "Unlimited". It counts across all your frontends.
- An offer starts as "Draft" and gives out codes only while it is "Active" and within its validity. "Paused" stops it until you activate it again, and "Ended" is final.
- Codes show masked in every list, with their first three characters only. A voucher manager sees an offer's static codes in full on the offer's page.
- The "Voucher settings", behind the gear on "Voucher offers", hold the default redemption address and the benefits alert address.
Voucher pools
- A voucher pool holds unique codes your partner supplied, for one voucher offer and one customer kind. Every member who redeems gets a code of their own, and no code is ever given out twice.
- "Import codes" takes a CSV or Excel file, or pasted codes, up to 50,000 at a time. A preview counts the new codes, the duplicates and the invalid lines, each with its line number, before anything is stored. A code exists only once in your organisation.
- A pool's page shows its stock: "Available", "Issued", "Withdrawn" and "Expired" codes. "Low stock" and "Empty" warn on the pool's page, the offer's page and the list of voucher offers.
- At the pool's low-stock threshold, and again when it is empty, the benefits alert address gets an email. Every night, shortly after midnight Vienna time, the pools are checked again for codes that expired.
- "Show" displays one available code in full, and every reveal is recorded. Codes can be withdrawn one by one, by the table's filter or by a list. Withdrawn is final.
- "History" lists each import with its file name and counts, each withdrawal and each change of the pool.
Redemptions
- "Redemptions", under "Vouchers", lists every redemption with its
RD-reference, the code in full, the member, the frontend and the mails. It shows for "Owner", "Administrator" and permission sets with "Redemptions: manage". - A redemption's page shows what the member was shown on the frontend, as it was at that moment. Under "Status and note", the redemption office sets "Open", "In progress", "Done" or "Cancelled" and keeps a note. The member never sees either.
- The list of voucher offers counts each offer's "Redemptions (30 days)", and an offer's page shows under "Redeemed by" the content through which members redeemed it.
- Every member gets a copy of their redemption by email, with the code, in your organisation's sign-in branding and in the language they read the page in. With "Copy of every redemption" on, the redemption office gets a copy too. Each copy shows as "Sent", "Failed", "Not sent" or "Pending".
- Where the page offered the Email channel, a member can write to the partner once about a redemption. The Studio sends the message, with the code, to the partner's redemption address or your default redemption address. If the partner's copy fails, the redemption's page asks the office to forward it.
- The "Redemption settings", behind the gear on "Redemptions", hold the redemption office address, the copy switch and the administrator address. Sending the administrator copy follows with a later release.
- Anonymizing an organisation membership also anonymizes its redemptions. Every redemption is deleted 7 years after its last status change.
Redeeming through a frontend
- Your frontends' backends redeem through the Service API. They learn whether an offer can give a code right now (available, not started, paused, ended or sold out), but never how many codes are left.
- For a signed-in member, the Studio checks the membership at the moment of redeeming, counts the redemption limit across all your frontends and gives out the code. A frontend also learns how often the member has redeemed an offer and whether the limit is reached.
- "Guest access", on a frontend's page, decides whether its backend may also redeem for people who are not signed in. It is off for every frontend until you switch on "Allow guest calls", and it is only for the app types "Web app" and "Server".
- A guest redemption with a member code is checked as an eligibility check and counts towards the redemption limit of that code's membership. Without a member code, only offers with a static code and no limit can be redeemed. A frontend makes at most 200 guest redemptions an hour.
Community Portal
- On a Benefit's "Redemption" tab, Portal editors can link the "Voucher Offer" of the Studio. While a Benefit is linked, its voucher codes and the partner's address are read-only in the Portal's admin, because the Studio manages them.
- Members still redeem from the Benefit's own fields for now. The Community Portal redeems through the Studio from a later release.
Fixes
- Uploading an image on the "Sign-in branding" page failed with "The image could not be uploaded". It works again.
- A Studio user who had disconnected a frontend could not delete their own account. Now they can.