Digital commerce infrastructure: a business planning guide

A reliable information base comes before the next website or connector. Conflicting specifications, prices, stock figures and documents in separate spreadsheets will be reproduced across systems unless the business resolves them first.

Begin with one representative range. Distinguish a product, its saleable variants and each channel listing. Keep internal identifiers stable and record external identifiers as mappings. Use genuine existing GTINs or other identifiers where applicable; do not invent them to fill a field.

Give each important field an accountable source

Google Merchant Center's product data specification is one concrete channel example. Other platforms, markets and products need their own requirements review.

Company presentation, project enquiries and online purchases are different tasks. Establish how the customer understands the product, confirms suitability and continues the conversation before deciding which functions belong in the first release.

A manufacturer seeking export enquiries can start with an accurate catalogue, application information, downloads and enquiry records. Include checkout, payment, delivery and order handling when online transactions are part of the agreed business model.

Match the implementation to the journey

Test both customer use and internal maintenance

The team must be able to maintain products and pages and understand which changes need approval. Customers must find the correct model, current documentation and next action on mobile. An available admin button is not evidence that the business operation works.

Share approved product facts across languages and review the expression separately. If material is missing, state the available scope rather than treating an unrelated product as its translated version.

Before connecting a store, platform or product discovery channel, confirm access, mappings, responsibilities and current interface conditions. A connector's existence does not establish that every required business task is supported.

Define direction, timing and exception handling

Pilot one channel and one product range

Cover creation, modification, withdrawal, unavailable stock, rejected changes and failed connections. Record the source, submitted data, expected destination and actual outcome. After a successful response, check the channel interface and customer-facing page.

Available stock is a business definition. Warehouses, reservations, return inspection, backorders and channel delays require explicit decisions.

Describe the before and after of each business event

Include reconciliation and recovery in the scope

A business user should be able to trace one order through source, variant, payment, stock changes and fulfilment. When systems disagree, show the affected object, latest sync state and owner rather than relying on a complete re-import.

Automate clear rules first. Keep an accountable manual route for exceptions. Do not combine different currencies, payment states and fulfilment states into one ambiguous completion label.

Delivery to the business should mean usable rights. Agree ownership of the domain, hosting, accounts, data, source code or licences, integrations and third-party subscriptions before implementation.

Assign access by role rather than sharing one administrator

OWASP's authorization guidance includes least privilege, denial by default and permission validation on every request. Hiding a link on a login page does not prove that a file or another customer's record is protected. Test access boundaries with authorised material.

Distinguish ownership, licences and portable assets

Custom code, commercial software licences and third-party services are different assets. The agreement should state what the business receives, what remains usable after a subscription ends, what can be exported and what migration work is necessary.

Verify a usable data export, business-controlled accounts and a supplier exit process. Keep credentials out of public pages and ordinary shared documents.

Files, screenshots and demonstration accounts can support a review. Acceptance should use agreed business actions to establish that the team can operate, maintain, recover and migrate the system.

Specify inputs, expected results and evidence

Define sign-off beyond going live

List mandatory passes, exclusions, deferred issues and owners. For each test record inputs, expected and actual results, time and reviewer. Bound production tests; do not create evidence through confidential customer files, real charges or destructive actions.

Check analytics events, business records and notification receipt separately. A backup file is not proof of recovery, and an export button is not proof of usable migration data.

A promise to respond when something breaks is not a maintenance plan. Product changes, staff access, software updates, interface changes and exceptions all need an owner.

Agree the continuing scope and change boundaries

NIST's contingency planning guide can inform recovery plans and testing; using it does not establish certification. Agree acceptable interruption, recovery points and response arrangements from business impact and available resources rather than applying a generic promise.

Preserve evidence around changes

Record why the change is needed, affected products and workflows, approval, verification and recovery steps. After a store, interface or supplier migration, rerun a representative business journey rather than checking only the homepage.