Total Cost
Part of Ecommerce vendor and agency evaluation
Comparing implementation proposals by scope
Compare ecommerce agency proposals by deliverables, merchant dependencies, exclusions, acceptance criteria and quoted price boundaries.
Compare ecommerce implementation proposals by matching each quoted deliverable to the same required store outcome. Identify what each agency will hand over, what the merchant must supply and what sits outside the price. Quoted totals are comparable only after those boundaries are clear.
Build a scope comparison sheet
Use the brief sent to all agencies as the left-hand column. Include only the work this store needs. For each proposal, mark an item included, excluded, assumed or unclear, and retain the supplier's wording in the internal sheet.
Work package / Scope question to resolve
- Product data
- Who cleans, maps, imports and approves the records?
- Storefront
- Which pages, templates and mobile states will be delivered?
- Checkout
- Which payment and delivery combinations will be configured?
- Connections
- Which events and fields move between named systems?
- Acceptance
- Who writes cases, runs them, fixes defects and signs off?
- Handover
- Which documentation, access arrangements and staff training are included?
“Integrate accounting” is too broad to compare. Ask which systems and records are involved, whether later refunds and corrections are covered, and who resolves a rejected transfer. Treat unanswered points as unclear rather than filling them in from a diagram.
Compare the boundaries of the price
Separate one-off delivery, recurring software and support, and work priced only if an assumption fails. Keep the quoted currency, GST treatment, billing term and price validity date visible. If one supplier has priced a standard theme and another a custom design, show that difference before comparing totals.
Record merchant responsibilities and their dates. The agency may depend on clean product data, approved copy, payment account access or a carrier agreement. Those may be reasonable dependencies, but an unstated dependency makes the schedule hard to judge.
Ask what counts as a defect against agreed scope, what counts as new work, who can approve a change and how price or timing is revised. “Changes managed” does not explain that decision route.
Implementation Proposal Evaluation Metrics
- Quoted currency
- AUD
- GST treatment
- Included in quote (where applicable)
- Billing term
- Monthly / Fixed-term milestone payments
- Support SLA coverage
- As per supplier's published service levels
Define acceptance as an observable result
For each essential deliverable, agree on a result staff can inspect. “Checkout configured” might mean an eligible customer sees the intended delivery option, completes the supported test payment path and leaves a usable order. “Training provided” might mean the named team can update a product and handle a held order using the supplied guide. These are proposed acceptance criteria, not reported test results.
Keep the platform feature and the agency task separate. A built-in feature may still need configuration. An app or custom component adds setup, licence and maintenance questions. Mark an essential outcome that cannot yet be shown as an assumption or unresolved risk.
Resolve differences before selection
Send each agency a written list of unclear items. A clarification should explain what its existing proposal includes. If the answer changes scope, price or timing, request a dated revised offer and retain the earlier version. This prevents an apparent like-for-like comparison from hiding a changed commitment.
Choose on the scope that meets essential outcomes with acceptable risk and a usable handover. The final sheet should say who will do each task, what the merchant will supply and which requirements still lack a commitment.
