Most stamp card programs are designed inside the software, one setting at a time. That is backwards. The program's economics, rules, and customer wording should be decided before opening the configuration screen, because every setting you guess at is a setting you will explain incorrectly to a customer later.
This article designs a complete sample program for an illustrative coffee shop. Every number is a model you should adjust to your own margins, but the sequence is the point: decide the business rules first, then build them in BoomerangMe. We also cover the software-side setup steps in our coffee shop stamp card setup guide; this article is the design work that comes first.
The sample business
Meet Riverside Coffee (illustrative). A single-location specialty coffee shop, average ticket around eight dollars, gross margin around seventy percent, about four hundred transactions a week, of which roughly half are repeat customers within the month. The owner's goal is modest and specific: convert occasional visitors into weekly regulars.
That goal matters because it shapes the reward. A program meant to increase visit frequency should reward behavior that is easy to repeat: a free drink after a reasonable number of visits. A program meant to increase ticket size would instead reward spending thresholds. Riverside Coffee wants frequency, so the stamp card is the right mechanic.
Decision one: the qualifying purchase
The first design decision is what earns a stamp. The options, from simplest to most restrictive:
- Any purchase earns a stamp — Customer experience: Simple to train and explain; Risk: Very low purchase; free water counts
- Any beverage purchase — Customer experience: Still simple; excludes retail; Risk: Slightly more to explain
- Purchase above a threshold — Customer experience: Ties stamps to meaningful tickets; Risk: Hardest to explain at the counter
For Riverside Coffee, any beverage purchase is the right balance. It is easy for staff to apply in seconds, matches how customers already think about a coffee shop visit, and excludes the retail shelf where a stamp would subsidize low-margin purchases. The threshold approach would add friction at exactly the wrong moment: the morning rush.
Decision two: the stamp threshold and reward
The threshold is the number of stamps required to earn the reward. This is where most programs get designed by feel, so work the numbers instead.
The reward is a free drink of any standard size. Riverside's average drink costs about two dollars to produce. For the program to make sense, the customer should feel the reward is reachable, and the business should receive enough margin from the qualifying purchases to fund it. At ten stamps, a customer who completes the card has spent roughly eighty dollars (ten visits at an eight-dollar average ticket) to earn a two-dollar reward. That is a reward cost of about 2.5 percent of the revenue the program generated, which is a sustainable loyalty cost for a business with seventy percent margins.
Nine-to-ten is also the classic punch-card length for a reason: long enough to protect margin, short enough that customers do not abandon the card. If the threshold is too high, cards get lost before completion and the program earns a reputation for being stingy rather than generous.
The decision framework: divide your reward cost by the expected revenue a completed card generates. If that ratio exceeds roughly five percent of revenue for a high-margin business, either shorten the reward's cost basis (free small drink rather than any size) or raise the threshold.
Decision three: exclusions, written down
Every program has exceptions, and every unwritten exception becomes a counter argument. Decide these before launch:
- Expiry. Will completed stamps expire? Riverside sets a six-month expiry on completed cards, communicated in the program terms rather than at the counter.
- Combining offers. Can the free drink be combined with a discount promotion? No. One reward per transaction.
- Staff use. Can employees participate? Decide it, write it down, apply it uniformly.
- Custom orders. Does a modified drink count as a standard drink? Riverside defines the reward as any drink up to a large, including one customization.
The purpose of writing these down is not legal protection. It is so that when a customer asks at 7:40 on a Tuesday morning, any team member gives the same answer.
The customer-facing wording
Write the program the way the customer will hear it, in one sentence: "Buy nine drinks, get your tenth free." Then write the enrollment script for staff: "Would you like a digital stamp card? It lives in your phone's wallet, so you never forget it."
Two details in that script are doing real work. "Digital" answers the objection of carrying another card, and "lives in your wallet" answers the follow-up question about downloading an app. Customers can enroll without installing a separate app through wallet-based cards, which removes the single biggest enrollment objection.
The customer-facing terms, in plain language, become the source of truth for the configuration. When you sit down to build the program in the software, you are translating decisions that already exist, not making them under a settings screen's pressure.
What to test before customers arrive
Before launch day, run the full program as a customer would experience it.
- Enroll a test card from a customer's phone.
- Earn a stamp at the register and confirm it appears on the customer's card.
- Fast-forward the card to a completed state and redeem the reward, checking what the staff sees and confirms.
- Confirm the redemption works during a busy transaction, not just in a quiet test.
- Have a staff member ask a question you did not anticipate, and add the answer to the written terms.
This is the same pre-launch discipline we recommend for any small-business software rollout: test the customer path, not just the admin screen.
Questions to answer before you build
Before opening the software, every program should have written answers to: What purchase earns a stamp? How many stamps earn the reward, and what exactly is the reward? What is excluded, and when do stamps expire? What does the counter staff say, word for word, when inviting a customer to join? What does the reward cost us per redemption, and is that cost below roughly five percent of the revenue a completed card generates?
If those answers exist on paper, the software build is a translation exercise. If they do not, the software build is guesswork, and customers will experience every guess as an inconsistency.
MBH Web Services builds programs exactly this way: business rules and reward economics decided first, then implemented, tested, and handed over with staff training included. But the design sequence in this article is something an owner can run solo in an afternoon, and it will produce a better program than configuring settings one at a time. Design the card on paper, then build it in BoomerangMe.
