What matters first
The code is the easy part. The rules around it make the offer work.
The program still has to decide who qualifies, which offer applies, how the request is verified, what limit is enforced, and what the person sees after a code is issued.
A controlled program keeps the person, offer, code, decision, expiration, redemption, and exception history connected. That gives the brand room to change the offer without losing track of what happened.
01
Eligibility first
Verify the person and the offer they can access before a code is assigned.
02
One visible record
Connect the request, issuance, expiration, reissue, and redemption to the same person and program.
03
Exceptions by design
Decide who handles missing codes, expired offers, duplicate requests, and incorrect eligibility before launch.
Build the program
Work through the decisions that shape this program.
01
Define the offer
Write the business purpose, eligible product, value, timing, and intended action in plain language.
Questions to answer
- What should this offer help the brand accomplish?
- Which products, bundles, or purchase paths does it cover?
- What should the person do after receiving or using it?
Output: A one-page offer definition with a clear outcome and next action.
02
Set eligibility and limits
Name the qualifying partner organizations, roles, markets, and any training or employment requirements.
Questions to answer
- How will employment or partner affiliation be verified?
- Can different groups receive different values or products?
- How many codes can one person request and during what period?
Output: An eligibility and limit matrix that can be applied consistently.
03
Prepare the code inventory
Use separate groups of unique codes when offers, markets, products, or eligible groups need different inventory and reporting.
Questions to answer
- Which code inventory supports each offer and group?
- What happens when the inventory runs low or a code fails?
- Who can add, remove, or replace codes while the offer is live?
Output: Named code inventories with minimum thresholds and an accountable owner.
04
Design issuance and status
Make it clear whether a code is available immediately, requires review, has expired, or needs help.
Questions to answer
- What does the person see before and after requesting a code?
- When is manual approval required?
- Can an expired or failed code be reissued, and under what rule?
Output: A request-to-code-to-status path with the messages people will receive.
05
Connect redemption and reporting
Decide how the commerce or delivery system will return usage information and how often the records will be matched.
Questions to answer
- Can the commerce system report which codes were redeemed and when?
- Which product, order value, partner, or market fields are available?
- What will the team review weekly while the offer is active?
Output: A reporting cadence that connects issued codes with known usage and open exceptions.
A real business moment
A launch opportunity arrives with two weeks to act.
A consumer brand learns that a retail partner will feature a new product. The brand wants verified store employees to try it before the promotion begins, but the offer needs different limits by role and must end with the retail event.
01
Who qualifies
Eligible retail employees are verified against the partner's employee list and grouped by store and role.
02
Offer
Each eligible employee can request one product-specific code from the inventory assigned to that role.
03
Control
The code expires after the launch window. Failed codes can be replaced once, while duplicate requests move to review.
04
Record
The brand can see eligibility, requests, issued codes, known redemptions, remaining inventory, and exceptions by store.
Where teams get tripped up
Fix these issues before the program goes live.
01
Shared codes
One reusable code may be easy to distribute, but it removes individual limits and makes usage and exceptions harder to trace.
02
Eligibility after issuance
Checking eligibility after the code is sent creates avoidable reversals and a frustrating experience.
03
No inventory owner
A promotion stalls quickly when no one is responsible for low inventory, failed codes, and emergency replacements.
04
Issuance called success
Codes issued show access to the offer. They do not show redemption, product experience, or sales impact on their own.
Before launch
Make sure the basics are covered.
- 01The offer and intended outcome are written in one sentence.
- 02Eligible partners, roles, markets, and products are defined.
- 03Verification, limits, expiration, and repeat-request rules are documented.
- 04Every offer is connected to the correct code inventory.
- 05Low-inventory and failed-code owners are assigned.
- 06Confirmation, denial, expiration, and help messages are ready.
- 07Redemption data and reporting frequency are understood.
- 08The team has a date to review, adjust, extend, or close the offer.
Questions that usually come up
A few answers before you build.
Should every person receive a unique promo code?+-
Use unique codes when the program needs individual limits, expiration, replacement history, or a reliable view of who used the offer. A shared code can fit a broad public offer, but it provides much less control.
Do codes need to be issued immediately?+-
No. A verified and eligible request can be issued immediately, while unusual requests or missing information can move to review. The person requesting the code should always see the current status.
What if the commerce system cannot report redemption in real time?+-
Use the most reliable cadence available, such as a daily or weekly file. Keep issuance and redemption as separate statuses so the team does not imply that every issued code was used.