The ecommerce platform sends orders to the ERP. The connection is active, requests receive a response and records appear in the destination system. If the technical exchange is all that gets reviewed, the integration works.
Before an order can be processed, however, someone downloads a spreadsheet, checks the product references, corrects several codes, compares the totals and emails another department when an address is incomplete. They then return to the ERP, edit the data and manually mark the order so it can continue.
When something fails, the incident is handled by email. If the same order enters twice, someone deletes the duplicate. If it does not appear in the ERP, the team checks the ecommerce platform, payment provider and a shared spreadsheet until they discover where it was lost. The process eventually succeeds because several people understand its exceptions and know how to compensate for what the integration does not handle.
From an operational perspective, the process has not been automated. Its most visible stage has been automated, while the rest remains dependent on manual checks, informal knowledge and corrections that are difficult to measure.
An integration cannot be assessed only by asking whether it transfers data. The business needs to know whether the complete process reaches the right outcome, whether failures are detected, whether exceptions have a defined path and whether each transaction can be understood without reconstructing it manually.
Technical success and operational success are different outcomes
Technical success answers necessary questions. Can the ecommerce platform connect to the ERP? Can both systems authenticate? Is the information sent in the expected format? Does the API respond? Is a destination record created?
Operational success asks different questions. Can the order continue without unnecessary intervention? Is the data suitable for invoicing, fulfilment or service delivery? Are failures detected before they affect the customer? Can the team resolve an exception without damaging other records? Do the systems ultimately agree?
An integration can pass every technical test and fail those operational checks. The order reaches the ERP with an unknown product reference. The customer pays successfully, but the payment status remains pending. Stock is reduced in one system and not in another. A record is created without a field the next department needs to do its work.
In each case, the technical exchange has completed while the business result has not. The integration has moved the information and passed the problem to the next stage.
The real process is usually longer than the connection between two tools
An integration is often represented as a line between two systems: ecommerce and ERP, CRM and invoicing, or a form and a sales platform. That view is useful for understanding the architecture, but it does not describe the whole operation.
An order may begin in ecommerce and pass through a payment provider, tax validation, the ERP, stock management, logistics, invoicing, customer communications and analytics. It may follow different paths depending on the country, product type, payment method or availability.
Decisions and exceptions appear between those stages. What happens if payment is authorised but the ERP rejects the order? Which system holds the main reference? Can the order be sent again without charging the customer or reserving stock twice? Who decides whether incomplete data should stop the process or be corrected later?
Designing an integration requires following the process from its initial event to the result the business needs. The purpose is to keep operations moving reliably across every relevant system, decision and team.
Human involvement is not always the problem
Not every process should run without people. Some orders require commercial review, some operations need approval and some exceptions should not be resolved automatically. Human involvement adds value when it brings judgement, responsibility or a decision the system should not make alone.
The problem appears when a person becomes the permanent translator between tools. They copy data, correct formats, check that two figures match or remember how each type of failure should be handled. Their work exists because the integration does not preserve enough context or manage the real conditions of the process.
It helps to distinguish between three types of involvement:
- Necessary decisions: reviews, approvals and assessments that require human judgement.
- Controlled exceptions: less frequent cases that the system identifies, records and directs to the right person with the information needed.
- Compensating work: repeated tasks performed to correct, complete or verify what the integration should have handled.
Removing every human step may be the wrong goal. Reducing compensating work and making exceptions visible is usually more useful.
Traceability should make every transaction easy to follow
When a customer asks about a missing order, the company should be able to locate it using a shared identifier and understand its journey. It should know which system received it, which data was sent, what response came back, which transformations were applied and what state the transaction is currently in.
A technical record saying “error 400” may help a developer, but it may not tell operations which order is affected or what action is required. Likewise, recording only “order sent successfully” does not prove that the subsequent process completed.
Useful traceability connects technical information with the operational reality. It should answer at least these questions:
- Which specific transaction are we following?
- Where did it originate, and which identifiers does it have in other systems?
- Which stages have completed, and which one is pending?
- What data was sent, and what response was received?
- Was there a failure, retry or manual intervention?
- Who is responsible for the next action?
Without that connection, investigating an incident requires checking several platforms, searching through emails and comparing data manually. Operational time is then spent reconstructing a history the system should already retain.
Failure handling is part of integration design
A reliable integration is not designed on the assumption that every system will always respond on time and every data item will be valid. APIs become unavailable, credentials expire, suppliers change conditions, mandatory fields arrive empty and responses take longer than expected.
The relevant question is what happens next. The system may retry the transaction, place it in a queue, stop the process, notify a person or use a controlled alternative. The right choice depends on the type of failure and the consequences of repeating or abandoning the action.
A temporary connection problem should not be handled in the same way as an unknown product reference. The first might be resolved by an automatic retry. The second requires a master data correction or a decision about product mapping. Retrying it one hundred times will not make the reference valid.
Some errors do not technically stop the integration. An order can be created with the wrong amount, assigned to the wrong customer or released for fulfilment before stock has been reserved. These failures can be more dangerous because the process appears to have finished.
Validations therefore need to check the meaning of the transaction as well as its transmission. A successful API response confirms that the destination accepted a request. It does not prove that the result is operationally correct.
Retrying a transaction can create duplicates
When a request receives no response, the source system may not know whether the destination processed it. Sending it again can create two orders, issue two invoices, reserve stock twice or start two deliveries.
The operation needs to be designed so the destination can recognise it when it appears again. The receiving system should identify a request it has already processed or apply a rule that prevents the same action from running twice. Retries should also be recorded so the team can distinguish an automatic recovery from a new business event.
Duplicates are not always identical. Someone may correct a field and send the order again, producing two slightly different records that the system no longer connects. A manual process may also create the order in the ERP before the delayed integration delivers it hours later.
Preventing duplicates requires defining what makes a transaction unique, which system generates its identifier and how manual corrections interact with automatic retries.
Reconciliation checks that both sides still tell the same story
Even when each exchange appears to work, differences can accumulate between systems. Orders may exist in ecommerce but not in the ERP. Confirmed payments may remain pending. A return may be completed on one side and open on the other. Stock changes may never propagate.
Reconciliation periodically compares results that should match. It does not wait for an alert. It actively checks that transactions completed in one system have the correct equivalent elsewhere.
This can happen in real time, through scheduled checks or through a combination of both. The business needs to define what is compared, how often it is checked, which differences are acceptable and who resolves those that require action.
An integration without reconciliation can accumulate silent failures for weeks. The team discovers them when a customer complains, finance closes the period or physical stock no longer matches availability. By then, finding the cause is more expensive because many more transactions need reviewing.
Master data is often a major source of integration problems
In many projects, the connection mechanism is not the main issue. The systems do not agree on the data. Ecommerce uses one product reference, the ERP uses another and the warehouse knows the item by a third. Customer names vary, addresses use different formats and each system applies its own rules to tax, discounts or status values.
A spreadsheet mapping one set of values to another often becomes the temporary solution. That can be useful during a migration or controlled phase, but it becomes a risk when nobody knows who maintains it, which version is valid or what should happen when a new reference appears.
Before automating the exchange, the business needs to decide which system is the source of truth for each type of data, how new entities are created, who approves changes and how those changes reach the other tools. Historical and incomplete data also needs a defined treatment.
An integration does not improve data quality by itself. If it connects systems with conflicting definitions, it may distribute those conflicts more quickly.
Every exception needs an operational owner
An alert without an owner simply moves the problem. The integration may have detailed logs, automated emails and a dashboard full of incidents, but the process still depends on chance if nobody knows who should review each type of failure.
Operational ownership assigns responsibility for the outcome. For every critical stage, the company should know who monitors the process, who acts on an exception, when it needs to be escalated and who can make decisions about data or business rules.
The owner will not always be a technology team. A connection failure may require technical action, while an unknown product reference may belong to catalogue management and a tax condition to finance. The system should direct each exception to the team that can resolve it and include the context they need.
It is also useful to separate responsibility for resolving an individual incident from responsibility for preventing the same problem from recurring. If the team manually fixes the same exception twenty times and nobody reviews its cause, the operation continues by normalising failure.
What to measure to understand whether the integration really works
Counting successful and failed requests gives only a partial view. An integration may report a high success rate while still generating substantial manual work or downstream errors.
Operational assessment should consider measures such as:
- Transactions that complete without manual intervention.
- Exceptions by type, system and cause.
- Time spent by each transaction in a pending state.
- Retries and their final outcomes.
- Duplicates detected or removed manually.
- Differences found during reconciliation.
- Hours spent checking, correcting or re-entering data.
- Incidents discovered through alerts compared with those reported by customers or users.
These measures help distinguish an occasional issue from a structural weakness. They also guide priorities. The integration may not need rebuilding, but it may need better mapping, stronger traceability, safer retries or clear ownership of a recurring exception.
How to review an integration that appears to work
The review should follow real transactions from beginning to end. It should include ordinary cases, known exceptions and scenarios in which one system does not respond as expected. The team then observes what happens without filling the gaps with an assumption that someone normally handles them.
An initial review can be organised around six areas:
- End-to-end journey: from the event that starts the process to the business result required.
- Traceability: identifiers, states, records and the ability to reconstruct each transaction.
- Failure handling: classification, retries, alerts, escalation and recovery.
- Consistency: duplicates, reconciliation and master data correspondence.
- Human involvement: manual tasks, why they exist and the knowledge required to perform them.
- Ownership: the people or teams responsible for monitoring, correcting and improving the process.
The review should reveal where risk and work have moved. The problem may be a fragile connection. It may also be a spreadsheet that has become part of the system without being managed as one, an inbox used as an incident queue or a person reconciling information every day that should already match.
A strong integration reduces work and uncertainty
Automation creates value when the process can move forward, the system records what happened and exceptions follow a clear route to resolution. The business can understand what is working, what is pending and what needs attention without checking every transaction manually.
This does not require an unnecessarily complex architecture or the removal of every spreadsheet. It requires a design proportionate to the importance of the process and clear visibility of the dependencies currently handled informally by the team.
At Pibeca, we design and implement integrations and automation for critical systems around the complete process, its data, its exceptions and the operation that follows. In projects such as our Salesforce solution for sales and field service, traceability across teams and systems is part of the architecture.
If your integration transfers data while the team continues downloading files, correcting records or investigating orders one by one, we can help you identify where work and risk are being displaced.
The useful question is not simply whether the integration is active. It is whether the operation can rely on it without several people constantly watching what happens between systems.
Frequently asked questions about systems integration
How can an integration work technically and still fail operationally?
It may send and receive data as designed while producing incomplete, duplicated or unusable information for the next stage. It may also rely on manual corrections that do not appear in technical metrics. Assessing it requires reviewing the complete business outcome and the work people still perform.
Is it a problem if an integration needs human involvement?
Not necessarily. Some transactions need approval, judgement or review. It becomes a problem when someone mainly copies information, corrects formats, compares systems or compensates for repeated failures. Human involvement should add a decision or resolve an identified exception instead of acting as a permanent connection between tools.
What is the difference between monitoring and reconciliation?
Monitoring observes system behaviour and generates signals about errors, response times or unusual states. Reconciliation compares results across systems to confirm that they contain consistent transactions. An integration can show no technical errors and still require reconciliation to detect orders, payments or updates that do not match.
How can duplicate orders or records be prevented?
Each transaction needs a stable identifier, and actions should be designed to recognise requests that have already been processed. Automatic retries also need to be coordinated with manual corrections. Looking for completely identical records is often insufficient because the same transaction may be sent again with minor changes.
What should happen when one of the systems is unavailable?
The appropriate response depends on the process and transaction. The integration may retry, retain the request in a queue, pause the flow or notify someone. The chosen response should prevent data loss and stop the same action from being executed multiple times when the unavailable system returns.
Does an integration that creates too much manual work need to be rebuilt?
Not always. The first step is to identify the source of the work, such as weak traceability, inconsistent master data, unmanaged exceptions, unsafe retries or unclear responsibilities. Some integrations improve through targeted controls and corrections, while others need a deeper review of their architecture and the process they support.
