Choosing a B2B eCommerce Agency: A Guide for New Zealand Retailers

Choosing a B2B eCommerce agency is a significant investment decision for a New Zealand retailer. The partner you appoint may shape how trade customers see negotiated prices, purchase for different branches, order on account and receive goods. The quality of the website matters, but so does the operating model behind it.

A strong proposal should make that operating model understandable. You should be able to see which requirements have been confirmed, where the agency needs more information, what the investment includes and who will resolve problems after launch. A polished portfolio cannot answer those questions on its own.

This guide is for NZ retail owners, executives, eCommerce leaders and technology teams preparing to shortlist a delivery partner. It provides a practical way to compare agencies against the same evidence, with particular attention to local fulfilment, finance processes, customer information and support coverage.

The objective is to appoint a partner that can deliver a suitable solution and help your team operate it. Start with your business requirements, then assess the platform, agency and implementation approach together.

Define the project before comparing agencies

Begin with a short statement of the problem you need to solve. Perhaps trade customers cannot see agreed prices online, staff rekey orders into the ERP, or a legacy portal makes routine changes expensive. Explain the operational effect and the decision the project must support. Avoid presenting a list of applications as though the solution has already been selected.

Describe the customers who will use the store: contractors, resellers, branch buyers or business customers who also shop in person. Record how they find products, confirm prices, choose a delivery location and obtain approval to purchase. Include the people who handle exceptions in sales, finance and the warehouse.

Separate mandatory requirements from improvements that can follow later. A reliable account price may be essential at launch, while a new merchandising feature can wait. This gives agencies a basis for challenging the scope without overlooking a fundamental operating need.

OSE’s broader agency-selection checklist covers the initial questions. For an NZ procurement decision, turn those questions into a common brief, evidence requirements and a documented evaluation. Our guide to eCommerce discovery workshops explains what an early discovery stage should resolve.

Give every agency the same NZ operating brief

A useful brief does not need to prescribe every screen. It should describe your current platforms, ERP and finance systems, product data, trade account arrangements, store network and delivery processes. Provide approximate volumes and complexity where they affect architecture, without sharing unnecessary personal information during shortlisting.

Include the New Zealand conditions that an attractive demonstration might miss. Ask how rural addresses, different North and South Island delivery zones, bulky goods, collection orders and branch stock will be represented where relevant. Treat these as scenarios to prove with your carriers and configuration, rather than assuming they come with an eCommerce platform.

Have finance define the expected customer-facing documents and reconciliation process. Inland Revenue’s taxable supply information guidance explains the current GST record-keeping framework; businesses can still use documents labelled ‘tax invoice’. Ask the agency to work with your finance team to validate the chosen workflow, not to make tax decisions for the business.

If you sell across the Tasman, state which entity owns each sale, which currencies and stock pools apply, and whether customer accounts are shared. Describe the intended model before asking agencies to price it. An NZ-only trade portal and a shared AU/NZ operation can involve different decisions even when their product ranges overlap.

Compare agencies using evidence rather than presentation quality

Choose your evaluation criteria before reviewing proposals. Otherwise, a strong pitch can shift the discussion towards whichever features a supplier happens to demonstrate well. Weight the areas that most affect your operating risk and the outcomes you need.

The New Zealand Government Procurement evaluation guidance offers a useful reference for structured scoring. Private retailers do not automatically have to follow government procurement processes. The practical principle is to decide how evidence will be assessed and apply the same approach to each supplier.

The following is an illustrative OSE starting point, not a prescribed industry model. Adjust it before issuing the brief. Score each area from zero to five, record the reason and calculate its weighted contribution. Keep mandatory conditions separate: a high overall score cannot compensate for an unresolved requirement the business cannot operate without.

Evaluation area	Example weight	Evidence to request
B2B workflow and NZ operating fit	25%	Demonstration against your account, delivery and finance scenarios
ERP integration and data ownership	25%	Data flows, connector coverage, failure handling and named owners
Delivery team and relevant experience	20%	Named roles, comparable work and reference discussions
Scope, investment and assumptions	15%	Comparable inclusions, exclusions and ongoing costs
Support, governance and handover	15%	Coverage commitments, escalation, access and exit arrangements

Use score differences to identify follow-up questions rather than manufacturing precision. A supplier marked down for unclear integration ownership might resolve that uncertainty with a better scope. A supplier that cannot demonstrate a mandatory pricing arrangement presents a different kind of gap.

Test the delivery team and its relevant experience

Ask who will actually lead discovery, design the integration, build the storefront and support the launch. Establish how those people participate in the proposal and how substitutions will be handled. Credentials can help you build a shortlist, but they do not establish that the proposed team has understood your project.

Request examples with comparable complexity rather than simply a recognisable retail brand. A useful reference might involve branch accounts, negotiated trade prices, a large technical catalogue or a similar ERP. Ask what the agency itself delivered, which partners were involved and what remained the retailer’s responsibility.

Speak with references about delivery and operation. What assumptions changed? How were exceptions handled? Could the retailer manage routine content and pricing changes? Did the support team understand the integration after launch? Ask for permission before expecting a supplier to disclose confidential project information.

The NZ procurement due-diligence guidance recommends independently checking supplier capacity, capability and proposal assumptions. Apply checks proportionate to your investment and risk. A relevant reference discussion and a review of the named team can be more useful than collecting another page of promotional claims.

Require a demonstration using your trade transactions

Give shortlisted agencies a small, consistent set of transactions before a demonstration. Include an ordinary trade buyer, an account with negotiated prices, a buyer purchasing for a different branch and an item sold in packs. Add one delivery or payment exception that regularly needs staff assistance.

