Draw the journey of a piece of information
Connecting a shop or marketplace to an ERP starts with a concrete question: what information must move, between which tools, and to enable what action? A useful diagram follows a product, an order and a return from beginning to end. It also shows human interventions, approvals and situations where an operation must wait.
Consider a fictional distributor selling through its website and preparing orders in a warehouse. Several suppliers provide catalogue data, while a business tool manages inventory. The first release might publish a validated catalogue, transfer orders and return a delivery status. This example frames decisions; it does not describe an Innovancy client.
Assign a source to each piece of data
Create a table showing each field’s source, owner, recipients and update frequency. A catalogue tool might hold commercial descriptions, the ERP might calculate inventory, and a carrier might provide delivery tracking. One application does not need to own every piece of information.
Avoid letting two systems change the same field without a priority rule. If a price is corrected in the shop and replaced by an import minutes later, the team should understand whether that is expected. Document permitted manual overrides and their duration. An exception should not become an invisible operating rule that survives after its original purpose disappears.
Stabilize catalogue identifiers
Products and variants need consistent recognition throughout the journey. Choose the identifiers that match supplier references, internal items and published offers. Colour or size can affect stock, price or lead time, so represent variants explicitly when the commercial process requires it.
Prepare a representative sample before a full import: a simple item, several variants, an incomplete reference, a missing image and a discontinued product. A data dictionary defines formats, units and accepted values. This preparation addresses ambiguities that a technically working connection cannot resolve by itself. Include the people who maintain these values in the review.
Define what available inventory means
The quantity shown online may differ from physical stock. It may account for reservations, safety stock, several warehouses or units already committed to another channel. The rule must be calculable and shared by commercial and operations owners. Specify what the storefront displays when an expected update does not arrive.
Update frequency depends on business risk and available interfaces. Scheduled updates may be adequate for some catalogues, while other situations need faster reactions. Real-time synchronization should follow a demonstrated need, not a marketing slogan. Assess API limits, volumes, processing time and monitoring before committing to the desired frequency.
Treat an order as a sequence of states
Describe the stages that make an order actionable: received, payment checked under the selected arrangement, accepted, preparing, dispatched, then delivered or closed. Each transition needs an identifiable source and destination. The customer-facing label does not need to expose every technical warehouse status.
Use stable identifiers for orders and significant events. Repeated notifications after an interruption should not reserve stock or create preparation work twice. Split shipments, amendments and unavailable products deserve separate scenarios. These decisions are easier to make before launch than while a customer is waiting for an explanation.
Plan exceptions and recovery
Test cancellation before preparation, partial delivery, a return and an unknown reference. Specify who can intervene and what information should return to the other tools. Automation should not turn a local error into an unexplained series of changes across the business.
Retain the traces needed to recover an operation without duplicating personal data everywhere. A monitoring view can show its identifier, stage, last successful exchange and expected next action. A documented retry queue should replay only what is missing. Define when a flow must stop because data quality or the availability of another service is insufficient.
Check interfaces and operational ownership
A connection depends on each tool’s version, hosting, permissions and actual exposed capabilities. Verify authentication, volume limits, error formats and a way to test without disrupting operations. An existing connector can help, but its product name alone does not prove coverage of your scenario.
The business needs to know who owns accounts, renews access and monitors API changes. Identify licences, subscriptions and carrier or payment contracts that remain its responsibility. These dependencies belong in the proposal and maintenance arrangements alongside implementation. Also agree on a contact for incidents that affect several suppliers, so ownership does not disappear between systems.
Launch a pilot with observable criteria
Begin with a product subset and one complete order journey instead of every reference and channel at once. Compare information at key stages: published price, available inventory, received order, preparation and delivery. Assign a business owner to confirm that the outcomes reflect the team’s actual work.
Innovancy can scope a shop, ERP or application independently and then assess useful connections. Bring sample files, inventory rules and an anonymized representative order. The pilot should support a decision: continue, correct a rule or reconsider a tool. It does not replace acceptance testing or arrangements for operational support after release.
