Platform Selection
Part of Ecommerce vendor and agency evaluation
Running the same store scenario in several platform demos
Use one realistic store scenario across platform demos and record what was shown, documented or left unresolved.
Give every shortlisted platform the same store data, customer task and expected staff outcome. Ask each supplier to use the plan and configuration it proposes. Record what works in that setup and what still depends on later work.
Prepare one scenario pack
Use representative product rules with personal information removed. Include an ordinary item and a difficult one, such as a stocked size with an unavailable choice or a customer instruction that must reach fulfilment. Give every presenter the same intended AUD prices, delivery destinations and order-handling rule. Share the expected outcomes so each supplier has a fair opportunity to demonstrate them.
For example, the shopper selects an available size, sees an eligible delivery option, completes a supported test checkout and leaves an order staff can identify. Add one exception, such as an ineligible address or declined test payment.
Demo step / Result to capture
- Product setup
- Shopper choice and the item staff would supply
- Availability change
- Treatment of an unavailable choice
- Checkout
- Displayed total, eligible delivery and payment route
- Order review
- Item, instruction, payment state and next staff action
- Exception
- Customer message, staff record and resolution owner
Key Demo Steps and Expected Outcomes
- Product SetupShopper choice and item staff would supply (e.g., size availability, product variant selection).
- Availability ChangeHandling of unavailable size or option; system feedback and staff response.
- CheckoutCorrect total displayed, eligible delivery options shown, supported payment route available.
- Order ReviewItem, customer instruction, payment state and next staff action documented.
- Exception HandlingCustomer message captured, staff record created, resolution owner assigned.
Identify the environment and its limits
Ask which plan, theme or storefront, apps, gateway and connected services were used. Mark any step run in a sample environment. A prototype can show an approach, but the comparison must state what is required to reproduce it in the purchased setup.
Provider test environments have specific limits. Shopify client transfer stores support test orders through documented test payment routes, but cannot process real transactions before transfer to a paid plan. BigCommerce partner sandbox stores cannot process live transactions. These restrictions do not make a test useless; they limit what it proves about an Australian merchant's live payment account and delivery connections.
Record what each demo established
Use three states: shown, documented but not shown, and unresolved. For a shown result, record the environment, configuration and relevant screen or test order reference. For a documented claim, note the plan condition or feature that still needs checking.
Give each unresolved item an owner and a follow-up date. A verbal assurance is not a passed checkout result.
Keep the sequence and questions consistent. A supplier may use a different product route to reach the same required outcome; record its manual steps, apps and custom work. Send uncertain points for written clarification after the meeting.
The comparison should let the merchant judge required outcomes and their evidence. It should also identify which parts need configuration-specific acceptance checks before opening. A pre-purchase demo is evidence for selection, not a substitute for launch testing.
Demo Results: What Was Shown, Documented, or Unresolved
- ShownEnvironment, configuration and test order reference recorded for each platform demo.
- Documented but Not ShownFeature claims requiring further verification; e.g., custom app integrations or conditional logic not demonstrated live.
- UnresolvedItems needing follow-up with owners and agreed deadlines; verbal assurances not accepted as valid outcomes.
