A company store is ready to launch when the right people can choose the right merchandise, complete an authorized transaction, and get a recoverable outcome when something goes wrong. A polished catalog is not enough. Use this company store launch QA checklist workbook to connect catalog, eligibility, accessibility, checkout, fulfillment, and recovery tests to evidence and a named human decision.
Download the workbook and define its limits
Download the English company store launch QA workbook, version 2027-04. The openable spreadsheet contains 42 original workflow cases and five sheets: Start here, Test Cases, Results, Defects, and Signoff. It starts with every case marked Not run. No example result is presented as a completed customer test.
The version name supports 2027 planning; preparation and source review occurred on October 30, 2026. This is an editorial test framework, not a forecast of future platform behavior, a security certification, or a complete accessibility audit. Recheck the selected platform, payment arrangements, destinations, and applicable requirements before the actual launch. Your organization remains responsible for employment, privacy, tax, legal, and purchasing decisions.
The workbook deliberately separates readiness from approval. A severity-weighted pass rate helps summarize test progress, but a high percentage cannot override an unresolved critical failure. All 42 cases need valid pass records before the sheet can indicate readiness for a human decision. The decision owner, date, and evidence remain separate inputs. A spreadsheet cannot authorize a launch or change a production system.
Keep an untouched master and make one working copy for each build, market, and audience combination. If a case genuinely does not apply, revise the test plan and formulas explicitly, obtain the responsible owner's agreement, and retain the prior version. Do not type Pass into an unexecuted case simply to make the dashboard green.
Fix the launch boundary before you test
Write a one-paragraph launch definition before opening the Results sheet. Identify the approved audience, products, destinations, currencies, payment method, budget source, fulfillment route, and support hours. State what is excluded. An employee allowance store, a public merchandise shop, and a client gift-selection portal can share visual components while requiring different eligibility and financial controls.
The program owner approves the intended experience. Human resources confirms employee eligibility and entitlement rules. Finance supplies the approved treatment of totals, co-payments, refunds, and reconciliation. Merchandise operations owns the catalog and substitutions. Information technology owns access and integration behavior. Privacy and security reviewers approve the test-data boundary. A support owner accepts the failure-handling procedure. One person can hold multiple roles, but no role should disappear into an unnamed team.
Use synthetic identities and representative, approved test addresses wherever practical. A screenshot containing a real employee's home address is not automatically suitable for a shared defect tracker. Decide who can see evidence, how long it is retained, and how it is removed. The recipient-data governance guide provides a separate framework for that lifecycle; this workbook tests whether the agreed controls actually operate.
Also decide what constitutes a safe test transaction. Use a supported test environment and payment mode where available. If an approved production smoke test is necessary, record its authorization, spending ceiling, cancellation route, and fulfillment containment first. Never assume a small order is harmless: it may reserve inventory, trigger a shipment, or expose a private catalog.
Freeze the configuration being evaluated. Record the build identifier and the relevant catalog, audience-policy, and shipping-rule versions in the evidence bundle. A passing test against yesterday's settings is not proof for today's launch candidate. Material changes require targeted retesting and a new decision record.
Use six coverage areas, not one happy-path order
The 42 cases are original operational tests organized into six groups of seven. They are not an industry benchmark or a claim that 42 tests cover every store. Extend them for your actual risks, including custom integrations, unusual products, multiple approval levels, or destination restrictions. When adding rows, extend every dependent formula and validation range and rerun boundary checks.
Launch-test coverage and the evidence each owner should supply
| Area | Decision to test | Primary owner | Useful acceptance evidence |
|---|---|---|---|
| Catalog | Can only approved products and variants be ordered? | Merchandise operations | Approved catalog version plus matching order lines |
| Eligibility | Do access, budgets, and revocation follow policy? | Program owner and identity team | Allowed and denied test identities with entitlement records |
| Accessibility | Can the intended journey be completed with relevant access methods? | Accessibility and product specialists | Recorded keyboard, focus, error, and assistive-technology checks |
| Checkout | Are totals, payment outcomes, and retries reconciled? | Finance and engineering | Linked cart, transaction, and order records |
| Fulfillment | Does the actual dispatch match the authorized order? | Fulfillment owner | Line-level reservation, dispatch, and delivery evidence |
| Recovery | Can the team stop, reconcile, and recover without duplication? | Support and operations | Owned incident, corrective action, retest, and closure record |
Catalog tests should include saved links to disabled products, a size or color change, exhausted stock, and a change of audience. Hiding a product in navigation does not establish that its direct ordering route is unavailable. Compare the submitted order line with the selected variant, not just the product-page image.
Eligibility tests need both allowed and denied identities. Include a person whose eligibility has been removed and someone with a similar identifier to another participant. Check the approved revocation behavior for an existing session. Test repeat redemption and attempts to perform an administrative action as a shopper. A successful login proves authentication, not correct entitlement.
Fulfillment tests should follow individual lines through split shipments, partial delivery, returns, and replacements. “Order shipped” can conceal an undelivered line. Require a stable relationship between the order, payment, reservation, dispatch, and support records. This is a reconciliation design, not a promise that every vendor exposes the same fields.
Test access and input errors as real customer journeys
Use the World Wide Web Consortium's Web Content Accessibility Guidelines, WCAG 2.2 as a technical reference when defining the accessibility work. The reviewed Recommendation is dated December 12, 2024. Its requirements are broader than the seven accessibility cases in this workbook. Passing these cases does not establish full conformance, certification, or satisfaction of a particular jurisdiction's legal obligations.
Choose the actual combinations of browser, device, and assistive technology with the relevant specialists. Start with keyboard navigation, visible focus, dialog entry and exit, meaningful image alternatives, understandable form errors, usable zoom and narrow layouts, and communication of cart-state changes. Record the tested combination so another reviewer can reproduce the result.
The W3C Web Accessibility Initiative's form-validation tutorial distinguishes helpful input validation from security enforcement. Its guidance supports clear required-field identification and accessible error notification; client-side checks alone are not sufficient security. Translate that distinction into separate tests for what the shopper sees and what the server actually permits.
For a US-facing store, use representative approved names and address formats rather than one convenient test address. Exercise apartment information, long names, punctuation, missing required fields, and corrected input. These are test-design choices, not assertions that a particular format is accepted by every carrier. Ask the actual fulfillment provider which address rules apply.
After an error, verify that valid input remains available and that the person can find and correct the problem. A red border alone may be insufficient evidence of an understandable error. Record the observed message and navigation behavior. Do not replace a manual journey review with an automated scanner score; the two answer different questions.
Enter results without turning the workbook into an approval machine
Review severity before execution. Default weights are three for critical cases and two for high cases; one is available for an explicitly reviewed standard-severity case. These are editorial starting values, not measured risk probabilities. The Results sheet looks up weight by case identifier so the relationship is explicit. Preserve stable, unique identifiers when editing the test plan.
A valid pass requires the actual Pass result, an evidence reference, a tester, and a valid spreadsheet date. The formula also rejects unsupported weights and unmatched or duplicated case identifiers in the test catalog. Treat those checks as input safeguards, not proof that the evidence is truthful. A reviewer must open the evidence and compare it with the acceptance criterion.
The weighted rate divides the weight of valid passing cases by total case weight. Keep the unresolved-critical count beside it. A critical failure in an otherwise strong run must remain visible; rounding a percentage is not a risk decision. The gate also requires every case to pass, so a missing noncritical result cannot disappear behind a favorable weighted average.
Enter each defect with a stable defect identifier, related case identifier, severity flag, state, owner, and closure evidence. A populated but incomplete defect row remains unresolved. Closing a defect requires more than changing its label: preserve the original failure, link the correction, and attach the retest. The workbook cannot determine whether a screenshot genuinely belongs to the tested build.
Do not overwrite formulas or paste an old passing column into a new run. When moving the workbook between spreadsheet applications, verify recalculation and the displayed gate. Keep a small validation copy for synthetic boundary tests, separate from operational evidence. A completed synthetic test of the workbook is not a completed test of your store.
Hypothetical decision one: employee access leaks a private catalog
Consider a hypothetical US employer preparing an employee merchandise store with single sign-on. This is an illustrative decision, not a customer story or a claim that a named platform provides a particular integration. Human resources supplies an approved eligible cohort and allowance policy. Information technology supplies a supported identity configuration. Merchandise operations provides the employee-only catalog and the public catalog that must remain separate.
The team creates eligible, ineligible, and recently removed test identities. An eligible person can sign in and choose the correct products. The removed person, however, can reopen an existing session and see private prices. A normal purchase test would miss the problem. The tester records the build, identity category, policy version, session sequence, and observed exposure, using synthetic data rather than a real employee record.
The launch owner now has three choices: release to everyone, restrict the cohort, or delay. A restricted cohort is not a useful mitigation if the same session defect exposes the private catalog to excluded users. It reduces volume but does not enforce the boundary. A delay creates schedule cost and may require a separate communication to employees, yet it avoids knowingly opening a store with unverified access controls.
The identity and storefront owners diagnose the specific revocation path. They document whether the agreed policy requires immediate removal or a defined session-expiry behavior, then implement the authorized correction. The tester repeats the original sequence, tests a fresh denied login, and confirms that an eligible identity still works. The budget check is repeated because access and entitlement may share configuration.
Acceptance requires the corrected build identifier, evidence that the removed identity cannot perform the prohibited action, evidence that the approved cohort can still order, and a named owner decision. The original failure remains in the Defects sheet. The team does not lower severity after the fact merely because the launch date is close.
If single sign-on remains unavailable, a different supported access method might be considered. That is a new architecture and policy decision, not a test waiver. The owner must approve its identity assurance, administration cost, recipient friction, and data implications, then test the revised flow before launch.
Hypothetical decision two: a multi-country checkout has an unknown payment outcome
Imagine a hypothetical merchandise program serving three approved countries. One product is disabled for a destination, and a carrier handoff is deliberately failed during testing. Finance supplies approved totals and refund treatment for each route; logistics supplies supported destinations and service constraints. The scenario does not assume that one country's tax or shipping rules apply elsewhere.
The first failure appears after checkout times out. The shopper sees no confirmation, but the payment provider's outcome is unknown. Repeatedly submitting the order might create duplicate charges or fulfillments. The tester records the original transaction and request identifiers, preserves the observed state, and asks the designated technical owner to reconcile the provider record before any retry.
Once the transaction is reconciled, the team checks the order and warehouse records. A failed carrier handoff must remain an owned exception, not become Delivered because the order exists. The support rehearsal explains the known state, the next check, and the permitted replacement or refund path without promising an unverified delivery date. Any replacement links to the original order to prevent duplicate compensation.
For the disabled product, test direct access, an old cart, and a country change after the item was added. A visible warning is not enough if the final submission still accepts the prohibited line. The merchandise owner may approve a suitable alternative, but the shopper's choice and any price or entitlement difference must be handled under the agreed policy.
The launch decision is between delaying all countries and opening only verified routes. Restricted shipping can preserve useful availability, but only if exclusion is enforced at the point of commitment and clearly explained. It adds support complexity and may reduce recipient choice. A global delay is simpler to communicate but postpones otherwise ready markets. Neither option is automatically best.
Acceptance for the restricted option requires passing destination-boundary tests, reconciled payment and order records, a working exception queue, and approval of the limited scope. The excluded route receives a named owner and a retest trigger. A later successful carrier test does not silently expand launch authority; the owner reviews the updated evidence and scope first.
Rehearse a launch freeze and keep the evidence usable
Before launch, run a short rehearsal with a deliberately unresolved critical defect. Confirm who can stop new intake, who communicates the restriction, and who reconciles orders already committed. Stopping a storefront does not erase payment obligations or shipments already in motion. Keep the recovery procedure separate from a broad instruction to “roll back everything.”
What to do when a critical defect appears
Freeze the affected launch scope. Preserve the exact build, request identifiers, and observed state. Assign a responsible owner. Reconcile uncertain transactions before retrying. Correct the authorized defect, rerun the failed case and affected neighboring cases, and obtain a fresh human decision. Keep the original failure and do not mark the case passed while a required dependency remains unavailable.
Use this final operational checklist:
- Confirm the launch definition and excluded audiences or destinations.
- Match the workbook to the exact build and configuration versions.
- Open the evidence behind every pass and every closed defect.
- Verify that no critical failure, unknown transaction, or unowned exception remains.
- Confirm support coverage, escalation contacts, and the intake-stop procedure.
- Record the authorized decision, its scope, date, and next review trigger.
If the project is replacing an existing store, use the company store migration guide for cutover and legacy-state planning. This launch workbook does not replace inventory migration, balance reconciliation, or URL-transition controls. It tests the intended post-change journey; a migration plan must also account for the old system.
Review the workbook quarterly and after material changes to products, eligibility, payment handling, destinations, or integrations. Keep completed runs as dated evidence instead of repeatedly overwriting one shared file. Report test coverage and operational readiness separately from adoption, revenue, employee sentiment, or business impact. This template provides no measured uplift estimate.
Make the launch decision traceable
Separate the test environment from the evidence environment. A screenshot taken in a sandbox can prove how that sandbox behaved, but it does not establish that production has the same configuration. Before the launch decision, compare the relevant configuration identifiers, enabled products, audience rules, payment mode, and destination restrictions. Record any differences and the additional authorized checks needed. Do not copy real payment credentials or personal addresses into the workbook to make this comparison more convenient.
The decision owner also needs a practical coverage statement. Name the browsers, devices, assistive technologies, payment routes, and shipping destinations actually exercised. Describe the basis for choosing them, such as the approved audience and supported implementation, without inventing traffic data. An untested route should remain untested even when a similar route passed. Where a narrower launch is proposed, document how the untested route is prevented from accepting orders and how support will explain the limitation.
Finally, distinguish a corrected defect from a changed requirement. A correction makes the agreed behavior work; a requirement change alters what the organization intends to permit. Both can be legitimate, but the second needs a new scope decision and corresponding tests. For example, removing a destination after a failed shipment is not evidence that the destination was repaired. It may support a restricted launch if the exclusion is tested and authorized. Preserve the original failure, the revised scope, and the condition for reconsidering the excluded route. This keeps a useful operational compromise from becoming a misleading success claim.
The useful output is not a green dashboard. It is a reproducible chain from approved scope to test action, observed result, defect resolution, and authorized decision. A small store with clear boundaries and recoverable failures may be safer to operate than a broad launch supported only by a successful demonstration. Choose scope based on verified evidence and the organization's actual capacity to handle exceptions.
For teams considering Giftpack's documented company-store and merchandise capabilities, this same matrix can structure implementation discussions. Confirm the supported audience controls, payment arrangements, inventory responsibilities, and destination-specific fulfillment before testing; do not infer an integration or compliance guarantee. A focused enterprise program discussion can help translate the approved scope into an execution plan, while your organization retains the launch decision and its legal, tax, privacy, and employer responsibilities.