“Connect the store to the ERP” is not enough scope for a reliable proposal. Which data moves in each direction, which system is authoritative and how will operations continue after a failure? Without those answers, a technically working connection can still leave stock and order conflicts. Treat the integration as a business-rules project before treating it as data movement.
Write scope by data group and direction
These are scoping questions rather than prescribed directions. Complete them according to the actual ownership model of your systems.
| Data group | Scope question | Acceptance example |
|---|---|---|
| Product | Where are codes and variant mappings managed? | The correct record receives the intended data |
| Stock | How are warehouses and saleable quantity calculated? | Reserved and available stock remain distinct |
| Price | Which list applies to which customer? | Discount and currency appear correctly |
| Order | At which stage is an ERP record created? | The same order is not created twice |
| Cancellation and return | Which state affects stock and collection? | Returns and cancellations are handled separately |
| Customer | How are identity and address relationships preserved? | Records do not attach to the wrong customer |
Choose update timing around business needs
Not every field needs an immediate transfer, while delays in some stock or order states can affect operations. Define acceptable timing by data group. Avoid using “real time” as an unmeasurable general promise.
Shopify's webhook documentation explains that event ordering and delivery are not guaranteed in every situation. When using such a mechanism, plan reconciliation and additional checks too. Receiving one notification does not establish permanent synchronisation of every record.
Make errors and retries understandable to operations
Imagine an order reaching the ERP while the connection fails before a response returns. Retrying should not create another order. This hypothetical case needs the order identifier, transfer state and repeat-processing rule to work together.
An error list should show the affected product or order, required action and owner, rather than only a technical code. Explain how corrected records are resubmitted and verified. An operation that must message a developer for every routine issue may be difficult to sustain.
Test more than one successful example
Select scenarios such as a new product, variant update, stock change, partial return, incorrect address and repeated delivery. Ensure test data does not create real sales or accounting outcomes. Compare source and destination records rather than relying on a success message.
Assign ownership for credentials, system updates and field changes after launch. Integration maintenance belongs in the agreed scope. The business should understand where information is managed and what happens when the connection fails.