Loyalty Program — Reasoning & Recommendations

01TL;DR

BigCommerce ships no loyalty program — but it ships most of one. Tiers, freight perks, store credit, coupons and progress messaging are all native and free. The only pieces genuinely missing are the points ledger and the earn engine.

And USA Clean doesn't need a ledger yet. At ~1.61% of sessions including a login, this is not a retention problem — it is an identity problem, and a loyalty program is a solution to a retention problem. Every mechanic in this brief is worthless against an anonymous session. Buying a points app today would mean paying ~$199/month to run a balance for people who never sign in to see it.

The recommendation is "USA Clean Pro" — a free, login-gated status program whose currency is freight, not points, built entirely on native Customer Groups + the Promotions API, at zero recurring cost. Signing in lowers your free-freight threshold; spending more lowers it further. The points question is deferred until logged-in order share justifies paying for a ledger.

Decision of record: pending — no client decision yet; will be logged as PD-006 in decisions.md.

02Current state

There is no loyalty program, no rewards surface, no tier, and no store-credit mechanic anywhere on shop.usaclean.com or in this prototype. A repo-wide grep for loyalty|rewards|points|rebate|VIP returns nothing but the eyebrow on Band 04 of the prototype landing page, which already reads "Post-purchase · Loyalty & personalization." The slot has been named for this feature since the index was restructured. It has been empty ever since.

What's actually broken is upstream of loyalty. The IA roadmap found 39% of sessions are returning visitors, but only ~1.61% include a login. Thousands of repeat buyers re-derive "what do I order for my Tennant T5" from scratch, every visit. That number is the whole reason this brief exists — and it is also the reason the obvious answer (buy a points app) is wrong.

What a self-serve buyer loses today by staying anonymous

• Their own history. Guest orders are orphaned — they exist in BigCommerce attached to an email address, but to no customer record. A returning technician cannot see what he bought for the T300 last time, because as far as the storefront is concerned he has never been here.
• Any reason to come back to us. There is no status, no accrued value, no saved machine — nothing worth more on the second visit than the first. The relationship resets every session.
• Themselves, in the account area. account.html leads with "Type: National," three sites, five users, fleet, approvals. As Recently Purchased put it: a single-location buyer with one machine and one past order sees none of themselves in it. An empty dashboard built for a 40-location chain is worse than no dashboard.

The data is already there. It is not surfaced, not claimed, and not rewarded.

03References

Zoro — the login-gated freight threshold (the most copyable mechanic in the scan)

Free ground shipping at $50 when signed in, $75 as a guest. No membership fee, no points, no ledger. The customer is paid — in the currency they care about most — to authenticate.

That is the entire acquisition engine of this brief, and on BigCommerce it is two automatic promotions, buildable in the admin UI with zero code. Everything else here is downstream of it.

Grainger RED PASS PLUS — the destination

$129/yr, free next-day delivery with no minimum, up to 15% off — and aimed explicitly at non-contract customers, which is precisely USA Clean's self-serve segment. The largest MRO distributor in North America has concluded that, for this buyer, freight is the product. Note that even Grainger offers a 60-day free trial: the paid tier is sold after the buyer has felt the benefit, never before.

Sherwin-Williams PRO+ — a major trade program with no points engine at all

One of the largest trade loyalty programs in America runs on tiered daily discounts. No points, no ledger, no expiry, no liability. It is the clearest evidence that a serious trade program does not require a currency.

NAPA / O'Reilly / AutoZone — why points fail this buyer, specifically

Automotive parts is the most mature individual-technician loyalty category, and its math is instructive:

A maintenance technician buys on failure — unpredictable cadence, perhaps 2–4 times a year. Under every program above, his points die before they ever reach a threshold. The mechanic is structurally incompatible with the buyer.

AutoZone is the exception worth stealing: it rewards trip frequency, not spend — a credit per qualifying visit regardless of size. That shape fits a failure-triggered buyer, and it maps onto BigCommerce's native customer.minimum_order_count with no ledger at all (§04).

Parts Town — the best technician UX in parts distribution

