Overview

Airship has the ability to store and issue single use voucher codes to guests as part of marketing campaigns, incentives or customer service gratuity.

We have flexible ways of working in different redemption scenarios alongside our partner technology companies such as EPOS, Order Ahead, Pay-at-Table etc. We can act as either the gatekeeper / originator of voucher codes (“master/primary”) or, more commonly, we simply act as the issuer and storage of redemptions (“slave/replica”).

There are two man requirements for an integration in this respect:

  1. Setting up an offer and getting your voucher codes to Airship so that we can issue them in our campaign mechanics.
  2. Getting redemptions back to Airship, so that we can report on campaign successes or trigger onward journeys or “don’t forget to use” comms.

Terminology

Assumptions / prerequisites

  • We assume your platform can already create offers and vouchers and that you have a way of redeeming them through your software, whether by manual type-in or a barcode/QR scanner.
  • We assume you have either a self-service interface or managed-service/support process for our mutual customers to create offers and generate voucher codes.
  • We assume that your voucher codes can only be used once.

Onboarding new offers and voucher codes

So what needs to happen when our mutual customer wants to run an offer? There are a few ways we can achieve this, noted below. We’ve highlighted which is the preferred option.

Offers

As our mutual customer creates an offer in your system, the offers need to reach Airship somehow, so that we have a corresponding Unique Code Group. There are two routes:

  1. We deal with this process manual between our support teams and/or the customer, whereby each offer must be manually created in Airship.
  2. The process is automated via our API, such that as the offer is created in your platform, a replica of the offer is created as a Unique Code Group (UCGID)

The outcome should be that we have a common linking reference, usually an ID of some kind, whereby, for example, your Offer ID 1235 (“Free glass of wine”) = Our UCGID 6789.

Our preference is option 2.

Voucher codes

Similarly, as voucher codes are created in your platform for these offers, Airship needs a copy of them so we can issue them.

There are three routes:

  1. Again, we could have a manual process, whereby voucher codes are created in bulk in your platform and then passed to us manually as CSV for our support team to load in for the relevant offer/Unique Code Group.
  2. Alternatively, if you have an API to create codes, a bespoke ‘issuance’ mechanic could be built whereby we issue a code to a customer as they click through from an email. This isn’t common as it does usually require extra bespoke work.
  3. Or, as voucher codes are created in your platform in bulk, you send them in bulk to our API.

Our preferred method is option 3.

The ideal “new offer” flow

So in summary, our preferred route is:

  1. Our mutual customer creates an offer in your system
  2. At the same time, you make API calls to create a UCGID placeholder in our system for that offer, with a suitable name. You grab our UCGID so you have a unique mapping ID to keep the two linked.
  3. As vouchers are bulk-generated (either initially or subsequent top-ups of codes), you bulk send these up to us, ready for us to exclusively issue.

Redemptions

A guest walks in with a code and presents a code for redemption. What next? The redemption needs to be sent back to Airship so that we know which codes have been used.

We assume in this scenario that you are validating the voucher against usage rulesets in your own platform. (If you would like us to be the master/primary owner for voucher validity, please contact us to discuss as this has some extra nuance.)

Again, there are a few ways of getting redemption data back to us.

  1. We have a ‘self-redemption’ mechanic that can be used to avoid integration altogether. This is described here. Codes can be scanned/typed into your platform on presentation of our voucher display, while our ‘countdown timer’ mechanic means we also get a redemption of the code. This is often accurate enough for many auditing and reporting purposes.
  2. Alternatively, you could send us a nightly CSV dump of redeemed codes. The CSV would need to contain our UCGID so we know which voucher code relates to which offer group.
  3. However, ideally, you would send us redemptions back in near real-time. We have APIs to facilitate this.

Further reading

We have written an SUV API guide which documents how to integrate using our preferred flow, as noted above:

  • Automatically creating and sending offers and codes to us
  • Marking them as redeemed in near real-time.
Did this answer your question?