A company-store pilot should end with a documented decision to expand, narrow or pause the rollout—not just a successful checkout. Approve the store only when representative recipients can order, the right merchandise reaches them, exceptions have an owner, and the program’s records agree. A payment simulation, an apparel sample and a delivered order prove different things.
This guide is for the person deciding whether an employee merchandise program is ready for more users. It provides a test matrix and release gates you can use with a managed provider or your own team. It is not a statistical reliability study or a substitute for a security review. Brand Sauce publishes this guidance from a company-store provider’s perspective; the framework does not assume that any particular platform includes the controls described.
Separate three kinds of proof
Start by labeling every observation. Otherwise, “tested” can mean that someone clicked through a mockup while another person believes a parcel has arrived.
| Evidence layer | What it can establish | What it does not establish |
|---|---|---|
| Digital rehearsal | Configured access, selection, totals, messages and simulated failure behavior | Actual decoration, packing, transit or real financial settlement |
| Physical sample review | The appearance, fit and handling of a particular approved sample | Whether the store sends the correct order to production |
| Controlled operational pilot | The observed journey of genuine, authorized orders through receipt and recordkeeping | Every future order, peak demand or an untested destination |
A beautiful sample does not prove that a size selected on a phone reaches the supplier correctly. A delivered bottle does not prove that a rejected payment is handled well. Keep those conclusions separate. If the launch fundamentals are still undecided, complete the company-store launch checklist first; this is the evidence gate after those decisions, not another launch plan.
Define exactly what you intend to release
Write a one-paragraph release boundary: who may order, which products and decorations are included, how orders are funded, where they may ship, and who handles support. Include the version or date of the assortment and policy. Testing a domestic employee-paid shop does not approve an international employer-funded recognition program.
For example, a proposed first release might include three approved products for one domestic office and its remote employees, with company-funded selections and no employee top-ups. A later phase could add personal purchases. This is a scope choice, not a claim that either arrangement is available from every provider.
List excluded cases just as clearly: unsupported destinations, unapproved logo variants, rush orders, split funding, or products awaiting samples. If a capability is not verified, remove it from the promise or mark it pending. A provider’s general country coverage statement is not proof that your exact product, decoration and delivery route are available.
Choose pilot cases by differences that matter
Do not recruit only the colleagues who built the store. They already know where the size guide lives and what the internal terminology means. Include people unfamiliar with the program and ask them to complete realistic tasks without coaching. Provide an appropriate accessible route for participation rather than requiring people to disclose a disability.
The number of participants should follow the number of meaningful paths, not a magic percentage of headcount. Several identical orders add less coverage than different funding, delivery and product paths. Use the following as a starting matrix and delete rows that do not apply.
| Case | Question to answer | Evidence to retain |
|---|---|---|
| First-time mobile recipient | Can they find the correct product, size and delivery expectation? | Task result, device and unprompted confusion |
| Funded selection at the limit | Does the permitted choice show the intended recipient total? | Approved funding rule and order summary |
| Choice outside the allowance | Is the intended block or payment route clear? | Observed result and explanation shown |
| Home versus office delivery | Does each address route retain the information it needs? | Redacted order and recipient confirmation |
| Two fulfillment paths | Can recipients understand separate production or shipping? | Line-level status and actual notifications |
| Assisted or keyboard-only journey | Can the recipient select, correct mistakes and finish? | Observed barriers and verified fallback |
| Correction or cancellation request | Does support know what is still changeable? | Request, owner and resulting order state |
These are proposed acceptance cases, not promises of platform functionality. A test may legitimately reveal that a desired behavior requires a different process. The decision is whether that process is usable at the intended volume.
Keep simulations out of real production
Ask the provider to identify the approved test environment and explain what remains connected. A storefront, payment system, order-management tool and decorator may not all share the same test boundary. Label test records clearly and agree who prevents simulated orders from becoming real merchandise.
For a concrete platform example, Shopify’s test-order instructions warn about automatic fulfillment services and describe checking the order after checkout. Those instructions apply to Shopify, not automatically to another store system. Confirm your provider’s equivalent controls instead of assuming a test payment protects every downstream connection.
Payment testing must follow the actual processor’s rules. Stripe’s testing documentation directs developers to simulated transactions and prohibits live-mode testing with real payment details. Do not improvise a charge-and-refund test because another platform’s guide mentions one. Ask the technical owner to select the permitted method.
Keep genuine pilot fulfillment separate: these are authorized merchandise orders intended to be produced and delivered, using the agreed purchasing arrangement. Budget for them as real orders. Do not disguise payment-system testing as a purchase. Record which evidence came from simulation and which came from real fulfillment.
Follow an order beyond the confirmation screen
For each genuine pilot order, trace the requested product and variant, approved artwork, destination, production handoff, shipping notification and receipt. Use an order identifier to connect the records; do not circulate a spreadsheet of home addresses to everyone reviewing the pilot.
At receipt, ask the participant to compare the parcel with the order—not simply rate whether they like the gift. Did the correct size and decoration arrive? Was an expected item missing, or was it correctly explained as a separate shipment? Was the delivery information useful? If the item needs care instructions, were those available?
Reconcile the completed order with the program’s financial record. An employer-funded checkout showing no recipient payment is not proof that the department was charged correctly. Match the agreed product, freight and other quoted charges to the appropriate record. Use the separate company-store invoice reconciliation guide for the detailed accounting workflow.
Observe the timing, but report it narrowly: “This order was received on this date” is evidence; “all future orders arrive this quickly” is not. One pilot cannot establish a delivery guarantee. For a date-critical event, obtain explicit production and shipping commitments for the actual order rather than extrapolating from the pilot.
Test recovery, not just the happy path
A store is not ready simply because an experienced administrator can complete checkout. Ask an unfamiliar participant to recover from an ordinary mistake: a missing required field, an unavailable selection or an invalid program code, using approved test cases.
W3C’s form-notification guidance recommends clear success and error feedback, including identifying problems in text rather than relying on visual styling alone. In your pilot, check whether the person understands what happened and what to do next. A red outline with no useful explanation should not be treated as a completed recovery path. This observation is one accessibility check, not a conformance certification.
Then rehearse the service handoff. Submit an agreed practice question through the designated support route without generating a false complaint about a real employee. Record who receives it, who can act, and how the recipient gets an answer. If an order can no longer be changed after production starts, the support response should explain the real options rather than promise an impossible edit.
For actual damaged or missing merchandise, follow the shipment recovery process. The pilot’s job is to establish that someone owns that process and can connect a request to the correct order.
Use release gates, not an average satisfaction score
A high average rating can hide a serious failure. Treat the following as recommended gates to agree before testing; they are not an industry certification.
| Gate | Ready to expand | Pause or narrow scope |
|---|---|---|
| Access and recipient cost | Intended users reach the right offer and see the agreed charge | Wrong people gain access or an unexpected payment is required |
| Order accuracy | Selected variants and approved artwork reach the right fulfillment path | Wrong variant, decoration or destination data is transmitted |
| Recipient recovery | Problems are understandable and a usable recovery route exists | A participant is stuck without a workable route |
| Service ownership | Requests reach an accountable person with a defined next step | Provider and internal team each assume the other owns the issue |
| Records | Orders, entitlements and agreed charges can be reconciled | Unexplained differences remain |
A minor copy change need not block an otherwise working release. But classify the issue by its effect, not by how easy it looks to fix. Incorrect delivery wording can be consequential if employees need the merchandise for an event. Give each accepted issue an owner, a correction date and a reason the remaining risk is acceptable.
Illustrative decision: launch less, with better evidence
Imagine a team planning a three-product store for 240 employees. It selects eight genuine pilot orders to cover home and office delivery, two production paths and different apparel sizes, alongside separate digital rehearsals. These numbers are illustrative, not a recommended sample size or measured Brand Sauce result.
Seven orders complete as expected. The eighth reveals that one product’s shipping message implies the entire order has shipped, although the other item is still being produced. The team should not summarize this as a reassuring overall success rate. It should determine which orders share the misleading message.
One reasonable decision is to correct and retest that message before expansion. Another is to launch the verified single-path assortment and hold the mixed-path bundle. Neither decision requires abandoning the program; both limit the promise to what has been demonstrated. Inviting all 240 employees while hoping support explains the confusion is a different, weaker acceptance decision.
Adjust the gate for on-demand, bulk and hybrid programs
On-demand pilots should check how individual selections reach production and how recipients understand production time. Bulk programs should check allocated sizes, stock availability and the pick-and-pack route. A hybrid pilot needs evidence for each route and for any order crossing between them.
Bulk can be a sensible fit for a fixed event with confirmed quantities, an approved design and a shared delivery point. An always-on store can suit recurring individual needs. A successful pilot does not prove that one model is cheaper; compare actual quotes, minimums, service scope and operational effort separately.
Keep a one-page release record
- Scope: audience, assortment version, funding, destinations and exclusions.
- Evidence: scenario identifiers, observed outcomes and simulation-versus-real labels.
- Open issues: impact, owner, deadline and any temporary restriction.
- Decision: expand, narrow or pause, with an accountable approver.
- After release: who watches initial orders and what triggers a pause in invitations.
Retest the affected paths after meaningful changes: a new funding rule, provider connection, destination or fulfillment model. Preserve the previous decision so the team knows what was actually approved. The goal is not an elaborate testing ceremony. It is a clear boundary between a store that looks ready and an operating program with evidence behind its promises.
Frequently asked questions
How long should the pilot run?
Long enough to observe the slowest included real fulfillment path and resolve important findings. A fixed number of calendar days is not a substitute for delivery evidence. Keep unfinished paths outside the approved scope.
Can a vendor demonstration replace a pilot?
It can show a capability, but it does not establish that your configuration, assortment and support handoff work. Ask which demonstration results carry over and which need your own evidence.
Must every product be physically ordered?
Not necessarily, but define what representative sampling covers. A different decoration process, supplier or packaging format may need separate evidence. Do not extend one sample’s approval to an unrelated product without a documented reason.
Should HR or IT sign off?
The program owner should own the release decision, informed by the people responsible for recipient experience, funding, technology and fulfillment. A technical pass alone cannot approve merchandise quality or an unresolved service process.