• My Equipment360 — save your machine, get the exact parts that fit it, its manuals and diagrams, and your own order history against that machine. This is the reason a technician creates an account, and it is the highest-value feature in this brief (§08, Phase 3).
• Order tracking is deliberately NOT gated. Anyone can track with an order number and a ZIP. The best operator in the category considered using tracking as an account lever and chose not to. Copy the decision, not just the feature.

SiteOne Partners — the channel-shift lever

2× points for ordering online. A direct, cheap attack on exactly the behavior USA Clean needs to change. Even if points never ship, the principle — pay more for the self-serve channel than the phone channel — belongs in the program.

Tractor Supply Neighbor's Club — reachable thresholds

Tier thresholds in the $500 / $2,000 annual range, not Home Depot Pro Xtra's $25,000 (Elite) / $250,000 (VIP). For a single-location buyer with one scrubber, a $25k ladder is not aspirational — it is an insult. Set the ladder where this buyer can actually climb it.

Harbor Freight Inside Track / WebstaurantStore Plus — how you sell a paid membership

Both are paid memberships that work, and both carry a device that de-risks the purchase for a P&L owner: Harbor Freight's 90-day full refund, and WebstaurantStore's "Guaranteed Savings" clause (they credit you the difference if annual savings don't beat the fee). If a Freight Pass is ever sold (§08), it ships with one of these or it doesn't ship.

The floor-care whitespace — opportunity, or warning?

04What BC Stencil gives us

More than expected. This is the section that changes the shape of the recommendation.

• Customer Groups are a real, zero-app TIER ENGINE. POST /v2/customer_groups creates a group carrying a discount_rules[] array; each rule has a type (all | category | product | price_list) and a method (percent | fixed | price). Silver is one rule — {type:'all', method:'percent', amount:3}. Gold is 5. Platinum is 8. Membership is the single scalar customer_group_id, writable via PUT /v3/customers. The entire "engine" is a nightly job that reads trailing-12-month spend from the Orders API and writes one integer. Two REST endpoints. No app, no custom storefront code, no recurring fee. (Note the v2/v3 asymmetry: group membership is writable on v3, but the groups themselves are v2-only.)
• Free shipping, gated on customer group, as an automatic promotion. action: {shipping: {free_shipping: true, zone_ids: '*'}} + customer: {group_ids: [GOLD]} + rules[].condition.cart.minimum_spend, with redemption_type: 'AUTOMATIC' so it applies with no code. This is Zoro's mechanic, natively, for free — and it is buildable in the admin UI with zero code. Schema gotcha: customer is a top-level key on the promotion object, not a clause nested inside condition — the nesting most write-ups get wrong returns a 422. Also: group_ids and excluded_group_ids are mutually exclusive on one promotion, and group_id 0 means guests + customers in no group, which is exactly the handle the guest-tier promotion needs.
• customer.minimum_order_count — a native, ZERO-LEDGER loyalty trigger. "Your 5th order ships free" works with no counting infrastructure whatsoever; BigCommerce evaluates the customer's order count itself. This is the AutoZone trip-frequency shape, free, today.
• Promotion notifications — the free progress bar. Four types (PROMOTION / UPSELL / ELIGIBLE / APPLIED) across four locations (HOME_PAGE / PRODUCT_PAGE / CART_PAGE / CHECKOUT_PAGE), HTML-capable, with BigCommerce handling the UPSELL → ELIGIBLE → APPLIED progression itself. And because the notification hangs off a group-gated promotion, the messaging is automatically tier-aware: a Gold member sees "you're $18 from free freight" against $50; a guest sees it against $125. This is normally a custom cart-drawer build. It shipped into the Standard Editor on 2025-08-19 — anything the team remembers from before that is stale.
• Store credit — the right rail for an individual. Per-customer (the "no company-scoped balance" problem that kills this for National Accounts simply does not apply here), API-writable (store_credit_amounts on PUT /v3/customers), storefront-readable via GraphQL (customer.storeCredit), and it auto-applies at checkout with no code for the buyer to dig out of an old email.
• Gift certificates — POST /v2/gift_certificates, with a real expiry_date, partial redemption, a carrying balance, and no email sent on API creation, so we own the delivery.
• Auto-create-account-after-guest-checkout is a native radio button. Settings › Checkout › Customer Accounts → "Customers are not required to have an account to check out, but automatically create one after ordering." It converts every guest purchase into a customer record with an order history and a set-password email. This is the precondition for literally every other mechanic in this brief.
• Passwordless magic-link login is native — a one-time email link to /login.php?action=check_passwordless_login&token={token}.
• Multi-coupon shipped 2026-01-05 — up to 5 codes in the native cart and checkout.
• Order webhooks for an earn ledger: store/order/statusUpdated and store/order/refund/created are the settle/claw-back pair. store/order/created is the wrong accrual trigger — the order isn't paid yet.

05Stencil limitations

Per rule #2, exactly what native BC cannot do here:

1. No loyalty, points, or referral feature of any kind. No object, no admin screen, no API. BigCommerce's own rewards glossary routes merchants to the App Marketplace, and its 2026 product-roadmap post is silent on loyalty while explicitly framing retention as a promotions problem. Waiting for BC to ship loyalty is not a strategy.
2. No ledger. Store-credit grants leave no trace at all — only redemptions are reconstructible from order data, and there is no "total outstanding credit" report anywhere in the platform. If we grant credit, we must keep our own book, or we cannot answer "how much do we owe?"
3. No store-credit expiry. Gift certificates have one; store credit does not.
4. Store-credit application is all-or-nothing. BC applies all available credit up to the order value; the buyer cannot elect to spend $40 of a $120 balance and save the rest. (Leftover value is not forfeited — but the choice isn't theirs.) Mitigate by not defaulting the toggle on: "You have $42.50 — apply now, or save it for a larger order?" We control when the endpoint fires.
5. minimum_order_count is lifetime and monotonic. Counts only go up, so a tier built on it can never demote, and the giveaway compounds forever. It is also API-only — promotions using it aren't creatable in the control panel, so merchandising staff can't self-serve them.
6. No native guest-order claim, and no native guest-order lookup. Both are sold as marketplace apps, which is the strongest available evidence the platform lacks them.
7. Customer Groups require the Growth plan or above — the tier engine does not exist on Core. (BigCommerce renamed its plans on 2026-06-01: Standard→Core, Plus→Growth, Pro→Scale, Enterprise→Performance. Do not say "Plus" in the deck.) USA Clean is almost certainly above Core given they are buying B2B Edition — but this must be a checked box, not an assumption, because the entire engine collapses without it.
8. Customer Segments are Performance-plan-only and in closed beta. Not an escape hatch for orthogonal segmentation below the top plan.
9. No review webhook — so "points for writing a review" has no native trigger.

06App marketplace shortlist

The client's rule is that an app loses if its recurring fee passes a one-time custom build within 12–18 months. Here there is a prior test the apps have to pass first: they have to beat free. Native Customer Groups + Promotions + store credit deliver the recommended program at $0/month. Every app below is therefore being asked to justify a fee against a working, zero-cost alternative — not against a build.

The honest reframe on build-vs-buy

The apps do not lose on price. A $199/mo app is ~$3,582 over 18 months — plausibly under what a custom points ledger would cost to build (~280–420h ≈ $35k–$55k, plus $8k–$15k/yr to run). By rule #3's arithmetic alone, the app wins.

They lose on shape and on sequence.

• Shape: the order-gated meters (Smile, Yotpo, LoyaltyLion) charge more as reorder frequency rises — they tax the exact behavior the program is built to create. Only Lootly's flat/unlimited pricing survives this catalog.
• Sequence: every one of them sells a ledger, and a ledger is the last mile. At ~1.61% login, buying one means paying a subscription to run balances for people who never sign in to see them. Manufacture the logged-in population first — with native tools that cost nothing — and only then ask whether a currency is worth renting.

07Caster impact

Everything new stays inline in the consuming page — rule #7, first-consumer scope. Nothing in shared Caster CSS changed, so the cache-bust stays at ?v=0.16.3 and /bump-cache-bust was not run.

The account chrome (.acct-tabs, .acct-tabs__item, .pill-count, .card) is reused unchanged from the existing account surfaces.

08Phased recommendation

Quick wins — ship now (OOTB, hours to days, ~zero cost)

None of these is a loyalty program. All of them are the precondition for one, and several are worth doing even if the program is never built.

1. Turn on auto-create-account-at-guest-checkout. It is a radio button. It is free. It converts every guest purchase into a customer record with an order history, and it is the precondition for tiers, store credit, and every targeted promotion. Ship it first.
2. The login-gated free-freight threshold — two automatic promotions ($50 signed in, $125 guest). Scope zone_ids to the contiguous US, and scope the promotion to parts/consumables categories so it can never fire on a freight-classed machine.
3. Native progress messaging — attach notifications to those promotions. Commit to CART + CHECKOUT (dependable); validate HOME/PDP in the live theme before promising them.
4. Enable multi-coupon, and set can_be_used_with_other_promotions: true on tier promotions — otherwise a Gold member who clicks a promo code in an email has their tier discount silently cancelled, the precise opposite of the behavior we're trying to buy.
5. Instrument the real numbers (§09) — before building anything.
6. Write the three non-goals down as explicit decisions (§09).

Trigger to graduate to Phase 1: the account-creation switch is live and guest→registered conversion is measurable, and the answer to the logged-in-order-share question (§09) says there is a real gap to close.

Phase 1 — the program (Low–Medium; native, no app, no recurring fee)

"USA Clean Pro." Silver / Gold / Platinum on native Customer Groups, earned on trailing-12-month spend, with thresholds in the $500 / $2,000 range — Tractor Supply's order of magnitude, not Home Depot's.

Plus the two things that make an account worth having on day one:

• "Claim your past orders" — match orphaned guest orders by email and write customer_id onto them. This is the direct answer to what the anonymous returning technician actually loses: not a discount — his own history. Without it, a new account is an empty room and the buyer must wait until their next purchase for it to mean anything.
• Passwordless magic-link login — for a technician with greasy hands on a phone at 11pm, "tap the link in your email" beats any password flow ever designed. Ship it with the backfill: together they are the technician unlock — "tap here to see everything you've ever ordered for your T300." Ship it without the backfill and the magic link opens an empty room.

Ship the un-gated guest order lookup (order # + ZIP) at the same time, as the program's deliberate counterweight. Parts Town proves the best operator in the category chose not to use tracking as a lever.

Trigger to graduate to Phase 2: logged-in order share is high enough that a credit balance would actually be seen and spent. Until then, credits accrue to accounts nobody signs into and become an un-auditable liability.

Phase 2 — a reward currency (data-gated)

Store credit as the reward instrument, with our own earn ledger. Store credit is the redemption rail (per-customer, auto-applies, no code); the ledger is a small table written from store/order/statusUpdated + store/order/refund/created, because BC gives us a balance and never a ledger. The account-area "how you earned this" view is built from our records, not BC's.

Settle two policy questions before building: the all-or-nothing redemption behavior (§05), and whether a welcome credit is survivable against consumables margin (§09).

Phase 3 — future (each independently gated; none is owed)

• "My Machines" — the equipment registry (the Parts Town pattern). The highest-value technician feature in this brief and the reason a technician creates an account at all. Hard dependency: does a reliable machine-model → compatible-parts mapping exist? If not, this is a catalog-data project before it is a UX project, and the estimate changes by an order of magnitude. This is the same mapping PD-004 is already data-gated on — the two should be resolved together.
• Paid "Freight Pass" (Grainger RED PASS PLUS is the destination). Two gates, measured not assumed: self-serve repeat frequency ≥ ~6 orders/year (below ~4–6 a paid tier will not renew), and the free freight program has already proven freight is the lever. Sell it with a Harbor-Freight-style refund or a WebstaurantStore-style guaranteed-savings clause.
• Technician-to-technician referral — after a population of logged-in, repeat, satisfied technicians exists. You cannot refer from nobody.
• A points currency — only if the client wants one. If forced, argue hard for the AutoZone shape: reward trip frequency, not spend, which fits a failure-triggered buyer and maps onto native minimum_order_count with no ledger at all. Treat "do we want points?" as a separate, later, independently-justified decision — not a sub-item of "do we want loyalty."
• QR code on the machine → straight to its parts. Depends on "My Machines" existing first, and it is an operations commitment (who applies the stickers, at what touchpoint?) before it is a feature.

Decision of record: pending — no client decision yet; will be logged as PD-006 in decisions.md.

09Implementation notes

The two traps (both will actually happen)

Discount precedence

BC's real execution order: customer-group discounts hit product price → product-level bulk pricing (which a fixed-amount rule can override) → product-level promotions → order-level promotions (subtotal only — explicitly excluding shipping, which is why free freight must be a shipping-scoped action, not an order-level percentage) → coupons, up to 5.

Unlike National Accounts, there is room in the price here — these buyers pay list, not a negotiated contract price. But the worst-case stack is now legally reachable since multi-coupon shipped: Platinum 8% + a welcome credit + a seasonal coupon + free freight, on one order. Model it, put a floor under it (minimum spend, category exclusions), and price it before raising the coupon count above 1.

Data sources

• Tier computation: trailing-12-month spend from the Orders API → PUT /v3/customers customer_group_id. A nightly scheduled job.
• Derive the tier from our own spend record, never from state that lives only in customer_group_id — see the graduation trap below.
• Earn ledger (Phase 2): store/order/statusUpdated to accrue on a settled status, store/order/refund/created to claw back. Not store/order/created — the order isn't paid yet.

The B2B boundary — why this brief is scoped the way it is

It compounds: National Account orders arrive via Net-30 / PO / rep-keyed / EDI / punchout and bypass the storefront checkout entirely, so store credit, gift certificates and cart promotions do not function for them at all. The same instruments work perfectly for the self-serve buyer precisely because they reach checkout. National Accounts want an off-invoice rebate; that is a different brief.

Four requirements follow:

1. Exclude B2B Edition customers from every loyalty promotion, explicitly, via customer.excluded_group_ids. (Budget an extra promotion object per tier boundary — group_ids and excluded_group_ids are mutually exclusive on one promotion.)
2. Guard the nightly tier job: it must never write a loyalty group id onto a customer linked to a B2B Edition company. One bad PUT silently destroys a negotiated contract price.
3. Design for graduation, not collision. A single-location buyer who grows into a small chain is the success case — and on the day they become a company user, the group slot is taken and their loyalty tier silently vanishes. So (a) derive the tier from an external, re-projectable spend record, and (b) make graduation an upgrade: the negotiated contract price must beat Platinum, visibly. If a customer's contract price is worse than the tier they just left, we have built a trap and they will find it.
4. Keep the two programs invisible to each other in the UI. Tier badges and credit balances must not render for B2B-linked customers; contract-pricing language must not render on self-serve surfaces. This is why account.html and account-home.html are untouched by this work — that separation is the boundary, made visible in the prototype.

One shared surface is fine, and only one: identity. Passwordless login, guest-order claiming, order tracking and the machine registry are useful to a National Account technician too, and none of them touch pricing. Build the identity layer once, for everyone. Build the reward layer twice, separately, and never let them meet.

Non-goals (write these down as decisions)

1. Do NOT force account creation before purchase. Baymard Institute (n=4,384): 24% of shoppers abandoned a cart solely because they were forced to create an account — the #2 abandonment reason after surprise costs. Amplified, not softened, for a technician on a phone next to a dead machine at 11pm. Offer the account after the purchase, as a benefit — never before it, as a toll.
2. Do NOT hide prices from guests. The peer set shows list price to everyone and reveals a better price on login (MSC: "Log in to save on over 1 million products"). "Sign in to see YOUR price" works. "Sign in to see A price" does not. And there is a USA-Clean-specific reason: hiding prices from guests hides them from AI answer engines too, which directly contradicts the GEO/AEO audit already delivered on this account.
3. Do NOT put order tracking behind a login. Parts Town — the most sophisticated technician UX in parts distribution — deliberately lets anyone track with an order number and a ZIP. A tech whose machine is down needs the tracking number, not a signup form.

The questions the client must answer

1. Of customers with at least one prior purchase, what share of their subsequent orders are placed logged-in? This one query decides whether the program is urgent or optional — it isolates the real retention failure from ordinary anonymous browse traffic. If it comes back high, the 1.61% figure is an artifact and a real rewards program becomes a legitimate next move rather than a premature one. Run it first.
2. What is freight as a share of a typical self-serve order — and do we already ship free above some threshold? If free freight is already given away, the strongest lever in this research is already spent and the recommendation changes materially.
3. What is the gross margin on consumables? Decides whether a 2–5% giveback is survivable — and whether the floor-care whitespace (§03) is an opportunity or a warning.
4. What BigCommerce plan are we on? Customer Groups require Growth or above — the entire tier engine collapses on Core.
5. Are any consumables bulk-pricing rules configured as fixed-amount rather than percent-off? If yes, they will silently void the tier discount on the highest-velocity SKUs (Trap 1).
6. Is customer_id writable on an existing guest order? Decides whether the "claim your past orders" backfill is a one-week build or an app purchase.

Auth + role gating

Everything here is signed-in-only by construction — which is the point, not a limitation. The tier engine is invisible to a logged-out shopper, and that is precisely what makes it a login incentive. But it means the logged-out surface is the load-bearing half: "Sign in — members ship free at $50" on the cart is what converts. That copy is theme work, and it is where the program lives or dies.

Accessibility

The freight nudge is a live region, not just a visual bar — when the remaining-to-threshold figure changes on a qty update, it must announce. The <progress> semantics carry aria-valuenow / aria-valuetext ("$18 remaining to free shipping"), and the bar is never the only carrier of the information — the text states it. Tier badges are text, not color alone. The tier ladder is a list with a programmatic current-step indicator, not a purely visual highlight.

Performance

The tier resolves server-side on login (it's a customer-group price), so there is no client-side flash. The nudge is rendered by BC's native promotion notifications, so it costs no additional request.

Analytics

Split every metric by segment — self-serve only. National Account volume will swamp the numbers and make the freight and margin math wrong in both directions.

• Guest → registered conversion (the quick-win metric — does the radio button work?).
• Logged-in order share, and the sharper cut: of customers with ≥1 prior purchase, the share of subsequent orders placed logged-in. This is the metric the whole program is judged on.
• Freight-nudge conversion — carts that crossed the threshold after seeing the UPSELL banner.
• Tier distribution and tier-up rate — is the ladder reachable?
• Credit redemption rate (Phase 2) — and outstanding liability, from our ledger, because BC will not tell us.

10Catalyst / replatform candidacy

Can it ship well in Stencil? Yes — entirely. The tier engine is two REST endpoints and a nightly job. The freight benefit and the progress nudge are native promotion objects that BigCommerce renders itself. The account surface is one Stencil template. There is no part of the recommended program that Stencil expresses awkwardly.

Would Catalyst make it materially easier? No. The constraints that shape this brief — no ledger, one customer_group_id, all-or-nothing store credit — are platform-data constraints, not rendering constraints. A React storefront does not give BigCommerce a points ledger. Replatforming would change nothing about the parts that are hard.

What is lost by holding for the replatform? Everything, for no gain. This is the rare brief where the honest answer is that the replatform is irrelevant. Ship it on Stencil.

The one Phase-3 item with a genuine headless flavor is "My Machines" — a stateful, fleet-aware registry that wants a server-side data layer, and which converges with the Phase-3 personalization case in Recently Purchased, Search and Model landing. As those briefs already note: personalization is the through-line that eventually justifies the headless move, but none of them justify it alone — and this one justifies it least, because its Phase 1 needs nothing.

11Sources

BigCommerce platform

Programs & precedents

Apps

Internal