Scayle and ZigZag
Integration Agency & Consultants
Cogent2 uses AI-powered delivery and operators who have managed high-volume returns to connect your commerce and logistics platforms. A proper integration between Scayle and ZigZag gives customer service and warehouse teams clarity on every return. This ensures faster refunds and accurate stock levels, protecting both customer satisfaction and your margins.
Scoping the multi-channel retail data architecture
Integrating Scayle and ZigZag enables swift connectivity, enhancing your multi-channel and omnichannel retail strategies. Our expertise ensures seamless system integration for unified retail experiences. Leverage our consulting and delivery skills to boost operational efficiency and tech stack performance. We provide comprehensive training to help you scale rapidly and effectively.
Solution Design
Designing the connection between Scayle and ZigZag requires a clear stance on data sequencing. In most implementations, Scayle remains the source of truth for the primary order and financial record, while ZigZag owns the logistics lifecycle and return status. We typically trigger a signal from ZigZag back to Scayle upon warehouse receipt to process customer repayments. A key trade-off involves inventory restocking: automating stock updates in Scayle reduces overselling risk but can lead to inaccuracies if items are later rejected during inspection. We often prioritises logistics flows first to stabilise the customer experience before refining automated inventory reconciliation. This approach ensures finance can close monthly books against verified Scayle figures while the warehouse team manages physical returns through ZigZag.
Syncing order records with return triggers
The integration creates a synchronised loop between Scayle order management and ZigZag logistics. Scayle typically acts as the source of truth for order data and customer records, which ZigZag uses to validate return eligibility. Once a return is initiated, ZigZag manages the carrier tracking and disposition status. In most implementations, when an item is processed at the warehouse, a refund trigger or credit note instruction flows back to Scayle. This sequencing protects data integrity by ensuring Scayle only processes refunds for verified, received items. We build monitoring into this flow to catch mismatched SKU identifiers and prevent orphaned returns that create reconciliation debt.
Orchestrating logic through an iPaaS layer
Cogent2 uses IPaaS to streamline Scayle and ZigZag integrations, enhancing data flow and connectivity. Benefits include faster deployment, reduced IT complexity, improved scalability, and seamless integration of diverse applications, enabling efficient management and innovation in digital transformation projects.
Eliminating financial reconciliation debt and exceptions
Standard dashboards usually mask the true cost of returns by only reporting successful flows. We focus on the exceptions: the 'stuck' returns where a customer has dispatched an item but Scayle has not updated the order status. These hidden failures compound into support backlogs and frustrated customers. Our approach surfaces these gaps early, highlighting discrepancies between the warehouse disposition in ZigZag and the financial status in Scayle. This provides the operations team with a clean view of what is in transit and what is being inspected. It identifies exactly where manual intervention is required to unblock a refund before the customer contacts support.
Operational handover for CX and finance
Handover focuses on how ecommerce, CX, and finance teams manage the returns lifecycle. We clarify ownership for each process: CX monitors return requests, while finance reviews refund reconciliation between Scayle and the billing systems. Your teams learn to check regular sync reports to identify potential issues like orphaned return labels or delayed refund triggers. Training covers how to interpret alerts, ensuring your team knows if a logistics delay is impacting a customer record in Scayle. We provide operational documentation written for the people running the business. This ensures the operating model is understood across departments, allowing for confident management of the post-purchase process once the integration is live.
Governance of the return to refund loop
Post-launch support focuses on the integrity of the return-to-refund loop. We monitor the integration for sync failures and stuck refund triggers, often identifying issues before they impact the customer. Escalation paths distinguish technical API errors from operational warehouse delays at the carrier or hub level. This oversight ensures that as volume grows, the integration remains stable. Our monitoring framework manages exceptions, reducing the need for manual oversight from internal teams.
Common failures
Inventory latency and overselling
Operational impact: A delay in updating Scayle with the correct stock disposition from ZigZag directly impacts resale. Resaleable stock is not returned to active inventory, causing stockouts on popular SKUs. Conversely, if damaged stock is incorrectly added back, the system oversells, leading to cancellations and workflow fractures that require manual intervention from CX teams.
Prevention: The integration logic must consume ZigZag's disposition data (e.g. resaleable, damaged, or quarantine) for each SKU and translate it into a specific inventory adjustment in Scayle. Using managed message queues ensures updates are processed sequentially, with exception handling to flag unrecognised SKUs before they halt the stock update flow.
Failed refund triggers and sync illusion
Operational impact: When ZigZag signals a refund is due but the action fails in Scayle, customers are left without funds. This creates a sync illusion where the return looks complete in the logistics portal but remains open in the commerce platform. The result is a spike in support queries and reconciliation debt for finance teams who must match ZigZag records against Scayle reports.
Prevention: Designing the refund process to be observable is critical. When ZigZag sends a signal, it should create an entry in a persistent queue. A worker process then attempts the refund via Scayle's API with retry logic for transient errors. Permanent failures should trigger an alert with the Sales Order ID for immediate investigation.
Return initiation blocked by product data mismatch
Operational impact: If product data is updated in Scayle but not synced to ZigZag, customers are blocked from registering returns. This data mismatch creates a frustrating experience where customers must contact support to manually bypass the automated workflow, increasing the cost per return and slowing down warehouse processing.
Prevention: Establish Scayle as the definitive source of truth for the product master. Scheduled processes should sync the active catalogue to ZigZag to keep SKU identifiers aligned. The integration also needs to propagate order status changes so ZigZag knows which line items are eligible for return based on their fulfilment status.
Frequently asked questions
How does the returns process work between Scayle and ZigZag?
A customer initiates a return through ZigZag, which handles the return logistics and grading of the item. Once the return is processed in the warehouse, ZigZag signals the outcome to Scayle, triggering the appropriate refund against the original sales order. Scayle then updates its inventory levels for the restocked SKU, making it available for sale.
What happens if returned stock isn't updated correctly in Scayle?
If ZigZag processes a return but the inventory level for that SKU isn't correctly incremented in Scayle, you will have inaccurate stock data. This commonly leads to overselling, forcing you to cancel a subsequent customer's order and creating a poor experience. Accurate stock sync is critical for protecting the integrity of the order-to-cash process.
How does this integration reduce our actual cost of handling returns?
The primary cost saving comes from automating the refund and restocking process, reducing manual intervention from your customer service or finance teams. Instead of manually cross-referencing a warehouse report from ZigZag and keying a refund into Scayle, the integration can automatically trigger the refund and update the SKU's stock level. This directly reduces labour costs and the potential for data entry errors.
Why would an automated refund from ZigZag fail in Scayle?
A common cause of failure is the expiration of the payment token associated with the original sales order in Scayle. If a return occurs many weeks after the purchase, the payment gateway's authorisation may be invalid for an automated refund. This failure requires the finance team to manually issue the customer's refund, often via gift card or bank transfer.
What if a customer returns an item for an SKU that no longer exists in Scayle?
This situation represents a common exception that the integration must be designed to handle. If ZigZag sends a return confirmation for a SKU that is deleted or inactive in Scayle, the automated stock and refund message will fail. This creates an exception that the operations or customer service team must resolve manually to ensure the customer is refunded and the physical item is accounted for.