Website and ERP integration: a practical scoping checklist

Before connecting a website to an ERP or business system, agree which information moves, which system owns it and what the customer sees if the connection fails. Start with one useful flow whose behaviour you can test.

Define the first flow in one sentence

“Publish approved product descriptions to the website” is a scope you can investigate. “Integrate everything” leaves questions about prices, permissions, stock and orders unanswered. An enquiry transfer and a paid-order integration have different responsibilities even if both start with a form.

The provider, product version, licensed features, API or export access and available test environment must be checked first. Do not assume that because one business system supports a feature, another does too.

Decide which system owns each field

Scroll sideways if any columns are cut off.

A product showing “available” does not explain whether stock is reserved, counted across branches or safe to promise. Agree that meaning with the person who owns inventory. If the first release only supports enquiries, say availability is subject to confirmation instead of presenting a simulated live stock figure.

A worked enquiry handoff

Illustrative flow: a customer selects three catalogue items and sends an enquiry. The website records the request and returns a reference. A server sends the agreed fields to the business system. If acknowledged, the reference is linked to the system’s record; if unavailable, the team sees a pending transfer.

The customer sees “Enquiry received”, not “Order confirmed”. Price approval, stock reservation and payment have not happened in this example. A team member should be able to find the original enquiry even when the transfer needs attention.

Specify retries without duplicate records

A connection can fail after the receiving system has already saved something. Retrying blindly can create a duplicate. Ask the implementer how a stable request reference, the provider’s retry rules and reconciliation will prevent or detect that outcome.

As a concrete provider example, Stripe documents idempotency keys for its API. That is an example of a supported retry mechanism, not evidence your ERP implements the same one. Confirm the mechanism, limits and retention period for the exact API being connected.

Use this failure checklist before accepting the work

• The customer clicks twice, refreshes or retries after a timeout.
• The receiving system saves the record but its response never arrives.
• A product is removed, a price changes or a required field is missing.
• The connection is down, slow or returning an access error.
• A user tries to view another customer’s private price or order.
• A transfer fails repeatedly and needs a named person to resolve it.
• Service returns and pending work is reconciled without duplicate entries.

Agree what each case should display, what is retained and how the team is notified. Use a permitted test environment or controlled test records before involving real customer orders. Public pages should never contain system credentials; server access should be limited to the records and actions needed.

Budget for operation and handover

The connection needs an owner after launch. Write down who maintains source data, rotates credentials, handles provider changes, checks failures and restores service. Confirm ongoing provider fees, monitoring, backups and support separately from the visual website build.

Send this first brief: “We use [provider/version]. We want [information] to move from [source] to [destination] when [trigger]. [Team] owns the records. We have [documentation/test access], and customers should see [fallback] if it fails.” Share documentation links, not passwords. Discuss this specific integration with The Strategy; feasibility and price follow the access and scope review.