Launch QA

Launch QA proves that the console configuration produces the customer experience you expect on the public site. Run this guide before you point a production domain at the site, start paid traffic, announce a booking flow, or hand the workspace to an operator team.

Who Should Run This

Workspace owner

Confirms business details, policies, prices, operating hours, and launch approval.

Console operator

Verifies console setup, test customer actions, inbox handling, orders, bookings, and content.

Payments owner

Confirms Stripe Connect status, payout readiness, taxes, refunds, and dispute contact details.

Marketing owner

Confirms analytics, ads, conversion events, local profile links, redirects, and search previews.

Support owner

Confirms help content, contact routes, tickets, notifications, and escalation paths.

Launch Inputs

Collect these before testing:

• The workspace slug and production domain.
• The public site URL and console URL.
• The list of launch conversion paths: product sale, service booking, form intake, support ticket, newsletter signup, or phone call.
• The payment mode to use for validation.
• The email addresses and phone numbers used for internal test customers.
• The Google Analytics, Google Ads, and Google Business Profile properties expected to receive data.
• The operator team members who will handle the first day of activity.

Preflight Checklist

Test Data Rules

Use internal test customers whose names clearly identify launch QA. Do not mix launch test orders, bookings, tickets, or form submissions with real customer records unless the workspace owner has approved it.

For payment testing, use the safest available payment path. If the workspace is connected to live Stripe, do not submit a real charge unless the payments owner explicitly approves the amount, refund path, and accounting treatment.

Public Site Smoke Test

Commerce QA

Run this if the site sells products, packages, gift cards, memberships, deposits, or any shippable or digital item.

Choose the riskiest purchasable item for the first pass: a variant, limited-inventory product, shippable item, discounted item, or product tied to a campaign. That reveals more launch risk than testing the simplest product.

Console Setup

Products

Product names, descriptions, images, variants, inventory rules, price, tax behavior, and visibility.

Collections and navigation

Products appear in the intended shop sections and promotional blocks.

Shipping

Shipping zones, pickup options, rates, delivery estimates, and tracking expectations.

Checkout and tax

Currency, tax display, consent, coupon behavior, and post-checkout messaging.

Payments

Stripe Connect status, statement descriptor, payout account, refund owner, and dispute email.

Customer Path

1. Open the public shop.
2. Select a product with the most launch risk: a variant, shippable item, discounted item, or item with limited stock.
3. Add it to cart.
4. Edit quantity and confirm the cart total changes as expected.
5. Enter customer information.
6. Select shipping, delivery, or pickup.
7. Review taxes, fees, discounts, and total.
8. Complete or stop at the approved payment boundary.
9. Verify confirmation, order record, inventory impact, notification, and customer portal history.

Failure Checks

• A hidden product appears publicly.
• A visible product cannot be purchased.
• Checkout uses the wrong currency or tax behavior.
• Shipping appears for a non-shippable product, or no shipping appears for a shippable product.
• Inventory goes negative without an explicit business reason.
• The confirmation email or order page points at the wrong domain.
• Refund, cancellation, and fulfillment ownership is unclear.

Booking QA

Run this if customers can schedule services, appointments, classes, consultations, events, or paid reservations.

Test the service most likely to expose scheduling complexity: staff choice, add-ons, deposit, waiver, limited capacity, or external calendar conflicts. A simple free consultation can pass while the real launch service still fails.

Console Setup

Services

Name, duration, price, deposit, description, staff, capacity, location, and cancellation policy.

Scheduling

Availability, buffers, lead time, cutoff, overrides, holidays, and timezone.

Calendar integration

Provider connection, conflict behavior, and staff calendar mapping.

Intake and consent

Required forms, waivers, policy acknowledgment, and post-booking instructions.

Notifications

Customer confirmation, reminders, staff notifications, cancellation messages, and reschedule messages.

Customer Path