Follow each journey from sign-in to the order received by the back office. Check product access, unit of measure, account price, stock promise, purchase order reference and delivery choice. Ask the agency to identify what is working software, what is configured for the demonstration and what remains a proposed development.

Request a written capability map separating native platform features, third-party applications, connector functions and custom work. If Shopify is proposed, our NZ guide to Shopify B2B plans helps frame questions about plan entitlements. A feature name is not sufficient evidence that your full workflow is supported.

A failed or incomplete demonstration can still be useful if it exposes a decision early. Record the gap, the proposed resolution, its cost implications and how it will be tested. Avoid accepting a vague promise that an important exception will be straightforward once development begins.

Establish who owns the ERP connection and its failures

An agency proposal should identify the owner of each important data set and business action. Specify who maintains products, customer identities, account prices, stock availability, payment terms and fulfilment updates. Then establish how the eCommerce platform receives or changes that information.

Ask the agency and ERP provider to review the boundaries together. An integration partner may own the connector while the agency owns the storefront, but someone still needs to coordinate an order that passes one system and fails in another. Your retailer should not become the default messenger between suppliers during an incident.

Agree what monitoring detects, who receives alerts, what evidence support can inspect and how a failed transaction is corrected. Include duplicate-order prevention and reconciliation. Define who approves any manual action that can change a customer balance, stock record or order status.

Use an acceptance scenario where an order is delayed or rejected, not only one where everything succeeds. A useful agency will explain the operational recovery process in plain language. OSE’s guide to ERP integration failures and recovery provides more detail on the questions to resolve.

Assess NZ support coverage and customer-data handling

Agency location is one consideration; the delivery and support arrangements need their own assessment. A New Zealand or Australian team should be able to state which hours it covers in NZ local time, how daylight-saving changes are handled and who responds during an important trading period. Do not infer those commitments from an office address.

Distinguish initial response from investigation, workaround and resolution. Agree severity definitions, escalation contacts and the role of platform, hosting, payment and ERP vendors. Include the customer-service and finance teams in planning an incident that interrupts account ordering.

For customer information, ask where production data and backups are stored, which suppliers and subcontractors can access them, and what happens in development environments. Start demonstrations with synthetic or appropriately de-identified records. Require a documented access and deletion process for project and support personnel.

The Office of the Privacy Commissioner distinguishes overseas disclosure from a provider storing or processing information on your behalf in its guidance on sending information overseas. The distinction depends on the arrangement, not simply the supplier’s country. Have the appropriate privacy or legal adviser assess your data flows and contract terms rather than assuming all offshore processing is prohibited or automatically acceptable.

Make proposals comparable before choosing the price

Create a common commercial schedule covering discovery, design, platform configuration, migration, integrations, testing, training, launch and support. Ask each agency to mark what is included, excluded, provisional or dependent on further discovery. A headline price is not comparable if one proposal excludes essential back-office work.

Request the billing currency, treatment of applicable taxes, payment milestones and the assumptions behind ongoing subscriptions. Present management with a consistent NZD planning view and an explicit exchange-rate assumption where needed. An NZD implementation quote may still depend on applications or platform fees billed in another currency.

Make internal work visible. Product-data cleanup, customer-account decisions, pricing approval and user testing require people from your business. Ask which delays would affect the programme and how changes to scope will be estimated and approved. Paid discovery should produce agreed outputs you can evaluate, not merely a commitment to the next project stage.

Compare ownership costs over a planning period suited to your business. Include support, applications, integration maintenance and expected change activity. Avoid treating an optimistic revenue forecast as certain payback. Your investment case should explain the assumptions and the evidence you will collect after launch.

Agree acceptance, handover and an exit path

Before signing, connect each mandatory requirement to an acceptance test and a responsible reviewer. Include pricing accuracy, order reconciliation, account permissions, delivery handling and the ability to perform routine administration. Specify the evidence needed to accept a release and the process for handling unresolved defects.

Your business should understand which accounts it owns or controls, how repositories and deployment access are managed, and what documentation will be maintained. Clarify rights to custom work and restrictions attached to licensed software. Arrange appropriate contract review rather than assuming every asset transfers automatically.

Define the handover even if you expect a long relationship. Ask what documentation, data exports, access transfer and assistance would be available if the engagement ended. Distinguish a reasonable transition service from an arrangement that leaves the retailer unable to operate without a particular individual.

OSE’s support agreement checklist develops these operational questions. The goal is a workable relationship with clear responsibilities, where both sides understand what is included and how future decisions will be made.

Use the shortlist to make a defensible appointment

Consolidate the evidence into a short decision paper: the preferred supplier, reasons for selection, unresolved conditions, delivery risks and approved investment assumptions. Record why the alternatives were less suitable. This helps stakeholders understand the decision and gives the delivery team a useful starting point.

Before launch, establish a baseline for the problems the project is meant to address. Measures might include manually handled orders, pricing exceptions, active trade buyers, reconciliation effort or support requests. Review those measures after launch alongside customer feedback, without treating feature adoption as proof of incremental revenue.

OSE’s perspective is that agency selection should test how a team investigates and manages your operating requirements, not merely how confidently it recommends a platform. A clear explanation of a difficult trade-off can be more valuable than an unqualified promise to deliver everything.

If you are preparing a B2B investment in New Zealand, talk to OSE about your requirements and shortlist process. Bring representative trade orders, an outline of your systems and the operational problems you want to resolve. That provides a practical basis for discussing the right scope and next step.

Frequently asked questions