1. Open the public booking entry point.
2. Choose a service, tier, staff member, or location when those choices exist.
3. Select a date and time that should be available.
4. Confirm unavailable times do not appear.
5. Fill out intake fields and consent documents.
6. Complete or stop at the approved payment boundary.
7. Verify the booking record, customer record, calendar event, notification, portal entry, and manage-booking link.
8. Test one lifecycle action: reschedule, cancel, confirm, or mark complete.

Failure Checks

• Timezone display changes unexpectedly between console and site.
• Staff calendars are not blocking unavailable time.
• A paid service can be booked without the expected payment step.
• A free consultation asks for payment unexpectedly.
• Required intake or consent is skipped.
• The manage-booking link is missing or points to the wrong domain.
• Internal staff do not receive the operational notification.

Customer Account And Portal QA

Forms, Inbox, And Support QA

Run this for every live form and support path.

1. Submit the highest-priority contact or intake form from the public site.
2. Confirm validation errors appear for required fields before submission.
3. Confirm successful submission uses clear confirmation copy.
4. Open the console inbox or form submissions view.
5. Confirm the message is attached to the right workspace, customer, and source.
6. Reply or assign the item when that workflow is part of launch.
7. Confirm customer-facing email, ticket status, and internal notification behavior.

Content And Discovery QA

Integration QA

Integration QA proves that connected providers support the launch plan rather than merely accepting credentials. Test the provider state, the public customer effect, the console record, and the rollback path for each enabled integration before the site depends on that provider for money, attribution, local discovery, email, domain routing, or cache freshness.

Stripe Connect

• Account onboarding is complete.
• Charges, refunds, payouts, disputes, statement descriptor, and receipt behavior have an owner.
• Product and booking payment paths use the intended connected account.
• No test data or disabled payment method is visible on the public site.

Google Analytics

• The correct property is connected.
• Page views fire on homepage, shop, product, booking, help, and content pages.
• Conversion events fire only after the intended customer action.
• Internal QA traffic is filtered or understood before launch reporting starts.

Google Ads

• Conversion labels match the launch campaign objective.
• Booking conversion events map to the right campaign.
• Product sale, form, phone, and lead objectives have a documented validation path before ads go live, even when they do not emit a Google Ads conversion event yet.
• Landing page URLs are production URLs.
• Ads are not enabled until the destination passes this checklist.

Google Business Profile

• Website, booking, phone, service, location, and business hours links match the public site.
• Review links point to the right profile.
• Local landing page and profile information do not contradict each other.

Confirm that any campaign, review request, or local profile link sends customers to the production URL rather than a preview, old domain, or generic homepage when a deeper booking or service page is expected.

Domain, Email, And Webhooks

• DNS resolves to the production site.
• Customer email links use the production domain.
• Webhook endpoints are pointed at the correct environment.
• Revalidation or cache refresh events update the public site after a console save.

After saving a visible console change, reload the affected public route from the production domain. That proves DNS, routing, webhook delivery, cache invalidation, and customer-visible rendering are aligned.

Operator Console QA

Before handoff, each operator should complete the work they own:

1. Front desk

   Must be able to do: Find a customer, read booking status, reschedule, cancel, and message the customer.

2. Commerce

   Must be able to do: Find an order, update fulfillment, issue a refund, and answer a customer question.

3. Marketing

   Must be able to do: Publish a content update, check discovery health, and verify analytics.

4. Support

   Must be able to do: Handle inbox items, tickets, forms, and escalations.

5. Owner

   Must be able to do: Review revenue, bookings, customers, integration health, and launch risk.

Launch Decision

Do not launch until every launch-critical workflow is either:

• Passed.
• Deferred with explicit owner approval.
• Disabled from the public site.

Record the launch decision with:

• Workspace name and domain.
• Date and approver.
• Conversion paths tested.
• Known exceptions.
• Rollback owner.
• First-day monitoring owner.

Rollback Checks

Know how to reverse these changes before making them:

• DNS cutover.
• Paid ads activation.
• Public navigation links to checkout or booking.
• A new product, service, or form launch.
• Email sender change.
• Integration webhook destination change.

If a customer-impacting launch issue appears, stop traffic first, then fix console configuration, then retest the affected customer path.