{ "$schema": "https://www.ecirql.com/schemas/agent-data.v1.json", "generated_at": "2026-05-20T07:03:20.197Z", "site": "https://www.ecirql.com", "organisation": { "name": "Cirql Works", "legal_name": "Cirql Works Ltd", "trading_name": "eCirql", "country": "GB", "city": "Manchester", "website": "https://www.ecirql.com", "email": "contact@ecirql.com", "linkedin": "https://www.linkedin.com/company/ecirql", "product": "https://patchbuddy.ai", "summary": "UK ecommerce consultancy. Certified Patchworks Partner Agency, NetSuite consultancy and AI enablement partner. Builders of PatchBuddy, the world's first AIiPaaS." }, "services": [ { "slug": "patchworks-integration", "name": "Patchworks integration", "url": "https://www.ecirql.com/services/patchworks-integration/", "summary": "Certified Patchworks Partner Agency. We design, build and support Patchworks process flows end to end.", "intro": "Cirql Works is a certified Patchworks Partner Agency. Our team works in Patchworks daily, designing and shipping process flows that survive their first peak." }, { "slug": "ai-enablement", "name": "AI enablement", "url": "https://www.ecirql.com/services/ai-enablement/", "summary": "We add AI to systems you already run. Function calling, RAG, agentic workflows in production.", "intro": "AI enablement is integration work, with AI in the loop. We help businesses ship production AI against the systems already running their operation, not run another pilot." }, { "slug": "bespoke-integration", "name": "Bespoke integration", "url": "https://www.ecirql.com/services/bespoke-integration/", "summary": "If the systems exist, we will connect them. REST, SOAP, GraphQL, EDI, SFTP and custom.", "intro": "Bespoke integration is what we do when the systems are not on a marketplace connector list and somebody still needs them talking to each other." }, { "slug": "netsuite-consultancy", "name": "NetSuite consultancy", "url": "https://www.ecirql.com/services/netsuite-consultancy/", "summary": "SuiteScript, RESTlets, SuiteQL, custom workflows. We advise, scope and ship.", "intro": "NetSuite is a substantial part of our practice. We advise, scope and ship NetSuite engagements end to end, alongside or in place of in-house Oracle teams." }, { "slug": "support-retainers", "name": "Support retainers", "url": "https://www.ecirql.com/services/support-retainers/", "summary": "A flexible way to keep us close to your team. Monitored flows, on-call engineers, tiered SLAs. From £750 per month.", "intro": "A flexible way to keep us close to your team, with the reassurance that integration issues won't slow your business operations down." }, { "slug": "integration-audit", "name": "Integration audit", "url": "https://www.ecirql.com/services/integration-audit/", "summary": "Fixed-fee independent review of your integration estate. £1,500, ten working days, PDF report and follow-up call. Credited in full if you commission project work with us within thirty days.", "intro": "A productised, fixed-fee audit of an existing integration estate. Independent, written up, delivered in ten working days, and structured so the audit fee turns into project budget if you move forward with us." } ], "platforms": [ { "slug": "aero-commerce", "name": "Aero Commerce", "category": "Ecommerce", "url": "https://www.ecirql.com/platforms/aero-commerce/", "summary": "Fast headless ecommerce platform for mid-market retailers.", "description": "Aero Commerce is a UK-built ecommerce platform with a headless architecture, popular with mid-market retailers who want more flexibility than a SaaS storefront gives them but less ongoing burden than a fully bespoke build. It is built on Laravel and exposes a clean PHP and REST API surface that engineers can extend without fighting the framework.\n\nPatchworks connects Aero Commerce via its REST endpoints, with orders, customers, products and stock the typical entities crossing the line. The interesting integration work is usually around the storefront-side customisations Aero allows: bespoke pricing logic, B2B account behaviours and content models that need to flow consistently between Aero and the ERP, PIM or marketing stack.\n\nOur team has shipped Aero integrations from end to end, including the migration work that often comes with adopting Aero in the first place.", "featured": false }, { "slug": "airtable", "name": "Airtable", "category": "Data & BI", "url": "https://www.ecirql.com/platforms/airtable/", "summary": "Collaborative platform combining spreadsheet and database functionality.", "description": "Airtable sits between a spreadsheet and a database. Operations teams use it as a lightweight system of record for things that do not deserve a full application: supplier onboarding workflows, content production trackers, returns triage, campaign briefs. The API is generous, the rate limits are not, and views can mask the shape of the underlying data in ways integrations need to handle carefully.\n\nPatchworks integrates Airtable via its REST API. Typical flows push data into Airtable from an ERP, ecommerce platform or marketing tool so operations teams can act on it in the surface they already use, and pull updates back out so changes do not stay trapped in a side system.\n\nMost Airtable integrations earn their keep by closing the loop between an operations team's spreadsheet and the systems that fulfil what the spreadsheet promises.", "featured": false }, { "slug": "akeneo", "name": "Akeneo", "category": "PIM", "url": "https://www.ecirql.com/platforms/akeneo/", "summary": "Centralised product information management for digital catalogues.", "description": "Akeneo is an enterprise-grade PIM, open source at its core, used by mid-market and large retailers to centralise product data across catalogues, locales and channels. The model is opinionated: families, attributes, categories and channels. Getting the model right is the integration work.\n\nPatchworks connects Akeneo through its REST API and standard import jobs. Outbound, Akeneo syndicates products and media to ecommerce platforms, marketplaces and DAMs. Inbound, supplier feeds, ERP item masters and translation services keep Akeneo current. The wrinkles are usually in the rules: which channel sees which attribute, how locale fallbacks work, when a variant axis changes meaning across families.\n\nWe design the syndication rules with the merchandising and product teams, not just the data engineers, so the PIM ends up matching how the business actually sells.", "featured": true }, { "slug": "algolia", "name": "Algolia", "category": "Search & Merchandising", "url": "https://www.ecirql.com/platforms/algolia/", "summary": "Fast and relevant search for websites and applications.", "description": "Algolia is hosted search. It runs the on-site search and merchandising surface for a long list of mid-market and enterprise retailers, with InstantSearch on the front end and a managed indexing pipeline behind it. The trade-off is that the search experience is only as good as the index, and the index is only as good as what you push to it.\n\nPatchworks pushes products, variants, prices, inventory state and ranking signals into Algolia from ecommerce platforms, PIMs and ERPs. Reindex cadence, partial updates and synonyms live alongside the product feed work. Conversion events flow back into Algolia for ranking and personalisation when those features are licensed.\n\nMost search integrations live or die on the index schema. We design that schema in the open, with the merchandising team in the room.", "featured": false }, { "slug": "amazon-seller-central", "name": "Amazon Seller Central", "category": "Marketplaces", "url": "https://www.ecirql.com/platforms/amazon-seller-central/", "summary": "Central hub for managing product sales on Amazon marketplace.", "description": "Amazon Seller Central is the merchant surface on top of Amazon's marketplace and one of the most fee-sensitive, dispute-heavy operational systems any retailer touches. The SP-API is comprehensive and unforgiving: throttled, region-segmented, with quirks that change without ceremony.\n\nPatchworks integrates Seller Central through SP-API for listings, inventory, orders, fulfilment notifications and settlement reports. Typical flows push product feeds from a PIM, sync inventory from a WMS, write order acknowledgements back from the ERP and reconcile settlement against finance. FBA and FBM accounts behave differently and usually need separate flow designs.\n\nThe work that adds the most value here is the dispute and reconciliation surface: matching settlement transactions to orders, working out where fees landed, and feeding it back to finance in a shape they can close on.", "featured": true }, { "slug": "avasam", "name": "Avasam", "category": "Other", "url": "https://www.ecirql.com/platforms/avasam/", "summary": "UK dropshipping platform connecting retailers with suppliers.", "description": "Avasam is a UK-based dropshipping marketplace that connects retailers with verified suppliers, with the platform handling stock visibility, order routing, shipping and supplier billing. Smaller than the wholesale-marketplace incumbents but well-suited to UK retailers that want a curated supplier base rather than a global one.\n\nPatchworks integrates Avasam for product feed ingest, real-time stock updates, order routing and shipment confirmations. The interesting work is usually on the retailer's ERP and ecommerce side, where dropship items need to behave operationally like own-stock items without confusing finance or fulfilment.", "featured": false }, { "slug": "bigcommerce", "name": "BigCommerce", "category": "Ecommerce", "url": "https://www.ecirql.com/platforms/bigcommerce/", "summary": "SaaS platform for building and managing online stores.", "description": "BigCommerce is one of the workhorse SaaS commerce platforms for mid-market and upper-mid retailers, with a generous API surface, headless support through Stencil and BigCommerce Catalyst, and enterprise features built in rather than bolted on. Multi-storefront and B2B Edition extend it into territory many platforms only fake.\n\nPatchworks integrates BigCommerce through its REST and GraphQL APIs. Sales orders flow out to ERPs and OMS, inventory and pricing flow in from ERPs and PIMs, customers move between BigCommerce and CRM and marketing platforms. Webhooks are reliable enough to anchor real-time flows on, which is not always true elsewhere.\n\nWe have shipped BigCommerce integrations across both standard and headless deployments, and the multi-storefront case in particular benefits from Patchworks's per-flow scoping.", "featured": true }, { "slug": "bleckmann-logistics", "name": "Bleckmann Logistics", "category": "WMS & 3PL", "url": "https://www.ecirql.com/platforms/bleckmann-logistics/", "summary": "Fashion-focused third-party logistics and fulfilment provider.", "description": "Bleckmann is a European 3PL with a strong focus on fashion and lifestyle brands. Warehouses across the UK, Netherlands, Belgium and beyond handle storage, pick-pack, value-add services and outbound shipments for clients that want a fashion-aware operations partner rather than a generic warehouse.\n\nPatchworks integrates Bleckmann's WMS for outbound order despatch, stock-level reconciliation, inbound goods receipt and shipping confirmations. File-based and API-based integrations both exist depending on the warehouse and contract. The interesting work is usually around bundles, kits and pre-pack work that fashion brands need but generic WMS integrations gloss over.", "featured": false }, { "slug": "bleckmann-returns", "name": "Bleckmann Returns", "category": "WMS & 3PL", "url": "https://www.ecirql.com/platforms/bleckmann-returns/", "summary": "Specialised returns handling for fashion retail.", "description": "Bleckmann's returns operation is a separate workstream from outbound logistics, with its own systems, its own SLAs and its own data needs. Returns processing for fashion needs to handle garment grading, restocking, refurbishment and disposition decisions that affect both the warehouse and the brand's finance close.\n\nPatchworks integrates Bleckmann Returns for RMA creation, returns receipt notifications, disposition outcomes and refund-eligibility signals. The flow back to ecommerce and ERP needs to be timely enough that customer service has the right context and finance can reconcile cleanly.\n\nThis is operationally one of the most rewarding integrations to get right and one of the easiest to underestimate at scoping.", "featured": false }, { "slug": "bloomreach", "name": "Bloomreach", "category": "CRM", "url": "https://www.ecirql.com/platforms/bloomreach/", "summary": "AI-driven platform for personalised customer experiences.", "description": "Bloomreach started as a search-and-merchandising specialist and has since grown into a customer engagement platform that combines content, search, personalisation and email marketing. The breadth is the strength and also where integration scope tends to expand.\n\nPatchworks integrates Bloomreach across the engagement surface: customer profiles and events from the ecommerce platform, transactional and behavioural data from the order systems, content syndication from the CMS or PIM. Real-time event delivery matters for personalisation, and the event schema deserves more design attention than it usually gets.\n\nBloomreach integrations work best when the data model is agreed up front between marketing, merchandising and engineering.", "featured": false }, { "slug": "brightpearl", "name": "Brightpearl", "category": "ERP", "url": "https://www.ecirql.com/platforms/brightpearl/", "summary": "Retail operations platform automating inventory and orders.", "description": "Brightpearl is a retail-focused ERP and operations platform, owned by Sage, built specifically for multichannel retailers that have outgrown Xero or QuickBooks but are not enterprise enough for NetSuite or D365. Inventory, orders, accounting and CRM in one system, with strong native integrations to Shopify and the big marketplaces.\n\nPatchworks integrates Brightpearl through its REST API. Typical patterns push sales orders in from ecommerce and marketplace channels, write fulfilments back from the warehouse, and keep inventory and pricing in sync with PIM and storefront sources. The accounting side benefits from careful tax-code and channel-tagging design at integration time.\n\nBrightpearl rewards integrations that respect its accounting model rather than treating it as a bare orders database.", "featured": false }, { "slug": "cacheflow", "name": "CacheFlow", "category": "Accounting", "url": "https://www.ecirql.com/platforms/cacheflow/", "summary": "B2B payment platform optimising cash flow management.", "description": "CacheFlow is a B2B payment platform built around the way modern subscription and platform businesses actually invoice: deal-shaped, multi-line, with structured terms and approvals. It sits between the CRM, the billing system and the bank.\n\nPatchworks integrates CacheFlow with CRMs, billing platforms and accounting systems. Deals flow from the CRM as structured contract data, billing schedules generate invoices, and finance sees the result without manual transcription.\n\nFor finance and revops teams CacheFlow is most useful when its data lands cleanly in the ledger, which is where the integration work pays off.", "featured": false }, { "slug": "centra", "name": "Centra", "category": "Ecommerce", "url": "https://www.ecirql.com/platforms/centra/", "summary": "Fashion-focused platform for B2B and D2C commerce.", "description": "Centra is a headless ecommerce platform built specifically for fashion and lifestyle brands, originating in the Nordics and now used across Europe. Its product model handles seasons, drops and B2B/D2C duality in a way that more generic platforms force teams to work around.\n\nPatchworks integrates Centra through its REST API. Orders flow out to ERPs and 3PLs, products and assortments flow in from PIMs, and the B2B/D2C separation needs careful handling so that wholesale orders and direct sales do not contaminate each other downstream.\n\nFashion ecommerce has its own grammar · drops, swatches, look-books · and Centra integrations work best when the team building them understands that grammar before they touch the API.", "featured": false }, { "slug": "channelengine", "name": "ChannelEngine", "category": "Marketplaces", "url": "https://www.ecirql.com/platforms/channelengine/", "summary": "Connects retailers to global marketplace channels.", "description": "ChannelEngine is a marketplace aggregator: one API surface, dozens of marketplaces behind it. Retailers list across Amazon, eBay, Bol, Zalando and many smaller channels without having to integrate each marketplace separately.\n\nPatchworks integrates ChannelEngine for product feed publishing, inventory and price sync, order ingestion and dispute handling. The work is in the channel-level customisations: each marketplace has its own attribute requirements, categorisation rules and return policies, and ChannelEngine surfaces these without solving them entirely.\n\nFor retailers running on a thin team it is one of the marketplace integrations where getting it right pays back the fastest.", "featured": false }, { "slug": "cin7-core", "name": "Cin7 Core", "category": "ERP", "url": "https://www.ecirql.com/platforms/cin7-core/", "summary": "Cloud inventory and order management for multichannel retail.", "description": "Cin7 Core is a cloud inventory and order management platform built for small and mid-market retailers and wholesalers running multichannel. The data model is straightforward and the API is workable, which is why it sees a lot of integration traffic.\n\nPatchworks integrates Cin7 Core for inventory sync, sales order ingestion, purchase order creation and warehouse handoffs. Multichannel sellers in particular benefit from disciplined inventory allocation across channels, which is more design than code work.\n\nCin7 Core integrations are quick to get going. The discipline comes in keeping them honest as the channel count grows.", "featured": false }, { "slug": "clarus-wms", "name": "Clarus WMS", "category": "WMS & 3PL", "url": "https://www.ecirql.com/platforms/clarus-wms/", "summary": "Warehouse management optimising storage and fulfilment.", "description": "Clarus is a warehouse management system used by 3PLs and direct shippers that want a step up from spreadsheets without committing to enterprise WMS pricing. It handles inbound, locations, picking, packing and outbound with the operational primitives a modern warehouse needs.\n\nPatchworks integrates Clarus through its API for inbound goods receipt, stock visibility, outbound order despatch and returns. The most useful integration work tends to be around exception handling: short picks, stock discrepancies, damages and the warehouse-floor signals that need to land in the ERP rather than die in a spreadsheet.", "featured": false }, { "slug": "clerk-io", "name": "Clerk.io", "category": "Ecommerce", "url": "https://www.ecirql.com/platforms/clerk-io/", "summary": "AI-powered search and personalisation for online stores.", "description": "Clerk.io is a European search and personalisation platform, smaller than Algolia but with a strong following among mid-market retailers who want recommendations and search in one product, on a per-month price that does not scale linearly with traffic.\n\nPatchworks integrates Clerk.io for product feed ingest, inventory sync, behavioural event streaming and conversion attribution. The integration is straightforward; the design work is in deciding which signals are worth sending and which dilute the recommendation engine.\n\nFor retailers who do not need Algolia's scale, Clerk.io often does the job at a fraction of the operational complexity.", "featured": false }, { "slug": "commerce-layer", "name": "Commerce Layer", "category": "Ecommerce", "url": "https://www.ecirql.com/platforms/commerce-layer/", "summary": "Headless platform for global digital commerce.", "description": "Commerce Layer is a headless commerce API designed for retailers and brands that want full control of the storefront and need a strong API-first commerce backend behind it. Multi-currency, multi-inventory and multi-region are built in rather than retrofitted.\n\nPatchworks integrates Commerce Layer for order ingest, inventory and price sync, customer mastering and the catalogue feed from PIM systems. Multi-region setups in particular benefit from a flow design that respects the inventory and pricing boundaries Commerce Layer establishes.\n\nHeadless deployments live and die on their integrations. Commerce Layer is one of the better headless backends to integrate against, because the API actually models how international retail works.", "featured": false }, { "slug": "commercetools", "name": "CommerceTools", "category": "Ecommerce", "url": "https://www.ecirql.com/platforms/commercetools/", "summary": "API-first platform for custom commerce experiences.", "description": "commercetools is the reference MACH commerce backend. API-first, microservices-native, used by enterprise retailers that have settled on composable architecture and need their commerce layer to behave the same way. The product is opinionated about composability and unopinionated about almost everything else.\n\nPatchworks integrates commercetools for product publication from PIMs, order routing to OMS and ERP, customer mastering and cross-region inventory. The strength of commercetools is also its complexity at integration time: the data model is rich and projects can lose months arguing about which entities own which truths.\n\nPatchworks's per-flow scoping helps here, because it makes the boundary between commercetools and the systems around it explicit rather than implicit.", "featured": false }, { "slug": "cybertill", "name": "Cybertill", "category": "POS", "url": "https://www.ecirql.com/platforms/cybertill/", "summary": "Cloud retail management for unified commerce.", "description": "Cybertill is a UK cloud retail platform with EPOS, stock control and CRM in one system, popular with multi-site independent retailers and charity retail. The fit is operational and pragmatic rather than enterprise-architectural.\n\nPatchworks integrates Cybertill for store-to-online stock visibility, customer-record reconciliation between till and ecommerce, and reporting flows into accounting and BI systems. The cross-channel reconciliation work · making sure a store sale and an online sale agree on the customer they belong to · is where these integrations earn their keep.", "featured": false }, { "slug": "deposco", "name": "Deposco", "category": "WMS & 3PL", "url": "https://www.ecirql.com/platforms/deposco/", "summary": "Supply chain platform for inventory and fulfilment.", "description": "Deposco is a supply-chain platform covering warehouse management, order management and inventory orchestration across a distributed fulfilment network. It is most often deployed by retailers running multiple warehouses, 3PLs and store-as-warehouse setups simultaneously.\n\nPatchworks integrates Deposco for sales order ingest, allocation feedback, shipment despatch and inventory reconciliation across the fulfilment network. The interesting work is the sourcing logic · which node fulfils which order · and the visibility back to the customer when that decision changes mid-flow.\n\nDistributed fulfilment is where most operations programmes get into trouble. Deposco helps; the integration design has to help further.", "featured": false }, { "slug": "descartes-peoplevox", "name": "Descartes Peoplevox", "category": "WMS & 3PL", "url": "https://www.ecirql.com/platforms/descartes-peoplevox/", "summary": "Cloud warehouse management for ecommerce operations.", "description": "Descartes Peoplevox is an ecommerce-native WMS used heavily by UK and European fashion and lifestyle brands. It handles batch pick-and-pack at scale, with the throughput discipline brands need at peak.\n\nPatchworks integrates Peoplevox for outbound order release, picking confirmations, despatch notifications and stock-level reconciliation. Inbound goods, restocking and returns flow back in the other direction. The bottleneck on these integrations is usually the despatch acknowledgement: getting it timely enough that customer service and marketing systems have current status.\n\nPeoplevox rewards integrations that move at the cadence the warehouse actually runs at, not the cadence the ecommerce team would prefer.", "featured": false }, { "slug": "dotdigital", "name": "Dotdigital", "category": "Marketing", "url": "https://www.ecirql.com/platforms/dotdigital/", "summary": "Omnichannel marketing automation tools.", "description": "Dotdigital is a UK marketing automation platform with strong ecommerce roots, used widely by retailers running on Shopify, Magento and BigCommerce. The strength is in segmentation, programmes and the operational SLAs UK marketing teams actually need.\n\nPatchworks integrates Dotdigital for customer and order data sync, behavioural event streaming and back-flow of marketing engagement metrics into the CRM or CDP. Consent state and subscription preferences need to live consistently across systems, and that is where most data-quality issues surface.\n\nDotdigital integrations work best when the segmentation strategy is written down before the API work begins.", "featured": false }, { "slug": "edifabric", "name": "ediFabric", "category": "EDI & Files", "url": "https://www.ecirql.com/platforms/edifabric/", "summary": "Framework for EDI document processing.", "description": "ediFabric is an EDI framework for .NET, used by developers and integration teams who need to parse, validate and emit EDI documents without paying for a full EDI platform. It is library-shaped: the rest of the integration estate has to provide the orchestration, the partner-by-partner config and the retry semantics.\n\nPatchworks pairs naturally with ediFabric. ediFabric handles the document layer; Patchworks handles the transport, partner-routing, mapping into ERP or WMS systems and the visibility a trading-partner programme actually needs.\n\nEDI integrations get judged on reliability under pressure. The architecture matters more than the tooling, and that is where the design effort lands.", "featured": false }, { "slug": "ekm-insights", "name": "EKM Insights", "category": "Ecommerce", "url": "https://www.ecirql.com/platforms/ekm-insights/", "summary": "All-in-one platform with built-in analytics.", "description": "EKM Insights is a UK-built ecommerce platform aimed at small businesses, with hosting, design, payments and analytics in one package. The audience skews towards retailers running their first or second ecommerce iteration, and the platform is designed accordingly.\n\nPatchworks integrates EKM Insights with marketplaces, accounting, marketing and basic fulfilment systems. Many EKM customers do not need a heavyweight integration estate; they need a couple of reliable connections that survive their next platform decision.", "featured": false }, { "slug": "emarsys", "name": "Emarsys", "category": "CRM", "url": "https://www.ecirql.com/platforms/emarsys/", "summary": "AI marketing platform for customer engagement.", "description": "Emarsys, now part of SAP, is an enterprise-grade customer engagement platform with strong cross-channel orchestration, predictive segmentation and ecommerce-specific use cases. It is most often deployed by retailers that have outgrown Klaviyo, Bloomreach or Salesforce Marketing Cloud and need an opinionated engagement programme.\n\nPatchworks integrates Emarsys for customer and order data sync, behavioural events and the programme-level data Emarsys needs to run predictive segments. The integration work is structural: agreeing the customer identity model, deciding how transactional data lands, and respecting consent boundaries that span EU jurisdictions.\n\nFor enterprise retailers running Emarsys, the quality of the data going in is the single biggest determinant of programme outcomes.", "featured": false }, { "slug": "eva", "name": "Eva", "category": "Ecommerce", "url": "https://www.ecirql.com/platforms/eva/", "summary": "AI shopping assistant for product discovery.", "description": "Eva is an AI shopping assistant that sits on the storefront and helps customers find products via natural-language conversation rather than category navigation or filtered search. The category is young; the integration work is well-shaped.\n\nPatchworks feeds Eva with product data from PIMs and ecommerce platforms, inventory and pricing in close-to-real time, and conversion events back into the customer data platform. The interesting design choices are around freshness · how stale Eva's view of stock and price is allowed to be · and around the fallback experience when Eva does not have an answer.\n\nConversational commerce only works when the catalogue feed is honest. Most of the integration work is making it so.", "featured": false }, { "slug": "flexport", "name": "Flexport", "category": "WMS & 3PL", "url": "https://www.ecirql.com/platforms/flexport/", "summary": "Digital freight forwarding and customs platform.", "description": "Flexport is a digital freight-forwarding and customs platform, used by retailers and brands that import physical goods at scale and want visibility into their supply chain that conventional forwarders do not provide.\n\nPatchworks integrates Flexport for purchase-order and shipment-status visibility, ETA updates back into the ERP and merchandising systems, and customs documentation flows into finance and compliance. Inbound forecasting against open POs is one of the more useful operational outputs.\n\nSupply-chain visibility is mostly a data-quality problem dressed up as a software problem. Flexport gives you the data; the integration work makes it act on something.", "featured": false }, { "slug": "fluent-commerce", "name": "Fluent Commerce", "category": "OMS", "url": "https://www.ecirql.com/platforms/fluent-commerce/", "summary": "Distributed order management for omnichannel retail.", "description": "Fluent Commerce is a distributed order management platform, designed for retailers running omnichannel fulfilment with stores, warehouses and dropship suppliers all participating in fulfilling the same order. Sourcing rules, allocation, splits and routing are first-class.\n\nPatchworks integrates Fluent for order ingestion from ecommerce and marketplace channels, sourcing-decision feedback to the customer experience layer, fulfilment-status updates from WMS systems and back-flow into the ERP. The design effort is in the sourcing rules · which node fulfils which order · and the visibility of those decisions to the operations team.\n\nDistributed fulfilment is where omnichannel promises get tested. Fluent helps. Integration design helps further.", "featured": false }, { "slug": "freeagent", "name": "FreeAgent", "category": "Accounting", "url": "https://www.ecirql.com/platforms/freeagent/", "summary": "Online accounting for freelancers and small business.", "description": "FreeAgent is UK SMB accounting, popular with freelancers, micro-businesses and small agencies. The product is opinionated about simplicity, which is most of its appeal.\n\nPatchworks integrates FreeAgent for invoice and credit-note creation, payment reconciliation and the basic data flows ecommerce SMBs need into their accountant's preferred system. The integration is usually quick; the design care is in how returns and refunds map into FreeAgent's ledger so the close stays clean.", "featured": false }, { "slug": "freshdesk", "name": "Freshdesk", "category": "Service Desk", "url": "https://www.ecirql.com/platforms/freshdesk/", "summary": "Customer support and ticket management system.", "description": "Freshdesk is Freshworks's customer support platform, a Zendesk alternative with strong adoption in mid-market and global support operations. The product is generally easier to deploy than Zendesk and slightly less rich at the high end, which is mostly a feature.\n\nPatchworks integrates Freshdesk for ticket creation, customer-context lookup against ERP and ecommerce data, and macro automation that respects the operational truth elsewhere in the stack. Order status, RMA state and customer history flowing into the agent surface is where most of the value lands.", "featured": false }, { "slug": "fulfillment-tools", "name": "Fulfillment Tools", "category": "OMS", "url": "https://www.ecirql.com/platforms/fulfillment-tools/", "summary": "Order management optimising multichannel fulfilment.", "description": "Fulfillment Tools is a German-built distributed order management platform, recently spun out of REWE Digital, focused on retailers and brands operating store fulfilment, micro-fulfilment and warehouse-as-a-network setups.\n\nPatchworks integrates Fulfillment Tools for order routing, store and warehouse fulfilment confirmations, inventory reconciliation across the fulfilment network and back-flow into ERP and ecommerce. Store-fulfilment in particular benefits from a careful flow design that respects the cadence and constraints of in-store picking.", "featured": false }, { "slug": "google-bigquery", "name": "Google BigQuery", "category": "Data & BI", "url": "https://www.ecirql.com/platforms/google-bigquery/", "summary": "Cloud data warehouse for large-scale analytics.", "description": "BigQuery is Google Cloud's serverless data warehouse. It is the default destination for analytical workloads on GCP and a common one for retailers and brands regardless of where their operational systems live, because the pricing and the SQL surface are forgiving.\n\nPatchworks integrates BigQuery as a destination, source or both. Operational data from ecommerce, ERP, WMS and marketing systems lands in BigQuery on schedule or via event triggers; analytical outputs and segments flow back out to operational tools. Idempotency, lineage and clear ownership are the design conversations worth having early.\n\nBigQuery integrations are easy to start and easy to neglect. Owning the freshness and shape of the data going in is where the discipline pays off.", "featured": false }, { "slug": "google-pubsub", "name": "Google Pub/Sub", "category": "Messaging", "url": "https://www.ecirql.com/platforms/google-pubsub/", "summary": "Real-time messaging for event-driven systems.", "description": "Pub/Sub is Google Cloud's managed message broker. It handles the asynchronous, event-driven plumbing for integration estates that need to scale beyond synchronous request/response patterns.\n\nPatchworks uses Pub/Sub as a backbone for event-driven integration. Topics carry order events, fulfilment milestones, inventory changes and operational signals between systems. Retry, replay, dead-letter handling and delivery semantics are first-class concerns rather than afterthoughts.\n\nThe integrations that benefit most from Pub/Sub are the ones where systems do not need to know about each other directly. The design effort is in deciding what the events mean, not what the broker does.", "featured": false }, { "slug": "google-sheets", "name": "Google Sheets", "category": "Data & BI", "url": "https://www.ecirql.com/platforms/google-sheets/", "summary": "Collaborative spreadsheet application.", "description": "Google Sheets is the world's most-deployed lightweight integration target. Operations teams reach for it constantly, and the gap between \"this lives in Google Sheets\" and \"this is now a real system\" is where integration agencies make themselves useful.\n\nPatchworks integrates Google Sheets for data ingest from operational systems, exception-handling workflows that need a spreadsheet shape to work with, and reporting outputs that finance and operations teams already know how to consume. The discipline is in not letting the Sheet become a permanent system of record by accident.", "featured": false }, { "slug": "gorgias", "name": "Gorgias", "category": "Service Desk", "url": "https://www.ecirql.com/platforms/gorgias/", "summary": "Ecommerce-focused customer service platform.", "description": "Gorgias is a customer service platform built specifically for ecommerce, with native integrations to Shopify, BigCommerce, Magento and the big marketplaces. The product is opinionated about ecommerce workflows, which is why it tends to displace generic helpdesks once a retailer has scaled past a certain size.\n\nPatchworks integrates Gorgias for order-context lookup against ERP and OMS data, automated ticket routing based on operational state, and feedback of resolution data into the CRM. The work that pays off most is closing the loop between support and operations: the right context on every ticket, the right escalation path when the answer lives outside the storefront.", "featured": false }, { "slug": "gxo", "name": "GXO", "category": "WMS & 3PL", "url": "https://www.ecirql.com/platforms/gxo/", "summary": "Global logistics and warehousing provider.", "description": "GXO is one of the world's largest contract logistics providers, with warehouses across the UK, EU and US. Retailers running on GXO are doing so for scale, automation maturity and global reach rather than fashion-aware service.\n\nPatchworks integrates GXO at the file and API level, depending on the warehouse and the contract. Outbound order despatch, inbound goods receipt, stock-level reconciliation and shipping confirmation are the standard flows. GXO sites vary in their interface conventions, and an integration that works in one facility is not automatically portable.\n\nWe treat each GXO site as its own integration scope, even when the contract treats them as one operation.", "featured": false }, { "slug": "happy-returns", "name": "Happy Returns", "category": "Returns", "url": "https://www.ecirql.com/platforms/happy-returns/", "summary": "In-person and online returns solution.", "description": "Happy Returns, now part of PayPal, runs an in-person and online returns network in the US, with drop-off bars and reverse-logistics consolidation as the differentiator. For US-active retailers it is one of the more operationally meaningful returns platforms.\n\nPatchworks integrates Happy Returns for RMA creation, drop-off and return-arrival events, disposition outcomes and refund triggers. The retailer's ecommerce, ERP and WMS all need the right signals at the right time so customer service, finance and the warehouse stay in sync.", "featured": false }, { "slug": "huboo", "name": "Huboo", "category": "WMS & 3PL", "url": "https://www.ecirql.com/platforms/huboo/", "summary": "Ecommerce fulfilment service provider.", "description": "Huboo is a UK-based fulfilment provider built around small and mid-sized direct-to-consumer brands. The pitch is operational simplicity at scale: human pickers, modern software and SKU-level visibility.\n\nPatchworks integrates Huboo for outbound order release, despatch confirmation, inventory reconciliation and returns receipt. Brands using Huboo typically want a tight ecommerce-to-fulfilment loop without the overhead of a heavyweight WMS, and the integration design reflects that.", "featured": false }, { "slug": "hubspot", "name": "Hubspot", "category": "CRM", "url": "https://www.ecirql.com/platforms/hubspot/", "summary": "Inbound marketing and sales platform.", "description": "HubSpot started as an inbound marketing tool and is now a full CRM, marketing and sales suite. It is the default CRM for a large share of mid-market B2B businesses and a real contender in B2C ecommerce CRM use cases.\n\nPatchworks integrates HubSpot with ecommerce platforms, ERPs and customer data sources. Contacts, deals, orders and behavioural events flow in either direction, and the customer-identity model deserves real design attention. HubSpot's properties model is forgiving, which can produce data sprawl quickly if integrations are not opinionated.\n\nFor B2B ecommerce in particular HubSpot earns its keep when integrated rigorously and gets in the way when integrated lazily.", "featured": false }, { "slug": "inriver", "name": "Inriver", "category": "PIM", "url": "https://www.ecirql.com/platforms/inriver/", "summary": "Digital-first product information management.", "description": "Inriver is an enterprise PIM that competes most directly with Akeneo and Salsify, with a strong following in industrial and B2B retail where digital-first product information is the constraint on growth.\n\nPatchworks integrates Inriver for syndication to commerce platforms, marketplaces and DAMs, and for inbound supplier data, ERP item-master sync and translation services. The model design · entity types, channels, relationships · is the design effort that determines whether the PIM serves the business or constrains it.", "featured": false }, { "slug": "jira", "name": "Jira", "category": "Project Management", "url": "https://www.ecirql.com/platforms/jira/", "summary": "Issue tracking and agile project management.", "description": "Jira is Atlassian's issue tracker, used by most development teams and a large share of operational ones. Integration estates touch Jira whenever ops, support or engineering work needs to cross system boundaries: tickets become deployments, incidents become tasks, releases become customer notifications.\n\nPatchworks integrates Jira for ticket-driven automation, release-cycle hooks and the operational feedback developers actually need. The work is mostly in the agreed boundaries · what counts as a ticket, who owns the transition, when the integration writes back.", "featured": false }, { "slug": "khaos-control", "name": "Khaos Control", "category": "ERP", "url": "https://www.ecirql.com/platforms/khaos-control/", "summary": "Integrated retail management solution.", "description": "Khaos Control is a long-established UK ERP for retail and distribution, with a strong following in independent retail and small-to-mid distributors. The product is opinionated about retail operations and shows its age in places, which is a feature for the operators who know it and a friction point for greenfield projects.\n\nPatchworks integrates Khaos Control for sales-order ingest from ecommerce and marketplace channels, inventory and price sync, purchase-order generation and fulfilment back-flow. The data model takes some getting used to; the upside is that once the integration is shaped right it tends to keep working.", "featured": false }, { "slug": "klaviyo", "name": "Klaviyo", "category": "CRM", "url": "https://www.ecirql.com/platforms/klaviyo/", "summary": "Ecommerce marketing and customer data platform.", "description": "Klaviyo is the dominant ecommerce CRM and email platform for Shopify-first retailers, with steadily growing traction outside the Shopify ecosystem. The differentiator is the data model: events, profiles and metrics rather than just lists.\n\nPatchworks integrates Klaviyo via its events API. Order events, fulfilment milestones, return events and custom triggers from operational systems land as profile properties and metric events. Behavioural flows and segments key off this data, so the freshness and the granularity matter more than they do for traditional ESPs.\n\nThe design work is in deciding what to send and at what granularity. Klaviyo will accept everything; marketing teams pay for ingestion and clutter quickly buries the segments that actually drive revenue.", "featured": true }, { "slug": "lightspeed-restaurant", "name": "Lightspeed Restaurant", "category": "POS", "url": "https://www.ecirql.com/platforms/lightspeed-restaurant/", "summary": "Cloud POS system for hospitality businesses.", "description": "Lightspeed Restaurant, the K-Series, is the hospitality POS that came in via the Kounta acquisition. It is the choice for venue groups and restaurant operators running multi-location hospitality with menu and stock management built in.\n\nPatchworks integrates Lightspeed Restaurant for sales data into accounting and BI, stock movements into the inventory system, customer loyalty across venues, and reporting flows that finance can close on. Multi-location reconciliation is the area where these integrations earn their keep.", "featured": false }, { "slug": "lightspeed-retail", "name": "Lightspeed Retail Epos", "category": "POS", "url": "https://www.ecirql.com/platforms/lightspeed-retail/", "summary": "Retail management with integrated payments.", "description": "Lightspeed Retail Epos is the retail-side POS, used by independent and mid-market store operators across the UK, Europe and North America. The strength is retail-aware inventory and the integration touch-points that come with it.\n\nPatchworks integrates Lightspeed Retail for store-to-online stock visibility, customer mastering across retail and ecommerce, sales transactions into accounting and ERP, and loyalty reconciliation. Store and online conflict resolution · who saw the customer first, who owns the loyalty balance · is where most of the integration design lands.", "featured": false }, { "slug": "linnworks", "name": "Linnworks", "category": "ERP", "url": "https://www.ecirql.com/platforms/linnworks/", "summary": "Multichannel inventory and order automation.", "description": "Linnworks is a UK-built multichannel order and inventory management platform, used heavily by retailers and brands selling across Amazon, eBay, Shopify and the long tail of marketplaces. The strength is breadth of channel coverage and operational pragmatism.\n\nPatchworks integrates Linnworks for marketplace and ecommerce channel sync, inventory allocation, shipping despatch and reporting back to ERP and finance systems. Multichannel sellers benefit most from an integration design that keeps channel-level rules explicit rather than buried in Linnworks-internal logic.", "featured": false }, { "slug": "lionwheel", "name": "Lionwheel", "category": "WMS & 3PL", "url": "https://www.ecirql.com/platforms/lionwheel/", "summary": "Ecommerce fulfilment services provider.", "description": "Lionwheel is a fulfilment provider operating in the UK and adjacent markets, with a service model aimed at growing direct-to-consumer brands.\n\nPatchworks integrates Lionwheel for order release, despatch confirmation and stock reconciliation. The integration scope is usually focused: get orders out reliably, get the data back in cleanly. The discipline is in the exception cases.", "featured": false }, { "slug": "magento", "name": "Magento", "category": "Ecommerce", "url": "https://www.ecirql.com/platforms/magento/", "summary": "Open-source platform with extensive customisation.", "description": "Magento, now Adobe Commerce, has been the default open-source enterprise commerce platform for over a decade. The product is rich, the customisation surface is enormous, and the integration estate around it tends to grow accordingly.\n\nPatchworks integrates Magento through its REST and GraphQL APIs. Orders flow out to ERPs and OMS, products and inventory flow in from PIMs and ERPs, customers move between Magento and the marketing stack. B2B Magento deployments have their own dimension · company structures, hierarchical pricing, quote workflows · that integrations need to respect rather than flatten.\n\nMagento integrations work best when the customisations the merchant has made are understood up front. There is no such thing as a generic Magento connector for a heavily-customised store.", "featured": true }, { "slug": "mailchimp", "name": "Mailchimp", "category": "Marketing", "url": "https://www.ecirql.com/platforms/mailchimp/", "summary": "Email marketing and automation tools.", "description": "Mailchimp is the default email platform for small and mid-market businesses, with marketing automation, audience management and reporting that scale from one-person shops to several-thousand-employee organisations.\n\nPatchworks integrates Mailchimp for audience and contact sync, behavioural and transactional event delivery, and back-flow of engagement metrics into the CRM. Consent state is the field most integrations get wrong; getting it right is mostly discipline rather than technology.", "featured": false }, { "slug": "mailjet", "name": "Mailjet", "category": "Marketing", "url": "https://www.ecirql.com/platforms/mailjet/", "summary": "Email delivery and campaign management.", "description": "Mailjet is a transactional and marketing email platform, used by businesses that want a more developer-friendly API and a more European compliance posture than the US-headquartered alternatives.\n\nPatchworks integrates Mailjet for transactional email triggers from operational systems, marketing list sync and engagement-event back-flow. The integration is usually quick; the discipline is in the deliverability conventions and the audit-trail Mailjet's compliance features depend on.", "featured": false }, { "slug": "mapp", "name": "Mapp", "category": "CRM", "url": "https://www.ecirql.com/platforms/mapp/", "summary": "Insight-led customer engagement platform.", "description": "Mapp is a European customer engagement platform with strong roots in cross-channel orchestration and an audience that skews towards mid-market and enterprise retail across the UK, DACH and Nordics.\n\nPatchworks integrates Mapp for customer profile sync, transactional and behavioural event ingest, and back-flow of campaign engagement data into the CRM or CDP. The data model deserves real design attention; Mapp performs in proportion to the quality of what you feed it.", "featured": false }, { "slug": "marketplacer", "name": "Marketplacer", "category": "Marketplaces", "url": "https://www.ecirql.com/platforms/marketplacer/", "summary": "Platform for building online marketplaces.", "description": "Marketplacer is an Australian-built platform for retailers and brands that want to operate their own marketplace, with curated seller programmes, third-party stock and the operational primitives that come with multi-seller commerce.\n\nPatchworks integrates Marketplacer for product feed ingest from seller systems, order routing to sellers, inventory and price sync, and settlement reconciliation across the seller base. The hard problems are usually around dispute handling and the financial reconciliation that follows.", "featured": false }, { "slug": "microsoft-dynamics-business-central", "name": "Microsoft Dynamics Business Central", "category": "ERP", "url": "https://www.ecirql.com/platforms/microsoft-dynamics-business-central/", "summary": "Cloud business management for SMBs.", "description": "Microsoft Dynamics 365 Business Central is Microsoft's cloud ERP for small and mid-market businesses, the successor to Dynamics NAV. It handles the full operational accounting and inventory surface and integrates well with the rest of the Microsoft cloud · Power Platform, Azure, the Microsoft 365 stack · where many UK businesses already live.\n\nPatchworks integrates Business Central through its REST API and the OData endpoints. Sales orders flow in from ecommerce and marketplace channels, item masters and inventory flow between Business Central and PIMs and warehouses, finance postings reconcile against the ledger. Multi-company and multi-currency setups need careful flow design around dimensions and posting groups.\n\nOur team has shipped Business Central integrations across both straightforward and multi-company estates, and the multi-company case in particular benefits from Patchworks's per-flow scoping.", "featured": true }, { "slug": "mirakl", "name": "Mirakl", "category": "Marketplaces", "url": "https://www.ecirql.com/platforms/mirakl/", "summary": "Enterprise marketplace solutions.", "description": "Mirakl is the enterprise marketplace platform: retailers like Carrefour, Best Buy and Maisons du Monde run Mirakl-powered marketplaces alongside their first-party operations. The platform handles seller onboarding, product catalogues, order routing and settlement at enterprise scale.\n\nPatchworks integrates Mirakl for seller-side product feed publishing, inventory and pricing sync, order ingestion and settlement processing. Operator-side flows handle seller onboarding, catalogue moderation and dispute reconciliation. Both sides of a Mirakl deployment have their own integration surface, and treating them separately is usually correct.\n\nMarketplace integrations are unforgiving about timing and fee mapping. Mirakl is no exception, and the discipline of running them under SLA is where the value lands.", "featured": true }, { "slug": "mongodb", "name": "MongoDB", "category": "Data & BI", "url": "https://www.ecirql.com/platforms/mongodb/", "summary": "NoSQL database for modern applications.", "description": "MongoDB is the default document database for modern application stacks, with a permissive data model and a generous query surface that suit the parts of operations that do not fit cleanly into a relational schema.\n\nPatchworks integrates MongoDB as a data source or destination, depending on where it sits in the estate. Document shape and indexing strategy matter for the integration's stability; getting them right is usually a joint conversation between the integration team and the application engineers who own the database.", "featured": false }, { "slug": "netsuite", "name": "NetSuite", "category": "ERP", "url": "https://www.ecirql.com/platforms/netsuite/", "summary": "Cloud business suite for enterprise operations.", "description": "NetSuite is Oracle's cloud ERP. It handles general ledger, AR/AP, inventory, manufacturing, fulfilment and a long list of operational subsystems for businesses too large for QuickBooks and too varied for a vertical-specific system. SuiteScript and SuiteTalk let developers extend almost any record type, and the API surface is comprehensive at the cost of being intricate.\n\nPatchworks integrates NetSuite via its REST and SuiteTalk APIs. Process flows typically push sales orders in from the storefront, write fulfilments back from the warehouse, and reconcile inventory in either direction. The complexity is usually in record-type choice · when to use a sales order versus a cash sale, when to use a credit memo versus a customer refund, and how to model item pricing without breaking the SuiteQL queries finance relies on.\n\nOur team writes SuiteScript daily, and that depth is what stops NetSuite integrations stalling six weeks in. It is also one of our headline service lines in its own right.", "featured": true }, { "slug": "newstore", "name": "NewStore", "category": "POS", "url": "https://www.ecirql.com/platforms/newstore/", "summary": "Mobile-first retail management platform.", "description": "NewStore is a mobile-first retail platform, popular with brand-led retailers that want a store-as-flagship experience and need the technology to match. POS, OMS and clienteling come from one platform with shared data.\n\nPatchworks integrates NewStore for store-to-online customer mastering, stock visibility across the fulfilment network, order ingestion from non-NewStore channels and back-flow into the ERP and finance systems. Clienteling data, in particular, has to land somewhere usable outside the store-associate app to earn its keep.", "featured": false }, { "slug": "occtoo", "name": "Occtoo", "category": "DXP", "url": "https://www.ecirql.com/platforms/occtoo/", "summary": "Digital experience platform for headless commerce.", "description": "Occtoo is a data orchestration platform built for commerce, helping retailers and brands collect, model and serve product, content and customer data across the systems that depend on it.\n\nPatchworks integrates Occtoo as a data hub between commerce platforms, PIMs, ERPs and downstream consumers. The interesting design work is the shape of the unified model and the latency budget different consumers need.\n\nOcctoo earns its keep when the data model is designed in the open with the teams that will live with it.", "featured": false }, { "slug": "octopus-energy", "name": "Octopus Energy", "category": "Other", "url": "https://www.ecirql.com/platforms/octopus-energy/", "summary": "Digital energy supply management.", "description": "Octopus Energy is a UK energy supplier with a substantial software practice and an open API for partners working in the energy supply ecosystem. Outside the energy market the platform is unusual but the integration patterns translate.\n\nPatchworks integrates Octopus where the supply chain requires it: usage data, smart-meter telemetry, billing flows and the operational signals partners need to act on. Each use case is its own design conversation.", "featured": false }, { "slug": "odoo", "name": "Odoo", "category": "ERP", "url": "https://www.ecirql.com/platforms/odoo/", "summary": "Open-source business management suite.", "description": "Odoo is the open-source business management suite, with modules covering accounting, inventory, manufacturing, ecommerce, marketing and a long list of vertical adaptations. It is the default ERP for businesses that want a single integrated platform without committing to enterprise pricing.\n\nPatchworks integrates Odoo through its XML-RPC and REST APIs. Sales orders, inventory, customers and accounting postings all sit within reach. Multi-company and multi-warehouse Odoo deployments need careful flow design, and the customised-module problem is real: every meaningfully-deployed Odoo is different.\n\nOdoo integrations reward time spent understanding the customisations before touching the API.", "featured": false }, { "slug": "ometria", "name": "Ometria", "category": "CRM", "url": "https://www.ecirql.com/platforms/ometria/", "summary": "Retail-focused customer data platform.", "description": "Ometria is a UK-built customer data platform focused on retail, with predictive segmentation, cross-channel orchestration and a data model designed for the messy reality of multichannel customers.\n\nPatchworks integrates Ometria for customer profile sync, transactional and behavioural event delivery, and back-flow of engagement and prediction data into the CRM and operational systems. Identity resolution across channels is the design work that determines whether Ometria's predictions are worth acting on.", "featured": false }, { "slug": "onbuy", "name": "Onbuy", "category": "Marketplaces", "url": "https://www.ecirql.com/platforms/onbuy/", "summary": "UK online marketplace platform.", "description": "OnBuy is a UK marketplace positioned as a smaller-fees alternative to Amazon and eBay for British sellers. The audience is mid-market retailers who want incremental marketplace presence without re-architecting their operation around Amazon.\n\nPatchworks integrates OnBuy for listings, inventory, pricing and order ingestion. The work is similar in shape to other marketplace integrations and tends to be less unforgiving than Amazon, which is a feature rather than a bug for the seller base.", "featured": false }, { "slug": "onestock", "name": "OneStock", "category": "OMS", "url": "https://www.ecirql.com/platforms/onestock/", "summary": "Omnichannel order management solution.", "description": "OneStock is a French-built distributed order management platform, with strong adoption in European retail running store fulfilment, multi-warehouse setups and click-and-collect.\n\nPatchworks integrates OneStock for order routing, inventory orchestration across the fulfilment network, fulfilment-status updates and back-flow into the ecommerce and ERP layers. Store-fulfilment in particular benefits from a flow design that respects the realities of in-store picking SLAs.", "featured": false }, { "slug": "openai", "name": "OpenAI", "category": "AI", "url": "https://www.ecirql.com/platforms/openai/", "summary": "AI research and deployment platform.", "description": "OpenAI's API is the most-deployed AI integration surface in commerce today. Models for generation, embeddings, function calling and structured output sit behind a single API, with the cost model and the latency budget being the operational constraints most projects underestimate.\n\nPatchworks integrates OpenAI as part of agentic workflows, retrieval pipelines and operational automations. Model calls, embeddings, tool definitions and event triggers all flow through the same pipes as the rest of the integration estate. Cost controls, retry semantics, audit logging and the safety boundary deserve as much design attention as any classic integration concern.\n\nThis is the heart of our AI enablement practice: production AI integrations, not pilots.", "featured": false }, { "slug": "orderwise", "name": "Orderwise", "category": "ERP", "url": "https://www.ecirql.com/platforms/orderwise/", "summary": "Business management for order processing.", "description": "OrderWise is a UK ERP and warehouse management system for distributors, manufacturers and multichannel retailers, with a long-established footprint in the UK SMB and lower-mid market.\n\nPatchworks integrates OrderWise for sales-order ingest from ecommerce and marketplace channels, inventory and pricing sync, purchase-order generation and fulfilment back-flow. The data model rewards integrations that respect its conventions; trying to flatten it is usually a false economy.", "featured": false }, { "slug": "orocommerce", "name": "OroCommerce", "category": "Ecommerce", "url": "https://www.ecirql.com/platforms/orocommerce/", "summary": "B2B ecommerce with CRM integration.", "description": "OroCommerce is an open-source B2B commerce platform, with a built-in CRM and an opinionated data model around buyers, accounts and account hierarchies. The differentiator is that B2B-specific behaviours · quote workflows, account-level pricing, request-for-quote · are first-class rather than bolted on.\n\nPatchworks integrates OroCommerce for orders, customers, products and the B2B-specific entities the platform exposes. Quote-to-order, account-hierarchy mapping and contract pricing are where most of the integration design lands.", "featured": false }, { "slug": "pagerduty", "name": "Pagerduty", "category": "Service Desk", "url": "https://www.ecirql.com/platforms/pagerduty/", "summary": "Digital operations management platform.", "description": "PagerDuty is the incident-response platform for engineering and operations teams that need on-call rotations, escalation policies and the audit trail incidents require.\n\nPatchworks integrates PagerDuty for incident creation from operational signals, escalation hooks and resolution feedback into the CRM and support systems. The work is in deciding what should page a human and what should not, which is mostly a design conversation about thresholds and ownership.", "featured": false }, { "slug": "pimberly", "name": "Pimberly", "category": "PIM", "url": "https://www.ecirql.com/platforms/pimberly/", "summary": "Cloud PIM and DAM solution.", "description": "Pimberly is a UK-built PIM and DAM with strong adoption among mid-market retailers and brands that need a more affordable on-ramp than the enterprise alternatives without losing the syndication features that make a PIM worth deploying.\n\nPatchworks integrates Pimberly for product publication to ecommerce platforms, marketplaces and channel-specific destinations, and for inbound supplier and ERP data. The model design is the design work that determines whether the PIM accelerates the merchandising team or trips it up.", "featured": false }, { "slug": "plytix", "name": "Plytix", "category": "PIM", "url": "https://www.ecirql.com/platforms/plytix/", "summary": "PIM platform for SMB product data.", "description": "Plytix is a PIM platform aimed at small and mid-market retailers, with a lighter feature set than Akeneo or Salsify and a price point to match. The fit is operationally pragmatic for businesses that need disciplined product data without enterprise overhead.\n\nPatchworks integrates Plytix for syndication to ecommerce platforms, marketplaces and DAMs, and for inbound supplier and ERP product data. The integration work is generally quick; the discipline is in the model design.", "featured": false }, { "slug": "prima-solutions", "name": "Prima Solutions", "category": "ERP", "url": "https://www.ecirql.com/platforms/prima-solutions/", "summary": "Fashion industry management software.", "description": "Prima Solutions is a vertical management platform for the fashion industry, covering product lifecycle, sourcing, planning and inventory for brands and retailers operating in apparel and accessories.\n\nPatchworks integrates Prima Solutions where the fashion supply chain meets the rest of the operation: product lifecycle data into PIM and ecommerce, inventory and allocation into the storefront and warehouse, and finance and merchandising flows into the wider estate.", "featured": false }, { "slug": "quickbooks", "name": "QuickBooks", "category": "Accounting", "url": "https://www.ecirql.com/platforms/quickbooks/", "summary": "Financial management for small business.", "description": "QuickBooks Online is the default cloud accounting platform for small and mid-market businesses worldwide. It is the system the bookkeeper uses, and that is mostly what matters when designing the integration.\n\nPatchworks integrates QuickBooks for invoice and credit-note creation, customer mastering, payment reconciliation and ledger postings from ecommerce, ERP and marketplace channels. The discipline is in the tax-code and chart-of-accounts mapping at integration time, which determines whether finance can close cleanly or has to clean up after the integration each month.", "featured": false }, { "slug": "rabbitmq", "name": "rabbitMQ", "category": "Messaging", "url": "https://www.ecirql.com/platforms/rabbitmq/", "summary": "Message broker for applications.", "description": "RabbitMQ is the established open-source message broker, used in integration estates that need queueing, pub/sub and routing without going all-in on a cloud-vendor's managed service.\n\nPatchworks uses RabbitMQ as a backbone for event-driven integration, with topics carrying operational events between systems. Retry, dead-letter handling and replay semantics are first-class concerns. The design effort is in the topology · exchanges, queues, routing keys · and the operational ownership of the broker itself.", "featured": false }, { "slug": "rebound-returns", "name": "Rebound Returns", "category": "Returns", "url": "https://www.ecirql.com/platforms/rebound-returns/", "summary": "Global returns management solution.", "description": "ReBOUND is a global returns platform, with strong adoption among brands and retailers managing cross-border returns and the consolidation that makes them economical at scale.\n\nPatchworks integrates ReBOUND for RMA creation, returns-status events, disposition outcomes and refund triggers. Cross-border flows in particular benefit from a careful design around customs documentation and the financial reconciliation that follows.", "featured": false }, { "slug": "returngo", "name": "ReturnGO", "category": "Returns", "url": "https://www.ecirql.com/platforms/returngo/", "summary": "Automated returns platform for ecommerce.", "description": "ReturnGO is a returns automation platform built around self-service portals, AI-assisted disposition and exchange-first flows that prefer keeping the customer in the brand rather than refunding out of it.\n\nPatchworks integrates ReturnGO for RMA flows, refund and exchange decisions, restocking signals and operational back-flow into ERP, WMS and customer-service systems. Exchange-first flows in particular benefit from real-time inventory visibility, which is mostly an integration design choice.", "featured": false }, { "slug": "returnless", "name": "returnless", "category": "Returns", "url": "https://www.ecirql.com/platforms/returnless/", "summary": "Digital returns optimisation platform.", "description": "Returnless is a Netherlands-headquartered returns platform with a portfolio of returns and exchange flows aimed at European ecommerce. It competes most directly with ReturnGO and the regional incumbents.\n\nPatchworks integrates Returnless for RMA creation, returns-status events and refund or exchange flows. The integration shape is broadly similar across returns platforms; the differences are in the model and the partner-by-partner courier integrations Returnless ships.", "featured": false }, { "slug": "reveni", "name": "Reveni", "category": "Returns", "url": "https://www.ecirql.com/platforms/reveni/", "summary": "Returns management for online retail.", "description": "Reveni is a Spanish-built returns platform with a strong focus on instant-refund flows that improve customer experience while the actual returns logistics catches up behind the scenes.\n\nPatchworks integrates Reveni for RMA creation, instant-refund triggers, courier handoffs and reconciliation against the actual returned goods. The financial design needs care: instant refunds work for the customer experience and against finance if the reconciliation back to received stock is not airtight.", "featured": false }, { "slug": "reviews", "name": "Reviews", "category": "Other", "url": "https://www.ecirql.com/platforms/reviews/", "summary": "Customer review management system.", "description": "Customer reviews · through Reviews.io, Yotpo, Trustpilot or another platform · sit between marketing, customer service and product. The integration scope is usually narrower than it looks: trigger requests at the right point, ingest the responses, surface them where the rest of the operation can act on them.\n\nPatchworks integrates reviews platforms for trigger-event delivery, review and rating ingest, and back-flow into the storefront and PIM where ratings appear. Negative-review escalation into the customer service tool is one of the flows that quietly pays back the most and gets built the least.", "featured": false }, { "slug": "rithum-channel-advisor", "name": "Rithum | Channel Advisor", "category": "Marketplaces", "url": "https://www.ecirql.com/platforms/rithum-channel-advisor/", "summary": "Multichannel commerce management platform.", "description": "Rithum, formerly Channel Advisor, is one of the larger multichannel commerce platforms, with a heritage in marketplace management and a current footprint covering retail media, brand operations and seller programmes.\n\nPatchworks integrates Rithum for product feed publication, inventory and pricing sync, order ingest and settlement reconciliation across the multichannel footprint. Each channel has its own conventions; Rithum surfaces them but does not abolish them, and the integration design has to respect that.", "featured": false }, { "slug": "sage-200", "name": "Sage 200", "category": "Accounting", "url": "https://www.ecirql.com/platforms/sage-200/", "summary": "Business management for manufacturing.", "description": "Sage 200 is a UK-favoured business management platform, popular with manufacturers, distributors and multichannel retailers in the £5m to £50m range. It handles the operational accounting and stock surface with the dialect British businesses are used to.\n\nPatchworks integrates Sage 200 for sales-order ingest from ecommerce and marketplace channels, stock and pricing sync, purchase-order generation and finance postings. The data model rewards integrations that respect its accounting conventions; the integrations that try to treat it as a generic database tend to need rework.\n\nWe have shipped Sage 200 integrations across both standard and customised deployments, and the customised case in particular benefits from Patchworks's per-flow scoping.", "featured": false }, { "slug": "salesforce-commerce-cloud", "name": "Salesforce Commerce Cloud", "category": "Ecommerce", "url": "https://www.ecirql.com/platforms/salesforce-commerce-cloud/", "summary": "Enterprise commerce with AI features.", "description": "Salesforce Commerce Cloud, the platform formerly known as Demandware, is the enterprise SaaS commerce platform for B2C retailers with global reach and high-availability needs. The product is opinionated about scale and reasonably opinionated about everything else.\n\nPatchworks integrates Commerce Cloud through its OCAPI and SCAPI surfaces. Orders, customers, products, inventory and pricing flow across the estate; the headless setups using SCAPI in particular benefit from a clean integration boundary that respects the platform's caching and content rules.\n\nCommerce Cloud projects live and die on the surrounding integration estate. We design that estate as part of the project, not after it.", "featured": true }, { "slug": "salsify", "name": "Salsify", "category": "PIM", "url": "https://www.ecirql.com/platforms/salsify/", "summary": "Commerce experience management platform.", "description": "Salsify is a commerce experience management platform combining PIM, DAM and digital shelf analytics, with strong adoption among consumer brands selling through retailer and marketplace channels.\n\nPatchworks integrates Salsify for syndication to retailer portals, marketplaces and direct-to-consumer storefronts, and for inbound supplier feeds, ERP item-master sync and translation services. Channel-specific attribute requirements are where most of the integration design lands.\n\nSalsify rewards integrations that treat the channel as a first-class concept rather than an afterthought.", "featured": true }, { "slug": "sanity", "name": "Sanity", "category": "CMS", "url": "https://www.ecirql.com/platforms/sanity/", "summary": "Headless content management system.", "description": "Sanity is a headless content platform with a structured-content model that suits brands and retailers who want editorial flexibility without a CMS dictating the data shape. The Studio editor and the GROQ query language are unusually thoughtful pieces of tooling.\n\nPatchworks integrates Sanity with commerce platforms, PIMs and operational data sources. Content models, components, locales and previews flow with the editorial team's needs respected and the front-end's data needs met. Co-designing the content model with editorial and engineering is usually the first hour of work that saves the last week.", "featured": false }, { "slug": "scayle", "name": "Scayle", "category": "Ecommerce", "url": "https://www.ecirql.com/platforms/scayle/", "summary": "Commerce platform for fashion brands.", "description": "Scayle is a German-built ecommerce platform, spun out of About You, with a model designed for fashion brands operating at scale. The strength is the operational primitives · drops, B2B/D2C duality, multi-region · that come built in.\n\nPatchworks integrates Scayle for orders to ERPs and 3PLs, products and assortments from PIMs, and the operational data that the brand's wider stack depends on. Fashion brands in particular benefit from an integration design that respects the seasonal cadence the business actually runs at.", "featured": false }, { "slug": "seko-logistics", "name": "Seko Logistics", "category": "WMS & 3PL", "url": "https://www.ecirql.com/platforms/seko-logistics/", "summary": "Global logistics services provider.", "description": "SEKO is a global 3PL with a strong cross-border ecommerce presence, used by brands and retailers shipping internationally that need the customs and freight maturity to do it cleanly.\n\nPatchworks integrates SEKO at the file and API level, depending on the warehouse and the contract. Outbound order release, despatch confirmation, customs documentation and inbound goods are the standard flows. International setups in particular need careful design around customs and the financial reconciliation across regions.", "featured": false }, { "slug": "sftp-connector", "name": "SFTP Connector", "category": "EDI & Files", "url": "https://www.ecirql.com/platforms/sftp-connector/", "summary": "Secure file transfer integration.", "description": "SFTP is not a platform but a protocol, and it is the lowest-common-denominator integration surface for trading partners, ERPs and warehouses that pre-date REST APIs. A surprising amount of operational integration traffic still moves over SFTP.\n\nPatchworks's SFTP connector handles file drops, scheduled polls, encryption and the partner-by-partner conventions every SFTP relationship accretes. The design work is in the file naming, the manifest discipline and the visibility a trading-partner programme needs around what landed when.\n\nSFTP integrations are uncool and durable. We treat them with the same engineering rigour as anything else.", "featured": false }, { "slug": "shipbob", "name": "Shipbob", "category": "WMS & 3PL", "url": "https://www.ecirql.com/platforms/shipbob/", "summary": "Global ecommerce fulfilment network.", "description": "ShipBob is a global ecommerce fulfilment network, with warehouses across the US, UK, EU and Australia, aimed at direct-to-consumer brands that want geographically-distributed fulfilment without negotiating each contract themselves.\n\nPatchworks integrates ShipBob for order release, despatch confirmation, inventory reconciliation across the fulfilment network and returns receipt. Brands using ShipBob across multiple regions benefit most from an integration design that respects the per-region operational conventions ShipBob inherits from each warehouse.", "featured": false }, { "slug": "shiptheory", "name": "Shiptheory", "category": "WMS & 3PL", "url": "https://www.ecirql.com/platforms/shiptheory/", "summary": "Shipping automation platform.", "description": "Shiptheory is a UK shipping automation platform that connects ecommerce and marketplace orders to a long list of carriers, handling label generation, manifest discipline and despatch confirmations.\n\nPatchworks integrates Shiptheory for outbound order release, carrier and service selection, label generation and tracking-event delivery. The interesting work is usually in the rules · which carrier for which service for which order · and the operational fallback when a carrier integration goes down.", "featured": false }, { "slug": "shopify", "name": "Shopify", "category": "Ecommerce", "url": "https://www.ecirql.com/platforms/shopify/", "summary": "Complete commerce platform for online retail.", "description": "Shopify runs more direct-to-consumer commerce than any other platform, with a SaaS model that scales from one-person shops to enterprise brands on Shopify Plus. The API surface · REST, GraphQL, webhooks and the Storefront API · is the most-used integration surface in modern commerce.\n\nPatchworks integrates Shopify for orders to ERPs and OMS, products and inventory from PIMs and ERPs, customers to the marketing stack, and the multi-store and B2B variants Shopify Plus introduces. Headless deployments using Hydrogen or third-party storefronts add their own integration considerations, mostly around content and personalisation.\n\nOur team ships Shopify integrations daily, and the depth shows up in the boring details: webhook reliability under retry, idempotency on order create, the difference between draft and committed inventory in a real operation.", "featured": true }, { "slug": "shopline", "name": "Shopline", "category": "Ecommerce", "url": "https://www.ecirql.com/platforms/shopline/", "summary": "Asian-focused ecommerce solution.", "description": "SHOPLINE is an Asian-headquartered ecommerce platform with a strong presence in Greater China, Southeast Asia and an expanding international footprint. The product is well-suited to brands operating in or expanding into APAC markets.\n\nPatchworks integrates SHOPLINE for orders to ERPs and fulfilment systems, products and inventory from PIMs and ERPs, and customer data flows. Cross-region setups in particular benefit from an integration design that respects local-market conventions around payment, returns and customer data.", "featured": false }, { "slug": "shopware", "name": "Shopware", "category": "Ecommerce", "url": "https://www.ecirql.com/platforms/shopware/", "summary": "Experience-driven commerce platform.", "description": "Shopware is a German-built commerce platform with strong adoption across the DACH region and an increasing presence in international markets. The architecture combines headless flexibility with a feature-rich classic admin, and the open-source community version sits alongside the commercial offering.\n\nPatchworks integrates Shopware through its REST and GraphQL APIs for orders, customers, products and content. B2B Shopware deployments have their own dimension · quote workflows, hierarchical account structures · that integrations need to model rather than flatten.\n\nShopware integrations work best when the customisations the merchant has made are understood before the API work begins.", "featured": false }, { "slug": "sitoo", "name": "Sitoo", "category": "POS", "url": "https://www.ecirql.com/platforms/sitoo/", "summary": "Cloud POS for unified commerce.", "description": "Sitoo is a cloud POS platform built specifically for unified commerce, used by retailers running multi-store networks alongside ecommerce. The data model treats store and online as a single operation rather than two systems pretending to agree.\n\nPatchworks integrates Sitoo for store-to-online stock and customer mastering, sales transactions into accounting and ERP, and operational reporting flows. The reconciliation work · making sure store and online agree on inventory, customer state and loyalty balance · is where most of the integration value lives.", "featured": false }, { "slug": "snowflake", "name": "Snowflake", "category": "Data & BI", "url": "https://www.ecirql.com/platforms/snowflake/", "summary": "Cloud data platform for enterprises.", "description": "Snowflake is the cloud data platform that has displaced the older data-warehouse incumbents across mid-market and enterprise. The separation of storage and compute, the SQL surface and the partner ecosystem make it the default destination for analytical workloads in retail.\n\nPatchworks integrates Snowflake as a destination, source or both. Operational data lands on schedule or via event triggers; analytical outputs and segments flow back into operational tools. The freshness and shape of the data going in determines whether downstream analytics is useful or merely impressive.", "featured": false }, { "slug": "sparklayer-b2b", "name": "Sparklayer B2B", "category": "Ecommerce", "url": "https://www.ecirql.com/platforms/sparklayer-b2b/", "summary": "Wholesale ecommerce platform.", "description": "SparkLayer adds B2B wholesale ordering on top of Shopify and BigCommerce storefronts, with quote workflows, account-level pricing and B2B customer behaviours that the base commerce platforms do not natively support cleanly.\n\nPatchworks integrates SparkLayer with the rest of the stack: orders to ERPs, accounts and pricing from CRMs and ERPs, and inventory visibility from the warehouse. B2B-specific rules · credit terms, payment behaviours, account hierarchies · are the design work that determines whether SparkLayer ends up running the B2B operation or just storing it.", "featured": false }, { "slug": "stokly", "name": "Stok.ly", "category": "ERP", "url": "https://www.ecirql.com/platforms/stokly/", "summary": "Retail management and EPOS system.", "description": "Stok.ly is a UK-built retail management and EPOS system aimed at independent and growing multi-site retailers that want unified commerce primitives without enterprise pricing.\n\nPatchworks integrates Stok.ly for store-to-online stock visibility, customer mastering, sales transactions into accounting and ERP, and operational reporting. Multi-site retailers in particular benefit from an integration design that respects the reconciliation cadence the business actually runs at.", "featured": false }, { "slug": "swap-commerce", "name": "Swap Commerce", "category": "Returns", "url": "https://www.ecirql.com/platforms/swap-commerce/", "summary": "Returns optimisation platform.", "description": "Swap is a returns and post-purchase platform focused on retention through exchanges, store credit and lifetime-value-aware refund decisions, rather than treating every return as a refund opportunity.\n\nPatchworks integrates Swap for RMA flows, exchange and store-credit decisions, restocking signals and customer-service handoffs. The integration design that determines retention outcomes is mostly in the inventory-visibility and exchange-eligibility rules, which deserve real care.", "featured": false }, { "slug": "tempo", "name": "Tempo", "category": "Project Management", "url": "https://www.ecirql.com/platforms/tempo/", "summary": "Time tracking and project planning.", "description": "Tempo is an Atlassian-ecosystem time tracking and resource planning tool, used by agencies, consultancies and product teams that need professional-services-grade time data on top of Jira.\n\nPatchworks integrates Tempo for time and cost data into finance and billing systems, project state into operational reporting and back-flow from operational systems into project plans. The integration scope is usually narrow; the discipline is in the data conventions that make finance happy.", "featured": false }, { "slug": "the-edge-by-john-lewis", "name": "The Edge By John Lewis", "category": "Marketplaces", "url": "https://www.ecirql.com/platforms/the-edge-by-john-lewis/", "summary": "Marketplace for John Lewis partners.", "description": "The Edge by John Lewis is the John Lewis Partnership's marketplace programme, allowing third-party retailers to list and sell through John Lewis's curated storefront.\n\nPatchworks integrates The Edge for product feed publication, inventory and pricing sync, order ingestion and the operational handoffs the marketplace's SLAs require. UK retailers operating on The Edge benefit from an integration design that treats it with the discipline of any other tier-one marketplace.", "featured": false }, { "slug": "tiktok-shop", "name": "TikTok Shop", "category": "Marketplaces", "url": "https://www.ecirql.com/platforms/tiktok-shop/", "summary": "Social commerce on TikTok platform.", "description": "TikTok Shop is the social-commerce arm of TikTok, combining short-form video, live shopping and direct in-app checkout. For brands that have already built a TikTok audience it is one of the fastest-paying channels in current commerce.\n\nPatchworks integrates TikTok Shop for product feed publication, inventory and pricing sync, order ingestion and the social-commerce-specific events that conversion attribution and influencer programmes depend on. The operational dimension · fulfilment SLAs, return windows, dispute handling · works similarly to other marketplaces despite the channel feeling different to the marketing team.", "featured": false }, { "slug": "torque", "name": "Torque", "category": "WMS & 3PL", "url": "https://www.ecirql.com/platforms/torque/", "summary": "Fashion logistics provider.", "description": "Torque is a fashion logistics provider, with operational primitives shaped for apparel and accessories · value-add services, garment-on-hanger, returns processing · that generic 3PLs do not surface as cleanly.\n\nPatchworks integrates Torque for outbound order release, despatch confirmation, inventory reconciliation and returns receipt. Fashion-specific value-add services are where the integration design earns its keep.", "featured": false }, { "slug": "trello", "name": "Trello", "category": "Project Management", "url": "https://www.ecirql.com/platforms/trello/", "summary": "Visual task management tool.", "description": "Trello is Atlassian's visual project management tool, used widely outside engineering for operational checklists, content production, supplier onboarding and the daily-cadence work that does not justify a full PM system.\n\nPatchworks integrates Trello where the visual board needs to talk to the systems that fulfil what the board promises: order operations, customer service workflows, content pipelines. The design effort is in deciding when the board is the source of truth and when it is the dashboard.", "featured": false }, { "slug": "twilio", "name": "Twilio", "category": "Marketing", "url": "https://www.ecirql.com/platforms/twilio/", "summary": "Cloud communications platform.", "description": "Twilio is the default cloud communications platform: SMS, voice, WhatsApp, email, the lot, behind a single developer-friendly API. For ecommerce specifically, transactional messaging and conversational commerce are the integration surfaces that matter.\n\nPatchworks integrates Twilio for transactional message triggers from operational systems, two-way conversational flows and message delivery telemetry into the CRM. Consent state and message-template discipline are the integration concerns that determine whether deliverability holds up at scale.", "featured": false }, { "slug": "veeqo", "name": "Veeqo", "category": "WMS & 3PL", "url": "https://www.ecirql.com/platforms/veeqo/", "summary": "Inventory and shipping management.", "description": "Veeqo is an inventory and shipping management platform, now owned by Amazon and free to use for sellers on the Amazon ecosystem. It handles multichannel inventory, shipping label generation and fulfilment-status flows.\n\nPatchworks integrates Veeqo for multichannel inventory sync, sales-order ingest from non-Amazon channels and shipping despatch. The Amazon ownership tilts the product towards Amazon-first sellers; the integration design needs to respect that without flattening the rest of the channel mix.", "featured": false }, { "slug": "virtualstock", "name": "Virtualstock", "category": "Marketplaces", "url": "https://www.ecirql.com/platforms/virtualstock/", "summary": "Dropship marketplace platform.", "description": "Virtualstock runs a dropship marketplace platform used by some of the largest UK retailers, with seller onboarding, product catalogues, order routing and dispute handling at the kind of scale the John Lewises and Argoses of the world require.\n\nPatchworks integrates Virtualstock for seller-side product feed publishing, inventory and pricing sync, and order ingestion. Operator-side flows handle seller onboarding and dispute reconciliation. The financial reconciliation across the seller base is where the integration design earns its keep.", "featured": false }, { "slug": "visual-next", "name": "Visual Next", "category": "ERP", "url": "https://www.ecirql.com/platforms/visual-next/", "summary": "Fashion business management software.", "description": "Visual Next is a fashion-vertical business management platform, used by apparel brands and retailers that need product lifecycle, planning, sourcing and inventory in one system.\n\nPatchworks integrates Visual Next where the fashion supply chain meets the rest of the operation: product lifecycle into PIM and ecommerce, inventory and allocation into the storefront and warehouse, finance and merchandising flows into the wider estate.", "featured": false }, { "slug": "visualsoft", "name": "Visualsoft", "category": "Ecommerce", "url": "https://www.ecirql.com/platforms/visualsoft/", "summary": "Full-service ecommerce solution.", "description": "Visualsoft is a UK full-service ecommerce platform, with hosting, design and the storefront platform combined. It is used by mid-market UK retailers who want a single provider for the technology and the agency side.\n\nPatchworks integrates Visualsoft with the rest of the operational estate: orders into ERPs, inventory and pricing into the storefront, customer data into the marketing stack. Visualsoft's full-service positioning means the integration work usually sits at the boundary with systems Visualsoft does not run.", "featured": false }, { "slug": "voyado", "name": "Voyado", "category": "CRM", "url": "https://www.ecirql.com/platforms/voyado/", "summary": "Retail loyalty and CRM platform.", "description": "Voyado is a Nordic-built retail loyalty and CRM platform, with strong adoption among European fashion and lifestyle brands that want loyalty mechanics · points, tiers, member-only experiences · wired into the customer data layer rather than bolted onto it.\n\nPatchworks integrates Voyado for customer mastering across channels, transactional and behavioural events, loyalty-balance reconciliation and back-flow of segment and prediction data. Cross-channel identity resolution is the design work that determines whether the loyalty programme reflects reality.", "featured": false }, { "slug": "whistl", "name": "Whistl", "category": "WMS & 3PL", "url": "https://www.ecirql.com/platforms/whistl/", "summary": "Mail and parcel delivery service.", "description": "Whistl is a UK postal and parcel delivery business, with a portfolio covering door-drop, fulfilment, returns and parcel delivery for brands and retailers across the country.\n\nPatchworks integrates Whistl for despatch automation, tracking events, returns receipt and the operational signals customer service and finance need. UK domestic logistics is the home ground; the integration design respects that focus rather than pretending to span more.", "featured": false }, { "slug": "woocommerce", "name": "WooCommerce", "category": "Ecommerce", "url": "https://www.ecirql.com/platforms/woocommerce/", "summary": "WordPress ecommerce plugin.", "description": "WooCommerce is the WordPress ecommerce plugin, the most-deployed ecommerce platform on the planet by absolute count if not by enterprise gravitas. The strength is the WordPress ecosystem; the variability is that no two WooCommerce stores are alike.\n\nPatchworks integrates WooCommerce through its REST API. Orders to ERPs and OMS, products and inventory from PIMs and ERPs, customers to the marketing stack · the integration scope is similar to other ecommerce platforms but the surface beneath it is whatever the merchant's plugin estate looks like.\n\nWooCommerce integrations work best when the plugin estate is understood up front. There is no such thing as a generic WooCommerce connector for a store with twenty plugins active.", "featured": false }, { "slug": "xero", "name": "Xero", "category": "Accounting", "url": "https://www.ecirql.com/platforms/xero/", "summary": "Cloud accounting for small business.", "description": "Xero is the cloud accounting platform of choice for UK, Australian and New Zealand SMBs, with a steadily growing footprint elsewhere. The product is opinionated about bookkeeper experience, which is most of its value.\n\nPatchworks integrates Xero for invoice and credit-note creation, customer mastering, payment reconciliation and ledger postings from ecommerce, ERP and marketplace channels. Tracking categories and chart-of-accounts mapping at integration time are the discipline that determines whether finance can close cleanly each month.", "featured": false }, { "slug": "zap-post", "name": "ZAP~POST", "category": "Marketing", "url": "https://www.ecirql.com/platforms/zap-post/", "summary": "Direct mail automation platform.", "description": "ZAP~POST is a UK direct-mail automation platform, allowing ecommerce brands to trigger physical mail · postcards, letters, samples · from operational events the same way they would trigger an email.\n\nPatchworks integrates ZAP~POST for trigger-event delivery from operational systems, address mastering and back-flow of send and delivery confirmations. Physical mail has a longer feedback loop than digital, which deserves real care in the trigger logic.", "featured": false }, { "slug": "zendesk", "name": "Zendesk", "category": "Service Desk", "url": "https://www.ecirql.com/platforms/zendesk/", "summary": "Customer service platform.", "description": "Zendesk is the default enterprise customer service platform, with strong agent workflows, automation and integration breadth. For ecommerce specifically, the integration scope is around order context, post-purchase events and the customer-history surface agents need.\n\nPatchworks integrates Zendesk for ticket creation, customer-context lookup against ERP and ecommerce data, automated routing and resolution feedback into the CRM. The work that pays off most is closing the loop between support and operations: tickets with the right context, agents with the right tools, finance with the right reconciliation.", "featured": false }, { "slug": "zigzag-returns", "name": "ZigZag Returns", "category": "Returns", "url": "https://www.ecirql.com/platforms/zigzag-returns/", "summary": "Global returns management platform.", "description": "ZigZag is a global returns platform with a particular strength in cross-border returns and the consolidation that makes them economical. It is used by brands and retailers managing international returns flows that do not fit a single 3PL.\n\nPatchworks integrates ZigZag for RMA creation, courier handoffs, returns-status events, customs documentation and refund triggers. Cross-border returns are unforgiving operationally; the integration design respects that and surfaces the failure modes early.", "featured": false } ], "integration_combos": [ { "slug": "shopify-to-netsuite", "a": "shopify", "b": "netsuite", "url": "https://www.ecirql.com/integrations/shopify-to-netsuite/", "lead": "Shopify is where the orders come in. NetSuite is where the business runs: stock, finance, customers, fulfilment, the lot. Connecting them properly means deciding which side owns each piece of data, then enforcing that decision in every flow that moves between them. We design, build and support Shopify-to-NetSuite integrations as a certified Patchworks Partner Agency. Order capture, customer sync, inventory and pricing publication, fulfilment writeback, refunds and tax. Same team for delivery and ongoing support, with a defined SLA from day one.", "patchworks_angle": "The canonical Shopify-to-NetSuite patterns are well-trodden on Patchworks: orders, customers, items, inventory and fulfilment events. Our delivery extends those patterns where the merchant's NetSuite account diverges from the template: custom record types, OneWorld subsidiary routing, non-standard item types, locked-period handling. We build directly in Patchworks, version flows alongside the merchant's release process, and hand over a runbook the on-call engineer can act on at three in the morning without needing to call us.", "flow": { "title": "Order sync: Shopify to NetSuite", "description": "The flow that runs every time a customer checks out on Shopify. Built once in Patchworks, monitored continuously, idempotent end to end.", "steps": [ { "kind": "trigger", "system": "Shopify", "label": "Order created", "detail": "order/create webhook" }, { "kind": "extract", "system": "Patchworks", "label": "Ingest payload", "detail": "queue, dedupe, normalise" }, { "kind": "transform", "system": "Patchworks", "label": "Map data", "detail": "line items, taxes, discounts, currency" }, { "kind": "decision", "system": "Patchworks", "label": "Customer exists?", "detail": "lookup by email / external ID" }, { "kind": "transform", "system": "Patchworks", "label": "Enrich", "detail": "item refs, subsidiary, tax codes" }, { "kind": "action", "system": "NetSuite", "label": "Create Sales Order", "detail": "via SuiteTalk / RESTlet" }, { "kind": "writeback", "system": "Shopify", "label": "Tag order", "detail": "store NetSuite document number" } ] }, "timeline": { "weeks": "6 to 10 weeks for a standard delivery", "phases": [ { "label": "Week 1", "detail": "Discovery: data-model walkthrough, NetSuite record-type choice, edge-case mapping." }, { "label": "Weeks 2 to 4", "detail": "Build: order, customer, inventory, fulfilment and refund flows in Patchworks." }, { "label": "Weeks 5 to 6", "detail": "Integration testing against real Shopify and NetSuite sandbox data." }, { "label": "Weeks 7 to 8", "detail": "UAT with operations and finance teams; sign-off on edge cases." }, { "label": "Weeks 9 to 10", "detail": "Cutover and hyper-care; transition into support retainer with monitoring and SLA." } ] }, "capabilities": [ { "capability": "order-sync", "label": "Order sync", "source": "shopify", "target": "netsuite" }, { "capability": "inventory-sync", "label": "Inventory sync", "source": "netsuite", "target": "shopify" }, { "capability": "product-sync", "label": "Product sync", "source": "netsuite", "target": "shopify" }, { "capability": "pricing-sync", "label": "Pricing sync", "source": "netsuite", "target": "shopify" }, { "capability": "customer-sync", "label": "Customer sync", "source": "shopify", "target": "netsuite" }, { "capability": "returns-sync", "label": "Returns sync", "source": "shopify", "target": "netsuite" }, { "capability": "refund-sync", "label": "Refund sync", "source": "netsuite", "target": "shopify" }, { "capability": "tax-sync", "label": "Tax sync", "source": "netsuite", "target": "shopify" } ], "faqs": [ { "q": "Do we need NetSuite OneWorld?", "a": "No. The integration works with single-instance NetSuite and OneWorld. OneWorld is required where you trade through multiple subsidiaries with separate ledgers; for many UK merchants single-instance is the right call." }, { "q": "How does the integration handle Shopify gift cards?", "a": "Gift card sales post to NetSuite as a deferred-revenue line against a liability account; redemptions release the liability against the order they're used on. We don't collapse the two events into a single discount line, because that breaks the VAT trail." }, { "q": "Can we keep Shopify's inventory native, or must NetSuite be the source?", "a": "Either pattern is supportable. The right answer depends on where the operational workflow sits. For merchants with multiple sales channels we generally make NetSuite the source of truth, with channel-aware availability rules pushing into Shopify; for single-channel Shopify merchants the inverse is sometimes simpler." }, { "q": "What about Shopify Plus checkout extensibility?", "a": "Supported. Custom checkout fields land on the order payload and map into NetSuite custom transaction fields. We define the mapping at scoping so finance and operations both know what's where." }, { "q": "Do you support Shopify-to-NetSuite under SLA after go-live?", "a": "Yes. The same team that builds the integration runs it under retainer. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month." } ] }, { "slug": "shopify-to-sage-200", "a": "shopify", "b": "sage-200", "url": "https://www.ecirql.com/integrations/shopify-to-sage-200/", "lead": "Shopify is the storefront. Sage 200 is where the UK back office runs: nominal ledger, stock, purchase orders, VAT, the whole accounting and operational stack. The integration moves orders, customers and payments out of Shopify into Sage 200 as proper sales documents, and pushes stock and pricing back the other way so the storefront reflects the warehouse rather than wishful inventory. We design, build and support Shopify-to-Sage 200 integrations as a Patchworks Partner Agency, with the SLA picking up the moment the integration goes live.", "patchworks_angle": "Sage 200's data model is built around accounting conventions rather than ecommerce expectations, and integrations that try to ignore that tend to need rework within months. We build the Shopify-to-Sage 200 flows directly in Patchworks, mapping orders onto the right Sage transaction types, respecting nominal codes and VAT groups, and letting Sage's batch posting cadence drive the rhythm where finance needs it to. The runbook covers the edge cases Sage tends to surface loudest at month-end.", "flow": { "title": "Order sync: Shopify to Sage 200", "description": "How a Shopify order lands as a Sage 200 sales document, with VAT, nominal codes and customer ledger entries in the right place from the first run.", "steps": [ { "kind": "trigger", "system": "Shopify", "label": "Order created", "detail": "order/create webhook" }, { "kind": "extract", "system": "Patchworks", "label": "Ingest payload", "detail": "queue, dedupe, normalise" }, { "kind": "transform", "system": "Patchworks", "label": "Resolve VAT codes", "detail": "rate, group, reverse-charge" }, { "kind": "decision", "system": "Patchworks", "label": "Customer exists?", "detail": "Sage account lookup" }, { "kind": "transform", "system": "Patchworks", "label": "Map to sales order", "detail": "nominal codes, analysis fields" }, { "kind": "action", "system": "Sage 200", "label": "Post sales order", "detail": "via Sage API" }, { "kind": "writeback", "system": "Shopify", "label": "Tag order", "detail": "store Sage document number" } ] }, "timeline": { "weeks": "6 to 9 weeks for a standard delivery", "phases": [ { "label": "Week 1", "detail": "Discovery: Sage 200 chart-of-accounts walkthrough, VAT scheme, nominal posting rules." }, { "label": "Weeks 2 to 4", "detail": "Build: order, customer, stock and pricing flows in Patchworks." }, { "label": "Weeks 5 to 6", "detail": "Integration testing against the live Sage instance using a staged Shopify store." }, { "label": "Weeks 7 to 8", "detail": "UAT with finance and operations; sign-off on VAT and nominal mappings." }, { "label": "Week 9", "detail": "Cutover and hyper-care; transition into support retainer with monitoring and SLA." } ] }, "capabilities": [ { "capability": "order-sync", "label": "Order sync", "source": "shopify", "target": "sage-200" }, { "capability": "inventory-sync", "label": "Inventory sync", "source": "sage-200", "target": "shopify" }, { "capability": "product-sync", "label": "Product sync", "source": "sage-200", "target": "shopify" }, { "capability": "pricing-sync", "label": "Pricing sync", "source": "sage-200", "target": "shopify" }, { "capability": "customer-sync", "label": "Customer sync", "source": "shopify", "target": "sage-200" }, { "capability": "returns-sync", "label": "Returns sync", "source": "shopify", "target": "sage-200" }, { "capability": "refund-sync", "label": "Refund sync", "source": "shopify", "target": "sage-200" }, { "capability": "tax-sync", "label": "Tax sync", "source": "sage-200", "target": "shopify" } ], "faqs": [ { "q": "Does the integration work with Sage 200 on-premise or only Sage 200 Cloud?", "a": "Both. The Patchworks connector supports Sage 200 Standard (cloud-hosted) and Sage 200 Professional (on-premise or partner-hosted). The flow logic is the same; the access path differs." }, { "q": "How are Shopify discounts represented in Sage 200?", "a": "Order-level and line-level discounts post as discount lines against the relevant nominal code rather than being baked into the unit price. Finance can see what was sold at what value and what was discounted; reporting stays honest." }, { "q": "Can Sage 200 stock drive Shopify availability?", "a": "Yes. For most engagements Sage is the source of truth for stock, with location-aware availability rules publishing to Shopify on a delta schedule plus event-driven updates on warehouse movement. Safety stock buffers are configurable per SKU group." }, { "q": "What about multi-currency orders?", "a": "Supported. Shopify Markets orders post to Sage 200 in the order currency, with FX policy applied at the configured rate. We agree the rate source at scoping so finance isn't reconciling two interpretations." }, { "q": "Do you support Shopify-to-Sage 200 under SLA after go-live?", "a": "Yes. The same team that builds the integration runs it under retainer. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month." } ] }, { "slug": "netsuite-to-amazon-seller-central", "a": "netsuite", "b": "amazon-seller-central", "url": "https://www.ecirql.com/integrations/netsuite-to-amazon-seller-central/", "lead": "Selling on Amazon is half the work. Reconciling Amazon back into the ERP without losing the trail is the other half. Our NetSuite to Amazon Seller Central integration runs the listings, the inventory, the order ingest and the settlement reconciliation as one connected flow, so the finance team sees Amazon revenue land in the right GL accounts and the operations team sees Amazon orders alongside the rest of the channel mix. We deliver and support the integration as a certified Patchworks Partner Agency.", "patchworks_angle": "Amazon's seller APIs change often and rarely warn you. The Patchworks connector abstracts the moving parts so the merchant-side flows stay stable when Amazon shifts a schema or deprecates an endpoint. We build NetSuite-to-Amazon delivery directly in Patchworks: product publication, inventory sync per marketplace, order ingest, fulfilment writeback for on-time-dispatch SLA, and settlement reports reconciled line by line against NetSuite transactions and item-fulfilment records.", "flow": { "title": "Order ingest: Amazon Seller Central to NetSuite", "description": "How an Amazon order lands as a NetSuite Sales Order with the marketplace-of-record tax treatment, channel attribution and settlement linkage in place from the first run.", "steps": [ { "kind": "trigger", "system": "Amazon", "label": "Order notification", "detail": "MWS / SP-API polling" }, { "kind": "extract", "system": "Patchworks", "label": "Fetch order detail", "detail": "items, address, fees" }, { "kind": "transform", "system": "Patchworks", "label": "Apply MoR tax rule", "detail": "marketplace-of-record VAT / sales tax" }, { "kind": "decision", "system": "Patchworks", "label": "FBA or seller-fulfilled?", "detail": "routes to different downstream flows" }, { "kind": "transform", "system": "Patchworks", "label": "Map to NetSuite SO", "detail": "channel = Amazon, attribution fields" }, { "kind": "action", "system": "NetSuite", "label": "Create Sales Order", "detail": "linked to channel and subsidiary" }, { "kind": "writeback", "system": "Amazon", "label": "Acknowledge", "detail": "ready-to-ship / dispatch SLA clock" } ] }, "timeline": { "weeks": "5 to 8 weeks for a standard delivery", "phases": [ { "label": "Week 1", "detail": "Discovery: marketplace scope (UK / EU / US), FBA vs seller-fulfilled mix, tax-of-record handling." }, { "label": "Weeks 2 to 4", "detail": "Build: listing, inventory, order, fulfilment and settlement flows in Patchworks." }, { "label": "Weeks 5 to 6", "detail": "Integration testing against the Amazon sandbox and NetSuite, including settlement reconciliation." }, { "label": "Week 7", "detail": "UAT with operations and finance; sign-off on FBA edge cases and chargeback handling." }, { "label": "Week 8", "detail": "Cutover and hyper-care; transition into support retainer with monitoring and SLA." } ] }, "capabilities": [ { "capability": "order-sync", "label": "Order sync", "source": "amazon-seller-central", "target": "netsuite" }, { "capability": "inventory-sync", "label": "Inventory sync", "source": "netsuite", "target": "amazon-seller-central" }, { "capability": "product-sync", "label": "Product sync", "source": "netsuite", "target": "amazon-seller-central" }, { "capability": "pricing-sync", "label": "Pricing sync", "source": "netsuite", "target": "amazon-seller-central" }, { "capability": "settlement-recon", "label": "Settlement reconciliation", "source": "amazon-seller-central", "target": "netsuite" } ], "faqs": [ { "q": "Can the integration handle multiple Amazon marketplaces?", "a": "Yes. Each marketplace (Amazon.co.uk, Amazon.de, Amazon.com, and so on) maps to its own NetSuite channel and subsidiary where appropriate. Listings, inventory and orders are scoped per marketplace, with shared product master data where it makes sense." }, { "q": "How does settlement reconciliation work?", "a": "Amazon settlement reports import line by line. Each line matches to the underlying NetSuite transaction (order, refund, adjustment, fee) or surfaces as an unmatched item for finance review. Nothing is silently dropped, and the GL impact is itemised rather than lumped into a single 'marketplace fees' bucket." }, { "q": "Do you support FBA inventory?", "a": "Yes. FBA inventory is modelled as a distinct NetSuite location with its own availability rules. Sellable inventory at FBA is published back to Amazon listings; movement between FBA and merchant locations is logged so the operations team sees the full stock picture." }, { "q": "What happens when Amazon updates the SP-API?", "a": "The Patchworks connector absorbs most schema and endpoint changes without the merchant-side flows needing rework. Where a change is structural, the support retainer covers the upgrade work within the same agreement rather than as a separate procurement." }, { "q": "Do you support NetSuite-to-Amazon under SLA after go-live?", "a": "Yes. The same team that builds the integration runs it under retainer. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month." } ] }, { "slug": "shopify-to-descartes-peoplevox", "a": "shopify", "b": "descartes-peoplevox", "url": "https://www.ecirql.com/integrations/shopify-to-descartes-peoplevox/", "lead": "Peoplevox is one of the most capable warehouse management systems in UK ecommerce, and Shopify is the storefront most often sitting in front of it. The integration carries the order from the moment it's placed through to the moment it leaves the warehouse, and then carries the fulfilment and tracking back so the customer-facing surface reflects reality rather than the warehouse's last known state. We design, build and support Shopify-to-Peoplevox integrations as a Patchworks Partner Agency.", "patchworks_angle": "Peoplevox rewards integrations that respect its picking, packing and dispatch model rather than treating it as a generic order sink. We build the Shopify-to-Peoplevox flows in Patchworks with explicit handling for split shipments, partial fulfilments, back-orders, gift messages and the carrier service rules Peoplevox uses to route work on the warehouse floor. Inventory, fulfilment and tracking flow back into Shopify in the same Patchworks integration so the storefront stays honest end to end.", "flow": { "title": "Order to dispatch: Shopify to Peoplevox", "description": "How an order moves from Shopify checkout to a Peoplevox pick wave and back as a dispatched fulfilment with carrier tracking in place.", "steps": [ { "kind": "trigger", "system": "Shopify", "label": "Order created", "detail": "order/create webhook" }, { "kind": "extract", "system": "Patchworks", "label": "Ingest payload", "detail": "queue, dedupe, normalise" }, { "kind": "transform", "system": "Patchworks", "label": "Resolve service", "detail": "carrier, service level, packaging hints" }, { "kind": "action", "system": "Peoplevox", "label": "Create sales order", "detail": "with pick priority and split rules" }, { "kind": "trigger", "system": "Peoplevox", "label": "Fulfilment event", "detail": "dispatch confirmation with tracking" }, { "kind": "transform", "system": "Patchworks", "label": "Map fulfilment", "detail": "line-level, partial-shipment safe" }, { "kind": "writeback", "system": "Shopify", "label": "Update order", "detail": "fulfilment, tracking, customer notification" } ] }, "timeline": { "weeks": "4 to 7 weeks for a standard delivery", "phases": [ { "label": "Week 1", "detail": "Discovery: Peoplevox warehouse setup, carrier mix, packaging hints, fulfilment rules." }, { "label": "Weeks 2 to 3", "detail": "Build: order, fulfilment, inventory and tracking flows in Patchworks." }, { "label": "Weeks 4 to 5", "detail": "Integration testing against a real Peoplevox sandbox using staged Shopify orders." }, { "label": "Week 6", "detail": "UAT with the warehouse team; sign-off on split shipments and carrier routing edge cases." }, { "label": "Week 7", "detail": "Cutover and hyper-care; transition into support retainer with monitoring and SLA." } ] }, "capabilities": [ { "capability": "order-sync", "label": "Order sync", "source": "shopify", "target": "descartes-peoplevox" }, { "capability": "inventory-sync", "label": "Inventory sync", "source": "descartes-peoplevox", "target": "shopify" }, { "capability": "fulfilment-sync", "label": "Fulfilment sync", "source": "descartes-peoplevox", "target": "shopify" }, { "capability": "tracking-sync", "label": "Tracking sync", "source": "descartes-peoplevox", "target": "shopify" }, { "capability": "returns-sync", "label": "Returns sync", "source": "shopify", "target": "descartes-peoplevox" } ], "faqs": [ { "q": "Can Peoplevox inventory drive Shopify availability?", "a": "Yes. Peoplevox can be the source of truth for sellable stock, with channel-aware availability rules publishing to Shopify on a fast cadence plus event-driven updates on receipt and movement. Safety stock buffers are configurable per SKU group and per location." }, { "q": "How does the integration handle split shipments?", "a": "Split shipments are first-class. When Peoplevox ships an order across multiple parcels, each fulfilment posts back to Shopify with its own carrier, service level and tracking number against the right order lines. Customer notification fires per parcel rather than collapsing into a single 'shipped' event." }, { "q": "What about gift messages and packaging hints?", "a": "Carried through. Custom Shopify checkout fields, line-item attributes and order notes map onto Peoplevox fields the warehouse team can act on at pick and pack time. We define the mapping during scoping so nothing arrives at the warehouse as a surprise." }, { "q": "How are returns handled?", "a": "The integration treats returns as an inbound flow into Peoplevox with a reason code and inspection state. Where you also run a returns platform (ReturnGO, Returnless, or similar), the three-way flow runs in the same Patchworks integration as the outbound fulfilment." }, { "q": "Do you support Shopify-to-Peoplevox under SLA after go-live?", "a": "Yes. The same team that builds the integration runs it under retainer. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month." } ] }, { "slug": "shopify-to-brightpearl", "a": "shopify", "b": "brightpearl", "url": "https://www.ecirql.com/integrations/shopify-to-brightpearl/", "lead": "Brightpearl is a retail operations platform that does a lot in one place: orders, inventory, purchasing, accounting and CRM. Sitting it behind Shopify means deciding which side of that combined surface owns each piece of data, and enforcing that decision in every flow. We design, build and support Shopify-to-Brightpearl integrations as a certified Patchworks Partner Agency. Orders, customers, inventory, pricing, fulfilments and credit notes flow as one coherent estate rather than a stack of point-to-point connections.", "patchworks_angle": "Brightpearl has a clear opinion about how retail operations should run, and integrations that respect that opinion are the ones that stay clean. We build the Shopify-to-Brightpearl flows in Patchworks with explicit handling for Brightpearl's order lifecycle, pick-and-pack model, and accounting treatment. Inventory rules per warehouse, automatic SKU routing, and the events that Brightpearl emits on shipment all flow back into Shopify so the storefront reads the same state operations and finance do.", "flow": { "title": "Order sync: Shopify to Brightpearl", "description": "How a Shopify order lands as a Brightpearl sales order with the warehouse routing, accounting treatment and customer record in place from the first run.", "steps": [ { "kind": "trigger", "system": "Shopify", "label": "Order created", "detail": "order/create webhook" }, { "kind": "extract", "system": "Patchworks", "label": "Ingest payload", "detail": "queue, dedupe, normalise" }, { "kind": "decision", "system": "Patchworks", "label": "Customer exists?", "detail": "Brightpearl contact lookup" }, { "kind": "transform", "system": "Patchworks", "label": "Resolve warehouse", "detail": "SKU routing, location rules" }, { "kind": "transform", "system": "Patchworks", "label": "Map to sales order", "detail": "lines, taxes, payment status" }, { "kind": "action", "system": "Brightpearl", "label": "Create sales order", "detail": "via Brightpearl API" }, { "kind": "writeback", "system": "Shopify", "label": "Tag order", "detail": "store Brightpearl reference" } ] }, "timeline": { "weeks": "5 to 8 weeks for a standard delivery", "phases": [ { "label": "Week 1", "detail": "Discovery: Brightpearl account setup, warehouse map, accounting period rules, fulfilment workflow." }, { "label": "Weeks 2 to 4", "detail": "Build: order, customer, inventory, fulfilment and credit-note flows in Patchworks." }, { "label": "Weeks 5 to 6", "detail": "Integration testing against the Brightpearl sandbox using staged Shopify orders." }, { "label": "Week 7", "detail": "UAT with operations and finance; sign-off on edge cases and accounting mappings." }, { "label": "Week 8", "detail": "Cutover and hyper-care; transition into support retainer with monitoring and SLA." } ] }, "capabilities": [ { "capability": "order-sync", "label": "Order sync", "source": "shopify", "target": "brightpearl" }, { "capability": "inventory-sync", "label": "Inventory sync", "source": "brightpearl", "target": "shopify" }, { "capability": "product-sync", "label": "Product sync", "source": "brightpearl", "target": "shopify" }, { "capability": "pricing-sync", "label": "Pricing sync", "source": "brightpearl", "target": "shopify" }, { "capability": "customer-sync", "label": "Customer sync", "source": "shopify", "target": "brightpearl" }, { "capability": "returns-sync", "label": "Returns sync", "source": "shopify", "target": "brightpearl" }, { "capability": "refund-sync", "label": "Refund sync", "source": "shopify", "target": "brightpearl" } ], "faqs": [ { "q": "Can Brightpearl own inventory while Shopify shows availability?", "a": "Yes. Brightpearl is typically the source of truth for stock, with channel-aware availability publishing to Shopify on a delta cadence plus event-driven updates on movement. Safety stock buffers are configurable per SKU group and per warehouse." }, { "q": "How are Brightpearl's automation rules respected?", "a": "We build the integration around Brightpearl's automation rather than fighting it. Order status transitions, allocation rules and accounting period locks are treated as authoritative; the Patchworks flows trigger and respect Brightpearl's lifecycle rather than bypassing it." }, { "q": "What about Shopify subscriptions and pre-orders?", "a": "Supported. Subscription rebills post as discrete orders with the subscription metadata mapped onto Brightpearl custom fields. Pre-orders carry a flag so allocation waits for available stock; the order stays open in Brightpearl rather than being auto-cancelled." }, { "q": "Can we use Brightpearl's POS alongside the Shopify integration?", "a": "Yes. The integration is scoped around the Shopify channel; Brightpearl POS sales sit alongside it in Brightpearl as their own channel and the inventory model accounts for both. Where you also use Shopify POS we model that as a third channel." }, { "q": "Do you support Shopify-to-Brightpearl under SLA after go-live?", "a": "Yes. The same team that builds the integration runs it under retainer. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month." } ] }, { "slug": "shopify-to-microsoft-dynamics-business-central", "a": "shopify", "b": "microsoft-dynamics-business-central", "url": "https://www.ecirql.com/integrations/shopify-to-microsoft-dynamics-business-central/", "lead": "Microsoft Dynamics 365 Business Central is where mid-market operations and finance live in a lot of UK and EU retailers. Shopify is increasingly what sits in front of it. The integration carries orders into Business Central as proper sales documents with the right dimensions, posts customer and item data the right direction, and lifts inventory and pricing back out so the storefront stays honest. We design, build and support the integration as a Patchworks Partner Agency, with the SLA picking up from go-live.", "patchworks_angle": "Business Central rewards integrations that respect its document model: orders are sales orders, not generic transactions. We build the Shopify-to-Business-Central flows in Patchworks mapping orders onto the right document types, posting groups and dimensions, with explicit handling for the VAT and currency rules Business Central enforces at posting. Item ledger entries, item availability and unit-of-measure conversions all flow back into Shopify in the same Patchworks integration.", "flow": { "title": "Order sync: Shopify to Business Central", "description": "How a Shopify order lands in Business Central as a sales document with the right posting groups, dimensions and VAT treatment from the first run.", "steps": [ { "kind": "trigger", "system": "Shopify", "label": "Order created", "detail": "order/create webhook" }, { "kind": "extract", "system": "Patchworks", "label": "Ingest payload", "detail": "queue, dedupe, normalise" }, { "kind": "transform", "system": "Patchworks", "label": "Resolve VAT codes", "detail": "rate, posting group, EU rules" }, { "kind": "decision", "system": "Patchworks", "label": "Customer exists?", "detail": "BC customer lookup" }, { "kind": "transform", "system": "Patchworks", "label": "Map dimensions", "detail": "channel, location, salesperson" }, { "kind": "action", "system": "BC", "label": "Create sales order", "detail": "via OData / web service" }, { "kind": "writeback", "system": "Shopify", "label": "Tag order", "detail": "store BC document number" } ] }, "timeline": { "weeks": "6 to 9 weeks for a standard delivery", "phases": [ { "label": "Week 1", "detail": "Discovery: BC tenant setup, posting groups, dimensions, VAT scheme, location codes." }, { "label": "Weeks 2 to 4", "detail": "Build: order, customer, inventory, pricing and credit-note flows in Patchworks." }, { "label": "Weeks 5 to 6", "detail": "Integration testing against a BC sandbox using staged Shopify orders." }, { "label": "Weeks 7 to 8", "detail": "UAT with finance and operations; sign-off on dimension and posting-group mappings." }, { "label": "Week 9", "detail": "Cutover and hyper-care; transition into support retainer with monitoring and SLA." } ] }, "capabilities": [ { "capability": "order-sync", "label": "Order sync", "source": "shopify", "target": "microsoft-dynamics-business-central" }, { "capability": "inventory-sync", "label": "Inventory sync", "source": "microsoft-dynamics-business-central", "target": "shopify" }, { "capability": "product-sync", "label": "Product sync", "source": "microsoft-dynamics-business-central", "target": "shopify" }, { "capability": "pricing-sync", "label": "Pricing sync", "source": "microsoft-dynamics-business-central", "target": "shopify" }, { "capability": "customer-sync", "label": "Customer sync", "source": "shopify", "target": "microsoft-dynamics-business-central" }, { "capability": "returns-sync", "label": "Returns sync", "source": "shopify", "target": "microsoft-dynamics-business-central" }, { "capability": "refund-sync", "label": "Refund sync", "source": "shopify", "target": "microsoft-dynamics-business-central" }, { "capability": "tax-sync", "label": "Tax sync", "source": "microsoft-dynamics-business-central", "target": "shopify" } ], "faqs": [ { "q": "Does the integration work with Business Central SaaS or on-premise?", "a": "Both. The Patchworks connector talks to Business Central SaaS via OData and web services; on-premise deployments are reachable via the same APIs through a published web service tier. The flow logic is the same." }, { "q": "How are BC dimensions handled?", "a": "Dimensions are first-class. Channel, location, salesperson, project and any custom dimension you use get mapped explicitly during scoping. The integration enforces them at the boundary rather than relying on BC posting defaults." }, { "q": "What about multi-company Business Central?", "a": "Supported. Where you run multiple BC companies for separate legal entities or currencies, each maps to its own integration target. Orders route to the right company based on the storefront, market or channel attribute." }, { "q": "Can BC inventory drive Shopify availability across locations?", "a": "Yes. BC location-level inventory publishes to Shopify with channel-aware availability rules. Safety stock buffers and in-transit handling are configurable per item or item category." }, { "q": "Do you support Shopify-to-Business-Central under SLA after go-live?", "a": "Yes. The same team that builds the integration runs it under retainer. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month." } ] }, { "slug": "bigcommerce-to-netsuite", "a": "bigcommerce", "b": "netsuite", "url": "https://www.ecirql.com/integrations/bigcommerce-to-netsuite/", "lead": "BigCommerce is a strong SaaS storefront with a clean API surface and real B2B credentials. NetSuite is where the rest of the business lives: stock, finance, customers, fulfilment. The integration moves orders and customers into NetSuite as the system of record, lifts inventory and pricing back to BigCommerce, and reconciles the rest as one coherent estate. We design, build and support the integration as a certified Patchworks Partner Agency, with monitoring and SLA in place from cutover.", "patchworks_angle": "BigCommerce's APIs are well-shaped for integration, but the work still lives in respecting NetSuite's record-type model on the other side. We build the BigCommerce-to-NetSuite flows in Patchworks: order ingest with channel and subsidiary routing, customer and item creation, fulfilment writeback for the operations team, and explicit handling of BigCommerce price lists where B2B customer-specific pricing is in play. Canonical Patchworks patterns get the obvious shape shipped; bespoke work covers the rest.", "flow": { "title": "Order sync: BigCommerce to NetSuite", "description": "How a BigCommerce order lands as a NetSuite Sales Order with channel attribution, subsidiary routing and customer linkage in place from the first run.", "steps": [ { "kind": "trigger", "system": "BigCommerce", "label": "Order created", "detail": "orders webhook" }, { "kind": "extract", "system": "Patchworks", "label": "Fetch detail", "detail": "items, addresses, custom fields" }, { "kind": "transform", "system": "Patchworks", "label": "Map line items", "detail": "discounts, taxes, currencies" }, { "kind": "decision", "system": "Patchworks", "label": "Customer exists?", "detail": "NetSuite lookup by email / ID" }, { "kind": "transform", "system": "Patchworks", "label": "Enrich", "detail": "item refs, subsidiary, tax codes" }, { "kind": "action", "system": "NetSuite", "label": "Create Sales Order", "detail": "via SuiteTalk / RESTlet" }, { "kind": "writeback", "system": "BigCommerce", "label": "Tag order", "detail": "store NetSuite document number" } ] }, "timeline": { "weeks": "6 to 9 weeks for a standard delivery", "phases": [ { "label": "Week 1", "detail": "Discovery: NetSuite record types, BigCommerce API scope, B2B pricing model, channel mapping." }, { "label": "Weeks 2 to 4", "detail": "Build: order, customer, inventory, pricing and fulfilment flows in Patchworks." }, { "label": "Weeks 5 to 6", "detail": "Integration testing against the NetSuite sandbox and a staged BigCommerce store." }, { "label": "Weeks 7 to 8", "detail": "UAT with operations and finance; sign-off on B2B pricing and channel edge cases." }, { "label": "Week 9", "detail": "Cutover and hyper-care; transition into support retainer with monitoring and SLA." } ] }, "capabilities": [ { "capability": "order-sync", "label": "Order sync", "source": "bigcommerce", "target": "netsuite" }, { "capability": "inventory-sync", "label": "Inventory sync", "source": "netsuite", "target": "bigcommerce" }, { "capability": "product-sync", "label": "Product sync", "source": "netsuite", "target": "bigcommerce" }, { "capability": "pricing-sync", "label": "Pricing sync", "source": "netsuite", "target": "bigcommerce" }, { "capability": "customer-sync", "label": "Customer sync", "source": "bigcommerce", "target": "netsuite" }, { "capability": "refund-sync", "label": "Refund sync", "source": "netsuite", "target": "bigcommerce" }, { "capability": "tax-sync", "label": "Tax sync", "source": "netsuite", "target": "bigcommerce" } ], "faqs": [ { "q": "How does the integration handle BigCommerce B2B customer pricing?", "a": "Customer-specific price lists in BigCommerce can be sourced from NetSuite (typical for B2B-led operations) or maintained natively in BigCommerce. We agree the source of truth at scoping and build the integration around that, not the other way around." }, { "q": "Can the integration support BigCommerce multi-storefront?", "a": "Yes. Each storefront maps to its own NetSuite channel and, where appropriate, its own subsidiary. Inventory and pricing publish per storefront so customers in different markets see what's right for them." }, { "q": "What about BigCommerce checkout customisations?", "a": "Custom checkout fields and order metadata land on the BigCommerce order payload and map into NetSuite custom transaction fields. We define the mapping at scoping so the finance and operations teams both know what's where." }, { "q": "Do you support BigCommerce B2B (formerly B2B Edition)?", "a": "Yes. Company hierarchies, account managers and buyer roles map onto NetSuite customer hierarchies and contacts. Quote-to-order workflows can be modelled where the engagement needs them." }, { "q": "Do you support BigCommerce-to-NetSuite under SLA after go-live?", "a": "Yes. The same team that builds the integration runs it under retainer. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month." } ] }, { "slug": "magento-to-netsuite", "a": "magento", "b": "netsuite", "url": "https://www.ecirql.com/integrations/magento-to-netsuite/", "lead": "Magento (Adobe Commerce) is a serious enterprise storefront with a lot of moving parts: stores, websites, customer groups, attribute sets. Connecting it to NetSuite without breaking the catalogue or the accounting takes care. We design, build and support the Magento-to-NetSuite integration as a Patchworks Partner Agency, moving orders and customers into NetSuite as the system of record and lifting inventory, pricing, tax and fulfilment back into Magento as one connected estate.", "patchworks_angle": "Magento's website / store / view hierarchy doesn't map one-to-one onto NetSuite's subsidiary / channel model, and integrations that skip that translation tend to ship correctly only for the first merchant they're built for. We build the Magento-to-NetSuite flows in Patchworks with explicit mapping between Magento store views and NetSuite channels, attribute sets and item records, and customer groups and price lists. The runbook covers the edge cases each merchant's catalogue surfaces.", "flow": { "title": "Order sync: Magento to NetSuite", "description": "How a Magento order lands as a NetSuite Sales Order with store-view attribution, customer-group pricing and subsidiary routing in place from the first run.", "steps": [ { "kind": "trigger", "system": "Magento", "label": "Order placed", "detail": "sales_order webhook" }, { "kind": "extract", "system": "Patchworks", "label": "Fetch detail", "detail": "items, addresses, attributes" }, { "kind": "transform", "system": "Patchworks", "label": "Map store view", "detail": "channel, currency, subsidiary" }, { "kind": "decision", "system": "Patchworks", "label": "Customer exists?", "detail": "NetSuite lookup by email / group" }, { "kind": "transform", "system": "Patchworks", "label": "Enrich line items", "detail": "configurable / bundle expansion" }, { "kind": "action", "system": "NetSuite", "label": "Create Sales Order", "detail": "via SuiteTalk / RESTlet" }, { "kind": "writeback", "system": "Magento", "label": "Update order", "detail": "NetSuite reference, status" } ] }, "timeline": { "weeks": "8 to 12 weeks for a standard delivery", "phases": [ { "label": "Weeks 1 to 2", "detail": "Discovery: Magento store hierarchy, attribute sets, customer groups, NetSuite record-type mapping." }, { "label": "Weeks 3 to 6", "detail": "Build: order, customer, inventory, pricing, tax and fulfilment flows in Patchworks." }, { "label": "Weeks 7 to 8", "detail": "Integration testing against NetSuite sandbox and a staged Magento store." }, { "label": "Weeks 9 to 10", "detail": "UAT with operations and finance; sign-off on configurable products and customer-group edge cases." }, { "label": "Weeks 11 to 12", "detail": "Cutover and hyper-care; transition into support retainer with monitoring and SLA." } ] }, "capabilities": [ { "capability": "order-sync", "label": "Order sync", "source": "magento", "target": "netsuite" }, { "capability": "inventory-sync", "label": "Inventory sync", "source": "netsuite", "target": "magento" }, { "capability": "product-sync", "label": "Product sync", "source": "netsuite", "target": "magento" }, { "capability": "pricing-sync", "label": "Pricing sync", "source": "netsuite", "target": "magento" }, { "capability": "customer-sync", "label": "Customer sync", "source": "magento", "target": "netsuite" }, { "capability": "refund-sync", "label": "Refund sync", "source": "netsuite", "target": "magento" }, { "capability": "tax-sync", "label": "Tax sync", "source": "netsuite", "target": "magento" } ], "faqs": [ { "q": "Does the integration support Magento configurable and bundle products?", "a": "Yes. Configurable products are expanded into their underlying simple SKUs on the way into NetSuite so item ledger and inventory stay accurate. Bundle pricing is preserved at the order level for revenue recognition." }, { "q": "How are Magento store views mapped to NetSuite?", "a": "Each store view maps explicitly to a NetSuite channel (and subsidiary, where OneWorld is in play). We agree the mapping during scoping rather than relying on defaults, so multi-market operations land in the right place from day one." }, { "q": "Can customer-group pricing be driven from NetSuite?", "a": "Yes. NetSuite can be the source of truth for customer-group pricing, with the integration publishing into Magento price-list structures. The inverse pattern (Magento-native pricing) is also supported where it fits the operation." }, { "q": "What about Magento B2B features?", "a": "Company accounts, requisition lists, quotes and shared catalogues are supported. Where you use Adobe Commerce B2B features they map onto NetSuite customer hierarchies and contact records via the same flows that handle B2C orders." }, { "q": "Do you support Magento-to-NetSuite under SLA after go-live?", "a": "Yes. The same team that builds the integration runs it under retainer. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month." } ] }, { "slug": "magento-to-sage-200", "a": "magento", "b": "sage-200", "url": "https://www.ecirql.com/integrations/magento-to-sage-200/", "lead": "Magento (Adobe Commerce) and Sage 200 is one of the most common UK ecommerce-to-ERP patterns: serious storefront in front, British accounting and stock control behind. The integration carries orders, customers and credit decisions out of Magento into Sage 200 as proper sales documents, and lifts stock and pricing back the other way so the storefront reflects warehouse reality. We design, build and support the integration as a certified Patchworks Partner Agency.", "patchworks_angle": "Sage 200's data model rewards integrations that respect its accounting conventions, and Magento's catalogue model needs explicit translation onto Sage's stock item and nominal structure. We build the Magento-to-Sage 200 flows in Patchworks with VAT groups, nominal codes and customer ledger entries handled at the boundary, plus explicit handling for Magento's configurable products and store views. Sage's batch posting cadence drives the rhythm where finance needs it to.", "flow": { "title": "Order sync: Magento to Sage 200", "description": "How a Magento order lands as a Sage 200 sales document with VAT codes, nominal postings and customer ledger entries in place from the first run.", "steps": [ { "kind": "trigger", "system": "Magento", "label": "Order placed", "detail": "sales_order webhook" }, { "kind": "extract", "system": "Patchworks", "label": "Fetch detail", "detail": "items, addresses, attributes" }, { "kind": "transform", "system": "Patchworks", "label": "Resolve VAT codes", "detail": "rate, group, reverse-charge" }, { "kind": "decision", "system": "Patchworks", "label": "Customer exists?", "detail": "Sage account lookup" }, { "kind": "transform", "system": "Patchworks", "label": "Map to sales order", "detail": "nominal codes, analysis fields" }, { "kind": "action", "system": "Sage 200", "label": "Post sales order", "detail": "via Sage API" }, { "kind": "writeback", "system": "Magento", "label": "Update order", "detail": "Sage reference, status" } ] }, "timeline": { "weeks": "7 to 10 weeks for a standard delivery", "phases": [ { "label": "Weeks 1 to 2", "detail": "Discovery: Magento catalogue, Sage 200 chart of accounts, VAT scheme, nominal posting rules." }, { "label": "Weeks 3 to 5", "detail": "Build: order, customer, stock and pricing flows in Patchworks." }, { "label": "Weeks 6 to 7", "detail": "Integration testing against the live Sage instance using a staged Magento store." }, { "label": "Weeks 8 to 9", "detail": "UAT with finance and operations; sign-off on VAT and nominal mappings." }, { "label": "Week 10", "detail": "Cutover and hyper-care; transition into support retainer with monitoring and SLA." } ] }, "capabilities": [ { "capability": "order-sync", "label": "Order sync", "source": "magento", "target": "sage-200" }, { "capability": "inventory-sync", "label": "Inventory sync", "source": "sage-200", "target": "magento" }, { "capability": "product-sync", "label": "Product sync", "source": "sage-200", "target": "magento" }, { "capability": "pricing-sync", "label": "Pricing sync", "source": "sage-200", "target": "magento" }, { "capability": "customer-sync", "label": "Customer sync", "source": "magento", "target": "sage-200" }, { "capability": "tax-sync", "label": "Tax sync", "source": "sage-200", "target": "magento" } ], "faqs": [ { "q": "Does the integration work with Sage 200 on-premise or only Sage 200 Cloud?", "a": "Both. The Patchworks connector supports Sage 200 Standard (cloud-hosted) and Sage 200 Professional (on-premise or partner-hosted). The flow logic is the same; the access path differs." }, { "q": "How are Magento configurable products posted to Sage?", "a": "Configurable products are expanded into their underlying SKUs at the integration boundary so Sage's stock and nominal ledger see real SKUs rather than parent placeholders. Order lines keep the parent reference for reporting." }, { "q": "Can Sage 200 stock drive Magento availability?", "a": "Yes. Sage is typically the source of truth for stock, with location-aware availability rules publishing to Magento on a fast cadence plus event-driven updates on warehouse movement. Safety stock buffers are configurable per SKU group." }, { "q": "What about Magento multi-store and multi-website?", "a": "Supported. Each store or website maps explicitly to a Sage 200 source, with the right nominal posting rules per channel. Multi-currency orders post in the order currency with FX policy applied at the configured rate." }, { "q": "Do you support Magento-to-Sage 200 under SLA after go-live?", "a": "Yes. The same team that builds the integration runs it under retainer. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month." } ] }, { "slug": "netsuite-to-mirakl", "a": "netsuite", "b": "mirakl", "url": "https://www.ecirql.com/integrations/netsuite-to-mirakl/", "lead": "Mirakl powers a large share of the marketplaces UK and EU retailers sell into, and a growing share of the marketplaces they operate themselves. Connecting NetSuite to Mirakl carries the listings, the inventory, the orders and the settlements as one connected flow, so finance and operations see Mirakl revenue land in the right places without the reconciliation tax. We design, build and support the integration as a certified Patchworks Partner Agency.", "patchworks_angle": "Mirakl's operator API is consistent, but every marketplace running on it has its own category taxonomy, attribute requirements and service-level rules. We build the NetSuite-to-Mirakl flows in Patchworks with marketplace-specific category mapping and attribute enforcement at the boundary, plus settlement reconciliation that matches each line in the Mirakl report against a NetSuite transaction. The result is a multi-marketplace operation that doesn't drown finance at period close.", "flow": { "title": "Order ingest: Mirakl to NetSuite", "description": "How a Mirakl marketplace order lands as a NetSuite Sales Order with channel attribution, settlement linkage and SLA awareness from the first run.", "steps": [ { "kind": "trigger", "system": "Mirakl", "label": "Order notification", "detail": "Mirakl operator API poll" }, { "kind": "extract", "system": "Patchworks", "label": "Fetch detail", "detail": "items, address, commission" }, { "kind": "transform", "system": "Patchworks", "label": "Resolve channel", "detail": "operator, currency, tax rule" }, { "kind": "transform", "system": "Patchworks", "label": "Map to NetSuite SO", "detail": "channel = Mirakl operator" }, { "kind": "action", "system": "NetSuite", "label": "Create Sales Order", "detail": "with attribution fields" }, { "kind": "writeback", "system": "Mirakl", "label": "Acknowledge", "detail": "dispatch SLA clock starts" }, { "kind": "action", "system": "Mirakl", "label": "Send tracking", "detail": "on fulfilment, with carrier data" } ] }, "timeline": { "weeks": "5 to 8 weeks for a standard delivery", "phases": [ { "label": "Week 1", "detail": "Discovery: marketplace scope, category mapping, attribute requirements, SLA tier per operator." }, { "label": "Weeks 2 to 4", "detail": "Build: listing, inventory, order, fulfilment and settlement flows in Patchworks." }, { "label": "Weeks 5 to 6", "detail": "Integration testing against the Mirakl sandbox per operator, including settlement reconciliation." }, { "label": "Week 7", "detail": "UAT with operations and finance; sign-off on SLA handling and commission reporting." }, { "label": "Week 8", "detail": "Cutover and hyper-care; transition into support retainer with monitoring and SLA." } ] }, "capabilities": [ { "capability": "order-sync", "label": "Order sync", "source": "mirakl", "target": "netsuite" }, { "capability": "inventory-sync", "label": "Inventory sync", "source": "netsuite", "target": "mirakl" }, { "capability": "product-sync", "label": "Product sync", "source": "netsuite", "target": "mirakl" }, { "capability": "pricing-sync", "label": "Pricing sync", "source": "netsuite", "target": "mirakl" }, { "capability": "settlement-recon", "label": "Settlement reconciliation", "source": "mirakl", "target": "netsuite" } ], "faqs": [ { "q": "Can the integration handle multiple Mirakl operators?", "a": "Yes. Each operator maps to its own NetSuite channel and, where required, its own subsidiary. Listings, inventory and orders are scoped per operator, with shared product master data where it makes sense." }, { "q": "How does settlement and commission reporting work?", "a": "Mirakl settlement reports import line by line. Commission, refunds, adjustments and fees each get their own GL mapping. Each line matches to the underlying NetSuite transaction or surfaces as an unmatched item for finance review." }, { "q": "What about Mirakl's strict dispatch SLAs?", "a": "Fulfilment writeback is engineered around the operator's SLA. Carrier, service level and tracking number arrive on the same dispatch event so the SLA clock stops cleanly. Late shipments are flagged via monitoring before the operator does." }, { "q": "How are category-specific attributes handled?", "a": "Each operator's category attributes are enforced at the integration boundary using a per-operator schema. Where the merchant's NetSuite item data is missing a required attribute, the listing flow blocks rather than publishing a non-compliant SKU." }, { "q": "Do you support NetSuite-to-Mirakl under SLA after go-live?", "a": "Yes. The same team that builds the integration runs it under retainer. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month." } ] }, { "slug": "shopify-to-returngo", "a": "shopify", "b": "returngo", "url": "https://www.ecirql.com/integrations/shopify-to-returngo/", "lead": "ReturnGO runs the customer-facing returns experience for a lot of Shopify merchants, but the experience only works if the rest of the stack hears about returns as first-class events. We integrate Shopify and ReturnGO so order context flows the right way, returns and refunds flow back into Shopify and downstream systems as they happen, and the customer-facing return state reflects what the warehouse and finance teams know. Built and supported as a certified Patchworks Partner Agency.", "patchworks_angle": "ReturnGO has good webhooks, but the work is in making sure each return event lands in the right place across the rest of the estate. We build the Shopify-to-ReturnGO flows in Patchworks with paired return-and-refund handling, restocking signals to the warehouse, and explicit treatment of exchanges so they don't collapse into refund-plus-new-order. Where the merchant also runs an ERP or WMS, the same Patchworks integration carries the events to those systems.", "flow": { "title": "Returns and refunds: ReturnGO into Shopify", "description": "How a customer return raised in ReturnGO advances the order record in Shopify, releases stock back to the right location and issues the refund against the original payment method.", "steps": [ { "kind": "trigger", "system": "ReturnGO", "label": "Return raised", "detail": "RMA webhook" }, { "kind": "extract", "system": "Patchworks", "label": "Fetch detail", "detail": "lines, reason, decision" }, { "kind": "decision", "system": "Patchworks", "label": "Refund or exchange?", "detail": "routes to refund or replacement flow" }, { "kind": "action", "system": "Shopify", "label": "Open return", "detail": "Shopify Returns API" }, { "kind": "transform", "system": "Patchworks", "label": "Resolve refund", "detail": "original tender, partial / full" }, { "kind": "action", "system": "Shopify", "label": "Issue refund", "detail": "against original payment method" }, { "kind": "writeback", "system": "ReturnGO", "label": "Confirm", "detail": "close RMA, customer notified" } ] }, "timeline": { "weeks": "3 to 5 weeks for a standard delivery", "phases": [ { "label": "Week 1", "detail": "Discovery: returns policy, RMA workflow, refund tender rules, exchange handling, warehouse signals." }, { "label": "Weeks 2 to 3", "detail": "Build: order, customer, returns and refund flows in Patchworks." }, { "label": "Week 4", "detail": "Integration testing using staged Shopify orders and ReturnGO sandbox; UAT on edge cases." }, { "label": "Week 5", "detail": "Cutover and hyper-care; transition into support retainer with monitoring and SLA." } ] }, "capabilities": [ { "capability": "order-sync", "label": "Order sync", "source": "shopify", "target": "returngo" }, { "capability": "customer-sync", "label": "Customer sync", "source": "shopify", "target": "returngo" }, { "capability": "returns-sync", "label": "Returns sync", "source": "returngo", "target": "shopify" }, { "capability": "refund-sync", "label": "Refund sync", "source": "returngo", "target": "shopify" } ], "faqs": [ { "q": "How are exchanges handled?", "a": "As a paired return-and-outbound pattern rather than a refund-plus-new-order. The original return advances cleanly, the replacement order carries the exchange reference, and accounting sees both halves of the transaction." }, { "q": "Can ReturnGO trigger restocking signals to the warehouse?", "a": "Yes. Where you run a WMS (Peoplevox, Veeqo, ShipBob and others), the same Patchworks integration routes ReturnGO inspection outcomes to the warehouse so restockable items move back to sellable stock without manual intervention." }, { "q": "Does the integration support partial refunds?", "a": "Yes. Line-level partial refunds, restocking fees and gift-card-tendered refunds all map onto Shopify refund records in the right shape. The original payment method drives the refund destination by default; merchant rules can override." }, { "q": "What about refunds against marketplace orders sold via Shopify?", "a": "Where the marketplace owns refund execution (Amazon, eBay), the integration coordinates the request rather than executing it directly. The status in Shopify and ReturnGO advances when the marketplace confirms." }, { "q": "Do you support Shopify-to-ReturnGO under SLA after go-live?", "a": "Yes. The same team that builds the integration runs it under retainer. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month." } ] }, { "slug": "akeneo-to-shopify", "a": "akeneo", "b": "shopify", "url": "https://www.ecirql.com/integrations/akeneo-to-shopify/", "lead": "Akeneo is the most-deployed open-source PIM in UK retail, and Shopify is increasingly what sits at the channel end of the product data pipeline. The integration carries enriched, locale-aware product data out of Akeneo and into Shopify as channel-ready listings, with variants, media, metafields and category mappings handled explicitly. We design, build and support Akeneo-to-Shopify publication as a certified Patchworks Partner Agency.", "patchworks_angle": "The work on a PIM-to-storefront integration is in respecting Akeneo's channel and locale model and translating it onto Shopify's product, variant and metafield surface. We build the Akeneo-to-Shopify flows in Patchworks with channel-aware publication, locale-specific copy and pricing, attribute enrichment and a publication gate so the merchandising team controls when a product goes live. New launches and routine updates use the same flow.", "flow": { "title": "Product publication: Akeneo to Shopify", "description": "How an Akeneo product reaches Shopify as a channel-ready listing with variants, media, locale copy and metafield enrichment in place from the first run.", "steps": [ { "kind": "trigger", "system": "Akeneo", "label": "Product published", "detail": "channel-specific publication event" }, { "kind": "extract", "system": "Patchworks", "label": "Fetch product", "detail": "with channel and locale scope" }, { "kind": "transform", "system": "Patchworks", "label": "Map attributes", "detail": "to Shopify metafields and variants" }, { "kind": "transform", "system": "Patchworks", "label": "Resolve media", "detail": "image order, alt text, locale variants" }, { "kind": "decision", "system": "Patchworks", "label": "Product exists?", "detail": "Shopify catalogue lookup" }, { "kind": "action", "system": "Shopify", "label": "Create / update", "detail": "via Admin API" }, { "kind": "writeback", "system": "Akeneo", "label": "Mark synced", "detail": "publication timestamp + status" } ] }, "timeline": { "weeks": "5 to 8 weeks for a standard delivery", "phases": [ { "label": "Week 1", "detail": "Discovery: Akeneo channel + locale setup, Shopify metafield architecture, media handling rules." }, { "label": "Weeks 2 to 4", "detail": "Build: product, variant, media and metafield publication flows in Patchworks." }, { "label": "Weeks 5 to 6", "detail": "Integration testing against the Shopify store with a representative product set." }, { "label": "Week 7", "detail": "UAT with merchandising team; sign-off on attribute mapping and locale handling." }, { "label": "Week 8", "detail": "Cutover and hyper-care; transition into support retainer with monitoring and SLA." } ] }, "capabilities": [ { "capability": "product-sync", "label": "Product sync", "source": "akeneo", "target": "shopify" }, { "capability": "product-syndication", "label": "Product syndication", "source": "akeneo", "target": "shopify" } ], "faqs": [ { "q": "How are Shopify metafields modelled in Akeneo?", "a": "Each Shopify metafield maps to an Akeneo attribute with the right type and scope (per channel, per locale). The mapping is configured during scoping so merchandising sees Akeneo as the source of truth without needing to learn Shopify's metafield UI." }, { "q": "Does the integration support Shopify Markets and locale-specific copy?", "a": "Yes. Akeneo locales publish to the corresponding Shopify market or locale, including translated copy, market-specific pricing where Akeneo owns pricing, and locale-specific media variants." }, { "q": "How are product variants handled?", "a": "Akeneo's variant axes (size, colour and any custom dimension) map onto Shopify product options. New variants flow through automatically; deprecated variants are flagged rather than hard-deleted so historical orders stay intact." }, { "q": "Can merchandising control when a product goes live?", "a": "Yes. The integration uses Akeneo's publication state as the gate. A product only reaches Shopify when merchandising explicitly publishes it on the relevant channel; status changes propagate immediately." }, { "q": "Do you support Akeneo-to-Shopify under SLA after go-live?", "a": "Yes. The same team that builds the integration runs it under retainer. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month." } ] }, { "slug": "akeneo-to-mirakl", "a": "akeneo", "b": "mirakl", "url": "https://www.ecirql.com/integrations/akeneo-to-mirakl/", "lead": "Marketplace listings are unforgiving: a missing required attribute, an oversized image or the wrong category mapping and the listing either fails or sells incorrectly. Akeneo holds the enriched product data; Mirakl wants it shaped its own way per operator. The integration syndicates Akeneo product data to one or many Mirakl marketplaces with category mapping, attribute enforcement and publication control in place from the first feed. Built and supported as a certified Patchworks Partner Agency.", "patchworks_angle": "Each Mirakl operator runs its own category taxonomy and required-attribute schema, and product-syndication integrations that don't respect that need rework every time the merchant opens a new marketplace. We build the Akeneo-to-Mirakl flows in Patchworks with a per-operator category map, attribute enforcement at the boundary, and a publication state that merchandising controls. New marketplaces are configuration rather than rebuild.", "flow": { "title": "Product syndication: Akeneo to Mirakl", "description": "How an Akeneo product becomes a compliant Mirakl listing on one or many operator marketplaces with the right category, attributes and media in place from the first publication.", "steps": [ { "kind": "trigger", "system": "Akeneo", "label": "Product published", "detail": "channel-specific publication event" }, { "kind": "extract", "system": "Patchworks", "label": "Fetch product", "detail": "with channel and locale scope" }, { "kind": "transform", "system": "Patchworks", "label": "Map to operator", "detail": "category, required attributes, units" }, { "kind": "decision", "system": "Patchworks", "label": "Compliant?", "detail": "blocks non-compliant SKUs" }, { "kind": "transform", "system": "Patchworks", "label": "Build offer feed", "detail": "price, stock policy, lead time" }, { "kind": "action", "system": "Mirakl", "label": "Publish listing", "detail": "via operator API" }, { "kind": "writeback", "system": "Akeneo", "label": "Mark synced", "detail": "per-operator publication timestamp" } ] }, "timeline": { "weeks": "5 to 8 weeks for a standard delivery (first operator)", "phases": [ { "label": "Week 1", "detail": "Discovery: target operators, category mapping, required-attribute schema per operator." }, { "label": "Weeks 2 to 4", "detail": "Build: product, attribute, media, offer and listing-state flows in Patchworks." }, { "label": "Weeks 5 to 6", "detail": "Integration testing against the operator sandbox with a representative product set." }, { "label": "Week 7", "detail": "UAT with merchandising; sign-off on category mapping and compliance gating." }, { "label": "Week 8", "detail": "Cutover and hyper-care; subsequent operators are configuration, not rebuild." } ] }, "capabilities": [ { "capability": "product-sync", "label": "Product sync", "source": "akeneo", "target": "mirakl" }, { "capability": "product-syndication", "label": "Product syndication", "source": "akeneo", "target": "mirakl" } ], "faqs": [ { "q": "How does the integration handle multiple Mirakl operators?", "a": "Each operator has its own category map and attribute schema. Adding a new operator after the first one is configuration rather than a fresh build, because the underlying flows are designed around the operator boundary from the start." }, { "q": "What happens when a SKU is missing a required attribute?", "a": "The flow blocks at the compliance gate rather than publishing a non-compliant listing. Merchandising sees the missing attribute on the Akeneo side, fills it, and the listing publishes on the next cycle. Nothing reaches the marketplace half-cooked." }, { "q": "How are price and stock policies modelled?", "a": "Per operator. Each marketplace can have its own pricing rule, stock buffer and lead-time policy without affecting the others. Where pricing is sourced from an ERP, the ERP feeds the offer-pricing layer at the integration boundary." }, { "q": "Can the integration handle media at the right dimensions per marketplace?", "a": "Yes. Each operator's image requirements (dimensions, aspect ratio, count) are enforced at the integration boundary. Where Akeneo holds source media, the integration applies the per-operator transformation rather than asking merchandising to upload variants manually." }, { "q": "Do you support Akeneo-to-Mirakl under SLA after go-live?", "a": "Yes. The same team that builds the integration runs it under retainer. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month." } ] }, { "slug": "shopify-to-klaviyo", "a": "shopify", "b": "klaviyo", "url": "https://www.ecirql.com/integrations/shopify-to-klaviyo/", "lead": "Klaviyo is the customer-data and email-marketing platform most Shopify merchants choose, and it earns the choice by being deep on ecommerce data shapes. The native Shopify connector handles the happy path; the work we get called in for is the cases it doesn't, or the cases where Klaviyo needs to coexist with other systems in the estate. We design, build and support Shopify-to-Klaviyo integrations as a certified Patchworks Partner Agency, with full support for downstream system handoffs.", "patchworks_angle": "Klaviyo's native Shopify connector is good. Where it stops being enough is when customers and orders need to flow through Klaviyo and on into a CRM, a CDP or an ERP as part of the same event chain. We build Shopify-to-Klaviyo in Patchworks so that customer and order events route to Klaviyo with the segment-shaped data its flows need, and onward to whichever systems should also hear about them. One integration. One audit trail.", "flow": { "title": "Customer and order data: Shopify to Klaviyo", "description": "How a Shopify customer or order reaches Klaviyo as a segment-shaped profile event, with explicit handling for downstream systems that should hear about the same change.", "steps": [ { "kind": "trigger", "system": "Shopify", "label": "Customer / order event", "detail": "webhook (create, update, refund)" }, { "kind": "extract", "system": "Patchworks", "label": "Ingest payload", "detail": "queue, dedupe, normalise" }, { "kind": "transform", "system": "Patchworks", "label": "Resolve identity", "detail": "email + external ID merge" }, { "kind": "transform", "system": "Patchworks", "label": "Shape profile event", "detail": "Klaviyo properties + metrics" }, { "kind": "action", "system": "Klaviyo", "label": "Update profile", "detail": "via Klaviyo API" }, { "kind": "action", "system": "Klaviyo", "label": "Track metric", "detail": "for segmentation + flows" }, { "kind": "writeback", "system": "Shopify", "label": "Tag identity", "detail": "store Klaviyo profile ID" } ] }, "timeline": { "weeks": "3 to 5 weeks for a standard delivery", "phases": [ { "label": "Week 1", "detail": "Discovery: existing native connector scope, gap analysis, downstream system handoffs." }, { "label": "Weeks 2 to 3", "detail": "Build: customer, order, refund and product flows in Patchworks." }, { "label": "Week 4", "detail": "Integration testing against the Klaviyo sandbox using staged Shopify events." }, { "label": "Week 5", "detail": "Cutover and hyper-care; transition into support retainer with monitoring and SLA." } ] }, "capabilities": [ { "capability": "order-sync", "label": "Order sync", "source": "shopify", "target": "klaviyo" }, { "capability": "customer-sync", "label": "Customer sync", "source": "shopify", "target": "klaviyo" } ], "faqs": [ { "q": "Why not just use Klaviyo's native Shopify connector?", "a": "For many merchants it's enough. We get called in where the merchant needs the same customer and order events to flow through Klaviyo and on into other systems (CRM, ERP, CDP, marketing data warehouse) as part of one event chain, or where the native connector doesn't model a piece of data the merchant relies on." }, { "q": "Can identity be resolved across systems?", "a": "Yes. Where the merchant runs a CRM or CDP that owns identity, we use that as the source of truth and reconcile Klaviyo profiles to it. Email plus an external ID is the typical merge key; we can add more where the data model needs it." }, { "q": "How are refunds and returns reflected in Klaviyo?", "a": "Refund and return events post as Klaviyo metrics so flows can react (post-return surveys, win-back campaigns gated on return history). Profile properties update to reflect refunded LTV and return-rate signals." }, { "q": "Can the integration coexist with the native Klaviyo connector?", "a": "Yes. The typical pattern is to keep the native connector for the patterns it does well and use the Patchworks flows for the events that need to fan out to other systems. We document the boundary so nothing gets double-counted." }, { "q": "Do you support Shopify-to-Klaviyo under SLA after go-live?", "a": "Yes. The same team that builds the integration runs it under retainer. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month." } ] }, { "slug": "sftp-to-netsuite", "a": "sftp-connector", "b": "netsuite", "url": "https://www.ecirql.com/integrations/sftp-to-netsuite/", "lead": "Not every system in a retail estate has a modern API. Legacy ERPs, in-house tools and long-running vendor systems still talk in files: a daily orders.csv on an SFTP server, a stock.txt drop at midnight, a fixed-width customer extract on the hour. We pick those files up, parse them, validate them, and synchronise the contents into NetSuite as proper records, with the same monitoring and SLA we apply to API-first integrations. Built and supported as a certified Patchworks Partner Agency.", "patchworks_angle": "Patchworks handles file-based sources as a first-class flow shape rather than a fallback. We build the SFTP-to-NetSuite integration in Patchworks with explicit file pickup, parsing, schema validation and dead-letter handling for malformed rows. The merchant sees the same monitoring, retry behaviour and on-call cover for a CSV drop as for a webhook from Shopify. Where the legacy system can also accept files back, the same Patchworks integration can publish outbound extracts on schedule.", "flow": { "title": "File ingest: SFTP to NetSuite", "description": "How a .csv or .txt file landing on an SFTP server becomes a set of NetSuite records with parsing, validation and error handling in place from the first drop.", "steps": [ { "kind": "trigger", "system": "SFTP", "label": "File arrives", "detail": "scheduled poll or watcher" }, { "kind": "extract", "system": "Patchworks", "label": "Fetch + checksum", "detail": "atomic move to working folder" }, { "kind": "transform", "system": "Patchworks", "label": "Parse rows", "detail": "CSV / TXT / fixed-width schema" }, { "kind": "decision", "system": "Patchworks", "label": "Schema valid?", "detail": "row-level reject to dead letter" }, { "kind": "transform", "system": "Patchworks", "label": "Map to NetSuite", "detail": "record type, subsidiary, dimensions" }, { "kind": "action", "system": "NetSuite", "label": "Create / update", "detail": "via SuiteTalk / RESTlet, batched" }, { "kind": "writeback", "system": "SFTP", "label": "Archive + receipt", "detail": "move to /processed, write log" } ] }, "timeline": { "weeks": "3 to 6 weeks for a standard delivery", "phases": [ { "label": "Week 1", "detail": "Discovery: file formats, drop cadence, NetSuite record-type mapping, error-handling policy." }, { "label": "Weeks 2 to 3", "detail": "Build: pickup, parse, validate, map, post and archive flows in Patchworks." }, { "label": "Weeks 4 to 5", "detail": "Integration testing using real legacy file samples against the NetSuite sandbox." }, { "label": "Week 6", "detail": "Cutover and hyper-care; transition into support retainer with monitoring and SLA." } ] }, "capabilities": [ { "capability": "order-sync", "label": "Order sync", "source": "sftp-connector", "target": "netsuite" }, { "capability": "inventory-sync", "label": "Inventory sync", "source": "sftp-connector", "target": "netsuite" }, { "capability": "product-sync", "label": "Product sync", "source": "sftp-connector", "target": "netsuite" }, { "capability": "pricing-sync", "label": "Pricing sync", "source": "sftp-connector", "target": "netsuite" }, { "capability": "customer-sync", "label": "Customer sync", "source": "sftp-connector", "target": "netsuite" } ], "faqs": [ { "q": "What file formats do you support?", "a": "CSV, TSV, fixed-width text, pipe-delimited and most variants in between. Where the source produces an unusual flavour (mixed delimiters, embedded headers, multi-record per line), we build a custom parser at the integration boundary. XML and JSON dropped on SFTP are also handled." }, { "q": "How are malformed rows handled?", "a": "Bad rows route to a dead-letter folder with the original line and a parse-error reason logged. Valid rows in the same file still process. Finance or operations can review the dead-letter file, fix the source data, and re-drop. Nothing silently corrupts the NetSuite side." }, { "q": "What about character encoding, line endings and BOMs?", "a": "Handled explicitly. UTF-8 with or without BOM, Windows-1252, ISO-8859-1, mixed CRLF / LF line endings. We agree the encoding at scoping rather than guessing, and the parser fails loudly if a file arrives in an unexpected encoding rather than corrupting the data on the way in." }, { "q": "Can the integration push files back to the legacy system?", "a": "Yes. The same Patchworks integration can publish outbound extracts from NetSuite to SFTP on schedule: stock counts, posted invoices, settlement reports, anything the legacy system needs to consume. Filename, folder, and format conventions match whatever the legacy system expects." }, { "q": "Do you support SFTP-to-NetSuite under SLA after go-live?", "a": "Yes. The same team that builds the integration runs it under retainer. File-pickup monitoring, on-call cover, monthly health checks and tiered response SLAs from £750/month. Missed file drops alert before the next batch posts late." } ] }, { "slug": "shopify-to-freeagent", "a": "shopify", "b": "freeagent", "url": "https://www.ecirql.com/integrations/shopify-to-freeagent/", "lead": "FreeAgent is the accounting platform a lot of UK Shopify merchants use to keep on top of VAT, MTD submissions and the year-end. The integration moves orders, customers and refunds out of Shopify and into FreeAgent as proper sales invoices and credit notes, with VAT treatment, tender and currency correct from the first run. We design, build and support Shopify-to-FreeAgent integrations as a certified Patchworks Partner Agency, so the accounting side stays in step with the storefront without manual reconciliation.", "patchworks_angle": "FreeAgent's API is clean but opinionated about how invoices, customers and tax rates should look. The work is in shaping Shopify order events into the right FreeAgent constructs while respecting the MTD reporting rules HMRC enforces. We build the Shopify-to-FreeAgent flows in Patchworks with explicit VAT rate mapping, tender-aware refund handling and a customer-resolution step so the FreeAgent ledger doesn't fragment into duplicates over time.", "flow": { "title": "Sales posting: Shopify to FreeAgent", "description": "How a Shopify order lands in FreeAgent as a sales invoice with VAT, customer, and tender treatment in place from the first run.", "steps": [ { "kind": "trigger", "system": "Shopify", "label": "Order paid", "detail": "order/paid webhook" }, { "kind": "extract", "system": "Patchworks", "label": "Ingest payload", "detail": "queue, dedupe, normalise" }, { "kind": "transform", "system": "Patchworks", "label": "Resolve VAT rate", "detail": "standard, reduced, zero, exempt" }, { "kind": "decision", "system": "Patchworks", "label": "Customer exists?", "detail": "FreeAgent contact lookup" }, { "kind": "transform", "system": "Patchworks", "label": "Map to invoice", "detail": "line items, discounts, currency" }, { "kind": "action", "system": "FreeAgent", "label": "Create invoice", "detail": "marked paid against tender" }, { "kind": "writeback", "system": "Shopify", "label": "Tag order", "detail": "store FreeAgent invoice reference" } ] }, "timeline": { "weeks": "3 to 5 weeks for a standard delivery", "phases": [ { "label": "Week 1", "detail": "Discovery: VAT scheme, MTD requirements, tender mapping, customer-resolution policy." }, { "label": "Weeks 2 to 3", "detail": "Build: order, customer and refund flows in Patchworks." }, { "label": "Week 4", "detail": "Integration testing using staged Shopify orders against a FreeAgent sandbox; UAT with finance." }, { "label": "Week 5", "detail": "Cutover and hyper-care; transition into support retainer with monitoring and SLA." } ] }, "capabilities": [ { "capability": "order-sync", "label": "Order sync", "source": "shopify", "target": "freeagent" }, { "capability": "customer-sync", "label": "Customer sync", "source": "shopify", "target": "freeagent" }, { "capability": "refund-sync", "label": "Refund sync", "source": "shopify", "target": "freeagent" } ], "faqs": [ { "q": "How is VAT handled across rates?", "a": "Each Shopify tax line maps to a FreeAgent VAT rate explicitly: standard, reduced, zero-rated, exempt, outside the scope. We agree the mapping during scoping, so MTD submissions reflect the same VAT treatment finance expects to see on the FreeAgent VAT return." }, { "q": "What about refunds and partial refunds?", "a": "Refunds post as credit notes in FreeAgent against the original invoice. Partial refunds map to line-level credit notes; restocking fees and gift-card refunds get the right tax treatment rather than collapsing into a single adjustment." }, { "q": "Does the integration support Shopify Markets and multi-currency?", "a": "Yes. Orders post to FreeAgent in the order currency with FX policy applied at the configured rate. We agree the rate source during scoping so finance isn't reconciling two interpretations of exchange rates." }, { "q": "How are Shopify customers reconciled to FreeAgent contacts?", "a": "Email plus an external identifier is the typical merge key. New customers create FreeAgent contacts on first order; existing customers reuse the same contact across all subsequent orders so the ledger stays clean." }, { "q": "Do you support Shopify-to-FreeAgent under SLA after go-live?", "a": "Yes. The same team that builds the integration runs it under retainer. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month." } ] }, { "slug": "netsuite-to-freeagent", "a": "netsuite", "b": "freeagent", "url": "https://www.ecirql.com/integrations/netsuite-to-freeagent/", "lead": "Some groups run NetSuite at the consolidated level but need a UK subsidiary on FreeAgent for MTD-compliant VAT submission and HMRC-friendly reporting. The integration carries sales invoices, credit notes, customer ledger entries and VAT-relevant transactions out of the NetSuite UK subsidiary and into FreeAgent on a controlled schedule, so MTD filings reflect group reality without manual export. We design, build and support this NetSuite-to-FreeAgent pattern as a certified Patchworks Partner Agency.", "patchworks_angle": "The complexity in NetSuite-to-FreeAgent isn't volume, it's correctness. VAT codes, posting periods and subsidiary scope have to line up between the two systems with no drift, because the FreeAgent side is what HMRC sees through MTD. We build the flows in Patchworks with explicit period-aware batching, VAT rate mapping and a reconciliation receipt back into NetSuite so finance can audit the trail at month-end without rebuilding it from spreadsheets.", "flow": { "title": "VAT-relevant posting: NetSuite UK to FreeAgent", "description": "How a NetSuite UK subsidiary's sales invoices, credit notes and VAT transactions reach FreeAgent on the cadence finance and HMRC expect.", "steps": [ { "kind": "trigger", "system": "Patchworks", "label": "Period schedule", "detail": "daily, weekly, or close-cadence" }, { "kind": "extract", "system": "NetSuite", "label": "Fetch transactions", "detail": "UK subsidiary, period filter" }, { "kind": "transform", "system": "Patchworks", "label": "Resolve VAT codes", "detail": "NetSuite tax code to FreeAgent rate" }, { "kind": "decision", "system": "Patchworks", "label": "Contact exists?", "detail": "FreeAgent contact lookup or create" }, { "kind": "transform", "system": "Patchworks", "label": "Map to invoices", "detail": "invoices, credit notes, journal lines" }, { "kind": "action", "system": "FreeAgent", "label": "Post documents", "detail": "batched per period" }, { "kind": "writeback", "system": "NetSuite", "label": "Mark exported", "detail": "FreeAgent reference + period stamp" } ] }, "timeline": { "weeks": "5 to 8 weeks for a standard delivery", "phases": [ { "label": "Week 1", "detail": "Discovery: subsidiary scope, MTD requirements, period close cadence, VAT code mapping." }, { "label": "Weeks 2 to 4", "detail": "Build: customer, invoice, credit-note and tax flows in Patchworks." }, { "label": "Weeks 5 to 6", "detail": "Integration testing against a NetSuite sandbox and a FreeAgent test account, including a full VAT period cycle." }, { "label": "Week 7", "detail": "UAT with finance; reconciliation receipt validated against a manually-prepared VAT return." }, { "label": "Week 8", "detail": "Cutover and hyper-care; transition into support retainer with monitoring and SLA." } ] }, "capabilities": [ { "capability": "credit-note-sync", "label": "Credit note sync", "source": "netsuite", "target": "freeagent" }, { "capability": "tax-sync", "label": "Tax sync", "source": "netsuite", "target": "freeagent" } ], "faqs": [ { "q": "Why would a NetSuite user also run FreeAgent?", "a": "Most don't. The pattern shows up when a group runs NetSuite at the consolidated level but a UK trading entity needs MTD-compliant submission through FreeAgent. It also shows up where a small UK subsidiary was on FreeAgent before the group standardised on NetSuite and finance prefers to keep MTD filing where it was." }, { "q": "How are VAT codes reconciled between the two systems?", "a": "Explicitly. Each NetSuite tax code maps to a FreeAgent VAT rate with documented intent. Where the source data uses a code that isn't in the mapping, the flow blocks rather than posting under an arbitrary fallback rate. Nothing silently misfiles VAT." }, { "q": "Does this support OneWorld with multiple UK entities?", "a": "Yes. Each UK trading entity that needs its own FreeAgent account is scoped per subsidiary. The integration runs the right slice of transactions per FreeAgent target so groups operating multiple UK entities don't have to merge them at the integration boundary." }, { "q": "What if NetSuite is reopened for a prior period?", "a": "Period-aware batching reads NetSuite's lock state and surfaces re-opened periods as a controlled exception. The integration doesn't blindly re-post; finance gets a notification and reviews before any backdated documents reach FreeAgent." }, { "q": "Do you support NetSuite-to-FreeAgent under SLA after go-live?", "a": "Yes. The same team that builds the integration runs it under retainer. Period-close monitoring, on-call cover, monthly health checks and tiered response SLAs from £750/month." } ] }, { "slug": "woocommerce-to-xero", "a": "woocommerce", "b": "xero", "url": "https://www.ecirql.com/integrations/woocommerce-to-xero/", "lead": "WooCommerce powers a long tail of UK and ANZ ecommerce operations, and Xero is the accounting platform most of them run. The integration carries orders, customers and refunds out of WooCommerce and into Xero as proper sales invoices and credit notes, with VAT or GST treatment, tender and currency correct from the first run. Built and supported as a certified Patchworks Partner Agency, so the books stay in step with the storefront without manual reconciliation.", "patchworks_angle": "Xero's invoice and contact model is opinionated, and a small Xero instance gets messy fast if the integration creates duplicate contacts or misclassifies tax. We build WooCommerce-to-Xero in Patchworks with a customer-resolution step that keeps the ledger clean, explicit tax rate mapping per jurisdiction, and tender-aware refund handling. Where the merchant uses Xero's tracking categories, those map onto WooCommerce order attributes rather than being applied at the end.", "flow": { "title": "Sales posting: WooCommerce to Xero", "description": "How a WooCommerce order lands in Xero as a sales invoice with tax, contact and tender treatment in place from the first run.", "steps": [ { "kind": "trigger", "system": "WooCommerce", "label": "Order completed", "detail": "order status webhook" }, { "kind": "extract", "system": "Patchworks", "label": "Ingest payload", "detail": "queue, dedupe, normalise" }, { "kind": "transform", "system": "Patchworks", "label": "Resolve tax rate", "detail": "VAT, GST, jurisdiction rules" }, { "kind": "decision", "system": "Patchworks", "label": "Contact exists?", "detail": "Xero contact lookup or create" }, { "kind": "transform", "system": "Patchworks", "label": "Map to invoice", "detail": "lines, discounts, tracking categories" }, { "kind": "action", "system": "Xero", "label": "Create invoice", "detail": "marked paid against tender" }, { "kind": "writeback", "system": "WooCommerce", "label": "Tag order", "detail": "store Xero invoice reference" } ] }, "timeline": { "weeks": "3 to 5 weeks for a standard delivery", "phases": [ { "label": "Week 1", "detail": "Discovery: Xero chart of accounts, tax rates, tracking categories, contact-resolution policy." }, { "label": "Weeks 2 to 3", "detail": "Build: order, customer and refund flows in Patchworks." }, { "label": "Week 4", "detail": "Integration testing using staged WooCommerce orders against a Xero demo organisation; UAT with finance." }, { "label": "Week 5", "detail": "Cutover and hyper-care; transition into support retainer with monitoring and SLA." } ] }, "capabilities": [ { "capability": "order-sync", "label": "Order sync", "source": "woocommerce", "target": "xero" }, { "capability": "customer-sync", "label": "Customer sync", "source": "woocommerce", "target": "xero" }, { "capability": "refund-sync", "label": "Refund sync", "source": "woocommerce", "target": "xero" } ], "faqs": [ { "q": "How are Xero tracking categories handled?", "a": "Per-line tracking categories map from WooCommerce order metadata or product attributes onto the corresponding Xero category. Where the merchant uses two tracking categories (region and channel, typically), both apply at the line level so reporting works end to end." }, { "q": "Does the integration support both UK VAT and AU/NZ GST?", "a": "Yes. Each jurisdiction's tax rates map to the corresponding Xero rate explicitly. The flow handles reverse-charge B2B, OSS where it's in scope, GST-free and zero-rated cases. We agree the mapping during scoping rather than relying on Xero's defaults." }, { "q": "How are refunds represented in Xero?", "a": "Refunds post as credit notes against the original invoice, with the right account coding and tax rate. Partial refunds map to line-level credit notes; gift-card-tendered and store-credit refunds get appropriate treatment." }, { "q": "Can the integration coexist with Xero's native WooCommerce app?", "a": "Yes, but we usually replace it. The native connection works for the simple case; we get called in when the merchant needs the integration to coordinate with other systems (warehouse, marketplace, returns platform) or where the merchant's WooCommerce setup has customisations the native app doesn't model." }, { "q": "Do you support WooCommerce-to-Xero under SLA after go-live?", "a": "Yes. The same team that builds the integration runs it under retainer. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month." } ] }, { "slug": "shopify-to-veeqo", "a": "shopify", "b": "veeqo", "url": "https://www.ecirql.com/integrations/shopify-to-veeqo/", "lead": "Veeqo is a multichannel-friendly inventory and shipping platform that a lot of growing UK ecommerce operations choose when they need more than Shopify's native fulfilment but less than a full WMS. The integration carries orders and customers out of Shopify into Veeqo for picking and shipping, and lifts stock, fulfilment and tracking back so the storefront reflects what the warehouse just did. Built and supported as a certified Patchworks Partner Agency.", "patchworks_angle": "Veeqo's strength is in handling multiple channels and warehouses from one place; the integration's job is to make sure the Shopify channel is one well-modelled slice of that rather than a special case. We build the Shopify-to-Veeqo flows in Patchworks with explicit handling for split shipments, multi-warehouse routing, carrier service selection and the writeback that closes the loop back to the customer-facing surface in Shopify.", "flow": { "title": "Order to dispatch: Shopify to Veeqo", "description": "How a Shopify order moves into Veeqo for picking and ships back into Shopify as a fulfilment with carrier tracking attached.", "steps": [ { "kind": "trigger", "system": "Shopify", "label": "Order created", "detail": "order/create webhook" }, { "kind": "extract", "system": "Patchworks", "label": "Ingest payload", "detail": "queue, dedupe, normalise" }, { "kind": "transform", "system": "Patchworks", "label": "Resolve warehouse", "detail": "location rules, SKU coverage" }, { "kind": "action", "system": "Veeqo", "label": "Create sales order", "detail": "with service and packaging hints" }, { "kind": "trigger", "system": "Veeqo", "label": "Shipment created", "detail": "dispatch with carrier + tracking" }, { "kind": "transform", "system": "Patchworks", "label": "Map fulfilment", "detail": "line-level, split-safe" }, { "kind": "writeback", "system": "Shopify", "label": "Update order", "detail": "fulfilment, tracking, customer notification" } ] }, "timeline": { "weeks": "3 to 6 weeks for a standard delivery", "phases": [ { "label": "Week 1", "detail": "Discovery: Veeqo warehouse and channel setup, carrier mix, fulfilment rules, packaging hints." }, { "label": "Weeks 2 to 3", "detail": "Build: order, fulfilment, inventory and tracking flows in Patchworks." }, { "label": "Weeks 4 to 5", "detail": "Integration testing against the Veeqo sandbox using staged Shopify orders; UAT with the warehouse team." }, { "label": "Week 6", "detail": "Cutover and hyper-care; transition into support retainer with monitoring and SLA." } ] }, "capabilities": [ { "capability": "order-sync", "label": "Order sync", "source": "shopify", "target": "veeqo" }, { "capability": "inventory-sync", "label": "Inventory sync", "source": "veeqo", "target": "shopify" }, { "capability": "fulfilment-sync", "label": "Fulfilment sync", "source": "veeqo", "target": "shopify" }, { "capability": "tracking-sync", "label": "Tracking sync", "source": "veeqo", "target": "shopify" }, { "capability": "returns-sync", "label": "Returns sync", "source": "shopify", "target": "veeqo" } ], "faqs": [ { "q": "Can Veeqo own inventory while Shopify shows availability?", "a": "Yes. Veeqo is typically the source of truth for sellable stock, with channel-aware availability rules publishing to Shopify on a fast cadence plus event-driven updates on warehouse movement. Safety stock buffers are configurable per SKU group and per warehouse." }, { "q": "How does the integration handle multi-warehouse?", "a": "Each Veeqo warehouse is its own location with its own routing and availability rules. Orders route to the right warehouse based on inventory coverage, customer address, or merchant rules; split shipments across warehouses are first-class rather than a special case." }, { "q": "Can the same Veeqo instance serve multiple Shopify stores?", "a": "Yes. Each Shopify store is a separate channel in Veeqo with its own inventory pool or shared availability, depending on merchant rules. The integration scopes per store cleanly so multi-store operations land in the right place." }, { "q": "What about Veeqo's own Amazon and eBay integrations?", "a": "They can coexist. Where the merchant uses Veeqo's native marketplace integrations, our integration sits on the Shopify side without conflict. Where the merchant wants a single integration estate, we can run Shopify, Amazon and eBay through Patchworks instead." }, { "q": "Do you support Shopify-to-Veeqo under SLA after go-live?", "a": "Yes. The same team that builds the integration runs it under retainer. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month." } ] }, { "slug": "akeneo-to-bigcommerce", "a": "akeneo", "b": "bigcommerce", "url": "https://www.ecirql.com/integrations/akeneo-to-bigcommerce/", "lead": "Akeneo holds the enriched product master data; BigCommerce is the storefront where shoppers see it. The integration carries channel-aware, locale-specific product data out of Akeneo into BigCommerce as channel-ready listings, with variants, media, custom fields and category mappings handled explicitly. We design, build and support Akeneo-to-BigCommerce publication as a certified Patchworks Partner Agency, so merchandising controls the storefront from the PIM rather than juggling two source-of-truth surfaces.", "patchworks_angle": "BigCommerce's catalogue is well-shaped for integration, and Akeneo's channel and locale model is built for exactly this kind of publication. The work is in respecting both: channel-aware publication, locale-specific copy, category mapping onto BigCommerce's tree, and a publication gate so merchandising controls when each product goes live. We build the Akeneo-to-BigCommerce flows in Patchworks with new launches, routine updates and deprecation handled by the same pipeline.", "flow": { "title": "Product publication: Akeneo to BigCommerce", "description": "How an Akeneo product reaches BigCommerce as a channel-ready listing with variants, media, locale copy and category mapping in place from the first run.", "steps": [ { "kind": "trigger", "system": "Akeneo", "label": "Product published", "detail": "channel-specific publication event" }, { "kind": "extract", "system": "Patchworks", "label": "Fetch product", "detail": "with channel and locale scope" }, { "kind": "transform", "system": "Patchworks", "label": "Map attributes", "detail": "to BigCommerce fields and variants" }, { "kind": "transform", "system": "Patchworks", "label": "Resolve media", "detail": "image order, alt text, locale variants" }, { "kind": "decision", "system": "Patchworks", "label": "Product exists?", "detail": "BigCommerce catalogue lookup" }, { "kind": "action", "system": "BigCommerce", "label": "Create / update", "detail": "via Catalog API v3" }, { "kind": "writeback", "system": "Akeneo", "label": "Mark synced", "detail": "publication timestamp + status" } ] }, "timeline": { "weeks": "5 to 8 weeks for a standard delivery", "phases": [ { "label": "Week 1", "detail": "Discovery: Akeneo channel + locale setup, BigCommerce custom-field architecture, category mapping, media rules." }, { "label": "Weeks 2 to 4", "detail": "Build: product, variant, media and custom-field publication flows in Patchworks." }, { "label": "Weeks 5 to 6", "detail": "Integration testing against the BigCommerce store with a representative product set." }, { "label": "Week 7", "detail": "UAT with merchandising; sign-off on attribute mapping, category alignment and locale handling." }, { "label": "Week 8", "detail": "Cutover and hyper-care; transition into support retainer with monitoring and SLA." } ] }, "capabilities": [ { "capability": "product-sync", "label": "Product sync", "source": "akeneo", "target": "bigcommerce" }, { "capability": "product-syndication", "label": "Product syndication", "source": "akeneo", "target": "bigcommerce" } ], "faqs": [ { "q": "How are BigCommerce custom fields modelled in Akeneo?", "a": "Each BigCommerce custom field maps to an Akeneo attribute with the right type and scope. The mapping is configured during scoping so merchandising sees Akeneo as the source of truth without learning two product surfaces." }, { "q": "Does the integration support BigCommerce multi-storefront?", "a": "Yes. Each storefront maps to its own Akeneo channel with its own locale and currency scope, so multi-market merchants publish the right copy, pricing and product mix per storefront from one Akeneo source." }, { "q": "How are product variants handled?", "a": "Akeneo's variant axes map onto BigCommerce product options. New variants flow through automatically; deprecated variants are flagged rather than hard-deleted so historical orders and reviews stay intact." }, { "q": "Can merchandising control when a product goes live?", "a": "Yes. The integration uses Akeneo's publication state as the gate. A product only reaches BigCommerce when merchandising explicitly publishes it on the relevant channel; status changes propagate immediately." }, { "q": "Do you support Akeneo-to-BigCommerce under SLA after go-live?", "a": "Yes. The same team that builds the integration runs it under retainer. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month." } ] }, { "slug": "shopify-to-xero", "a": "shopify", "b": "xero", "url": "https://www.ecirql.com/integrations/shopify-to-xero/", "lead": "Shopify is where the orders come in. Xero is where the books balance. A well-built integration takes the daily reconciliation effort and reduces it to a check rather than a project. We move orders, refunds and payments out of Shopify into Xero as proper sales invoices and credit notes, with VAT codes mapped, Shopify Payments fees separated from gross revenue, and gateway payouts reconciled against the Xero bank feed. Built and supported as a Patchworks Partner Agency, with the same engineering team carrying the work through to ongoing retainer.", "patchworks_angle": "The Shopify-to-Xero canonical patterns are well-trodden on Patchworks; the work we add is everything Xero is opinionated about. VAT scheme alignment under MTD, multi-currency rounding to the contact's base currency, gift-card liability accounting and the difference between bank-fed and integration-fed reconciliation. Flows live in Patchworks, version against your release cadence, and the handover runbook is one your finance team can audit on its own.", "flow": { "title": "Order sync: Shopify to Xero", "description": "Every paid Shopify order lands in Xero as a structured sales invoice with the right VAT codes and customer record, ready for the gateway payout to land in the bank feed.", "steps": [ { "kind": "trigger", "system": "Shopify", "label": "Order paid", "detail": "orders/paid webhook" }, { "kind": "extract", "system": "Patchworks", "label": "Ingest order", "detail": "queue, dedupe" }, { "kind": "decision", "system": "Patchworks", "label": "Contact exists?", "detail": "lookup by email" }, { "kind": "transform", "system": "Patchworks", "label": "Map invoice", "detail": "VAT codes, payment account, currency" }, { "kind": "action", "system": "Xero", "label": "Create invoice", "detail": "with payment applied" }, { "kind": "writeback", "system": "Shopify", "label": "Tag order", "detail": "store Xero invoice number" } ] }, "timeline": { "weeks": "4 to 6 weeks for a standard delivery", "phases": [ { "label": "Week 1", "detail": "Discovery: VAT scheme, chart of accounts, gateway payout cadence, multi-currency exposure." }, { "label": "Weeks 2 to 3", "detail": "Build: orders, refunds, customers, payments, fee separation." }, { "label": "Week 4", "detail": "Reconciliation: gateway payouts mapped onto Xero bank feed entries." }, { "label": "Weeks 5 to 6", "detail": "UAT with finance, cutover, hyper-care into retainer." } ] }, "capabilities": [ { "capability": "order-sync", "label": "Order sync", "source": "shopify", "target": "xero" }, { "capability": "customer-sync", "label": "Customer sync", "source": "shopify", "target": "xero" }, { "capability": "refund-sync", "label": "Refund sync", "source": "shopify", "target": "xero" } ], "faqs": [ { "q": "How does this handle Shopify Payments gateway fees?", "a": "Each daily payout is split into the underlying order revenue and the Shopify Payments fee, posted to the right nominal codes. The Xero bank feed then matches the payout amount in a single click rather than line-by-line." }, { "q": "What about multi-currency orders?", "a": "Orders post in the order currency where the Xero contact has that currency enabled; otherwise we convert to the contact's base currency using your defined rate source. FX gain or loss posts to a configured account so the trial balance stays honest." }, { "q": "Does this work under UK Making Tax Digital?", "a": "Yes. Sales invoices carry the right VAT scheme codes (Standard, Reduced, Zero, EU postponed, Reverse charge) so Xero's MTD submission picks them up correctly. We map Shopify's tax-line variants to Xero VAT codes at scoping." }, { "q": "Do you support this combo under SLA after go-live?", "a": "Yes. The same team that builds the integration runs it under retainer. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month." } ] }, { "slug": "shopify-to-linnworks", "a": "shopify", "b": "linnworks", "url": "https://www.ecirql.com/integrations/shopify-to-linnworks/", "lead": "Shopify is one sales channel among many. Linnworks is the multichannel operations brain: stock, listings, orders, despatch, all under one roof. Connecting them properly means Shopify becomes a real input into the wider channel mix rather than an island. Orders flow in for fulfilment, inventory and pricing push back out, and the Linnworks side stays authoritative for stock across every channel. We design, build and support Shopify-to-Linnworks integrations as a Patchworks Partner Agency, with the SLA picking up the moment cutover lands.", "patchworks_angle": "Linnworks has a built-in Shopify channel; what we add is the integration discipline that keeps multi-channel stock from drifting. Patchworks sits in front of Linnworks where the merchant needs deterministic event handling, retries, replay and an audit trail that survives a Linnworks outage. We build the canvases in Patchworks, version flows against the merchant's release process and hand over runbooks that cover the cases Linnworks logs alone won't tell you about.", "flow": { "title": "Order sync: Shopify to Linnworks", "description": "Each Shopify order arrives in Linnworks ready for picking, with stock decremented across every channel as part of the same event.", "steps": [ { "kind": "trigger", "system": "Shopify", "label": "Order created", "detail": "order/create webhook" }, { "kind": "extract", "system": "Patchworks", "label": "Ingest payload", "detail": "queue, dedupe, normalise" }, { "kind": "transform", "system": "Patchworks", "label": "Map to Linnworks", "detail": "SKUs, channels, locations" }, { "kind": "action", "system": "Linnworks", "label": "Create order", "detail": "in despatch queue" }, { "kind": "action", "system": "Linnworks", "label": "Allocate stock", "detail": "across configured warehouse" }, { "kind": "writeback", "system": "Shopify", "label": "Tag with Linnworks ID", "detail": "for audit" } ] }, "timeline": { "weeks": "4 to 7 weeks for a standard delivery", "phases": [ { "label": "Week 1", "detail": "Discovery: channel inventory, SKU strategy, location model, despatch profile." }, { "label": "Weeks 2 to 4", "detail": "Build: orders, inventory, products, fulfilment writeback." }, { "label": "Week 5", "detail": "Integration testing under realistic multi-channel order volume." }, { "label": "Weeks 6 to 7", "detail": "UAT with operations, cutover, hyper-care into retainer." } ] }, "capabilities": [], "faqs": [ { "q": "We already use the Linnworks Shopify channel. Why add Patchworks?", "a": "The Linnworks channel is fine for simple stores. Patchworks earns its place once you need event retries, replay, custom mapping rules, or visibility across more than one Shopify store. If the native channel works for you today, we'd tell you to leave it alone." }, { "q": "How does multi-location inventory work?", "a": "Linnworks remains the source of truth for stock; we push availability into Shopify with location-aware rules so customers see accurate stock by ship-from location. Safety-stock buffers, in-transit qty and held stock are all handled at the integration boundary." }, { "q": "What if we sell on Amazon and eBay through Linnworks as well?", "a": "Linnworks keeps doing that natively. The Patchworks integration is the Shopify side of the picture. Stock decrements from a Shopify sale propagate through Linnworks to every channel automatically." }, { "q": "Do you support this under SLA after go-live?", "a": "Yes. The same team that builds the integration runs it under retainer. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month." } ] }, { "slug": "magento-to-brightpearl", "a": "magento", "b": "brightpearl", "url": "https://www.ecirql.com/integrations/magento-to-brightpearl/", "lead": "Magento (Adobe Commerce) is the storefront. Brightpearl is the retail operations spine: inventory, orders, purchasing, accounting, the lot. Connecting them well means Magento drives orders into Brightpearl as real sales documents, Brightpearl pushes the only authoritative stock number back, and the integration negotiates the long list of edge cases around B2B pricing, multi-warehouse routing and tax. We design, build and support Magento-to-Brightpearl integrations as a Patchworks Partner Agency, with SLA-backed support from go-live.", "patchworks_angle": "Brightpearl has a Magento connector of its own, and for many merchants that's the right place to start. Patchworks earns its place where Magento's catalogue depth pushes the native connector against its limits: large attribute sets, configurable products with non-trivial variant trees, customer-group pricing, multi-source inventory. We build those flows in Patchworks, version them with the merchant's release cadence, and hand over runbooks that cover the cases the native connector glosses past.", "flow": { "title": "Order sync: Magento to Brightpearl", "description": "Magento orders land in Brightpearl as proper sales orders with the right customer record, pricing context and warehouse routing.", "steps": [ { "kind": "trigger", "system": "Magento", "label": "Order placed", "detail": "sales_order_place event" }, { "kind": "extract", "system": "Patchworks", "label": "Ingest order", "detail": "queue, dedupe" }, { "kind": "decision", "system": "Patchworks", "label": "Customer exists?", "detail": "lookup by email" }, { "kind": "transform", "system": "Patchworks", "label": "Map order", "detail": "SKUs, pricing, tax, warehouse" }, { "kind": "action", "system": "Brightpearl", "label": "Create sales order", "detail": "with allocation" }, { "kind": "writeback", "system": "Magento", "label": "Tag order", "detail": "store Brightpearl ID" } ] }, "timeline": { "weeks": "6 to 9 weeks for a standard delivery", "phases": [ { "label": "Week 1", "detail": "Discovery: catalogue depth, customer groups, warehouse model, tax setup." }, { "label": "Weeks 2 to 4", "detail": "Build: products, inventory, orders, customers, fulfilment writeback." }, { "label": "Weeks 5 to 6", "detail": "Integration testing with real Magento and Brightpearl sandbox data." }, { "label": "Weeks 7 to 8", "detail": "UAT with operations and finance; sign-off on edge cases." }, { "label": "Week 9", "detail": "Cutover and hyper-care; transition into support retainer." } ] }, "capabilities": [ { "capability": "order-sync", "label": "Order sync", "source": "magento", "target": "brightpearl" }, { "capability": "inventory-sync", "label": "Inventory sync", "source": "brightpearl", "target": "magento" }, { "capability": "product-sync", "label": "Product sync", "source": "brightpearl", "target": "magento" }, { "capability": "pricing-sync", "label": "Pricing sync", "source": "brightpearl", "target": "magento" }, { "capability": "customer-sync", "label": "Customer sync", "source": "magento", "target": "brightpearl" } ], "faqs": [ { "q": "Do you handle configurable products and their child SKUs?", "a": "Yes. We map Magento's configurable + simple-product pattern onto Brightpearl's parent/variant model explicitly at scoping. The integration treats the simple-product SKU as authoritative for stock and pricing, with the configurable used for storefront display." }, { "q": "What about customer-group pricing in Magento?", "a": "Customer groups map to Brightpearl price lists. Orders carry the right effective price for the customer at checkout, and Brightpearl posts the matching invoice without finance having to override anything." }, { "q": "How is multi-source inventory handled?", "a": "Brightpearl is the source of truth for sellable stock. Magento Multi-Source Inventory receives availability by source so customer-facing stock reflects the warehouse split rather than a single aggregate number." }, { "q": "Do you support this under SLA after go-live?", "a": "Yes. The same team that builds the integration runs it under retainer. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month." } ] }, { "slug": "magento-to-microsoft-dynamics-business-central", "a": "magento", "b": "microsoft-dynamics-business-central", "url": "https://www.ecirql.com/integrations/magento-to-microsoft-dynamics-business-central/", "lead": "Magento (Adobe Commerce) handles the storefront. Microsoft Dynamics 365 Business Central is the financial and operational system of record. Connecting them properly means orders flow into BC as proper sales documents, customers post against the right ledgers, and finance has a clean audit trail from checkout to general ledger. We design, build and support Magento-to-Business Central integrations as a Patchworks Partner Agency, with the same team carrying delivery into ongoing SLA cover.", "patchworks_angle": "Business Central has its own opinions about how transactional data lands: customer card requirements, posting groups, dimension codes, VAT business and product groups. The Magento side has its own structures (EAV catalogue, customer groups, configurable products) that don't always have a one-to-one BC mapping. We build the translation in Patchworks, document the mappings explicitly and hand over runbooks the BC consultant can act on without calling us.", "flow": { "title": "Order sync: Magento to Business Central", "description": "Magento orders land in Business Central as posted sales documents with the right dimensions, posting groups and customer ledger entries.", "steps": [ { "kind": "trigger", "system": "Magento", "label": "Order placed", "detail": "sales_order_place" }, { "kind": "extract", "system": "Patchworks", "label": "Ingest order", "detail": "queue, dedupe" }, { "kind": "decision", "system": "Patchworks", "label": "Customer card exists?", "detail": "lookup by email / external ID" }, { "kind": "transform", "system": "Patchworks", "label": "Map order", "detail": "items, dimensions, VAT groups" }, { "kind": "action", "system": "BC", "label": "Create sales order", "detail": "via API endpoint" }, { "kind": "writeback", "system": "Magento", "label": "Tag order", "detail": "store BC document number" } ] }, "timeline": { "weeks": "8 to 12 weeks for a standard delivery", "phases": [ { "label": "Week 1", "detail": "Discovery: chart of accounts, posting groups, dimension model, VAT setup." }, { "label": "Weeks 2 to 5", "detail": "Build: customers, items, orders, inventory, invoices, fulfilment writeback." }, { "label": "Weeks 6 to 8", "detail": "Integration testing against Magento and BC sandbox; finance review." }, { "label": "Weeks 9 to 10", "detail": "UAT with finance and operations." }, { "label": "Weeks 11 to 12", "detail": "Cutover and hyper-care into retainer." } ] }, "capabilities": [ { "capability": "order-sync", "label": "Order sync", "source": "magento", "target": "microsoft-dynamics-business-central" }, { "capability": "inventory-sync", "label": "Inventory sync", "source": "microsoft-dynamics-business-central", "target": "magento" }, { "capability": "product-sync", "label": "Product sync", "source": "microsoft-dynamics-business-central", "target": "magento" }, { "capability": "pricing-sync", "label": "Pricing sync", "source": "microsoft-dynamics-business-central", "target": "magento" }, { "capability": "customer-sync", "label": "Customer sync", "source": "magento", "target": "microsoft-dynamics-business-central" }, { "capability": "tax-sync", "label": "Tax sync", "source": "microsoft-dynamics-business-central", "target": "magento" } ], "faqs": [ { "q": "Do you handle BC dimensions on every transaction?", "a": "Yes. Dimensions are mapped explicitly at scoping (typically channel, region, brand, where they exist) and applied to every posted line. Finance reporting works out of the box because the dimension data is right at source." }, { "q": "What about VAT business / product posting groups?", "a": "Magento tax classes map onto BC VAT business and product posting groups. We define the matrix at scoping so VAT calculations match between the storefront and BC's tax engine without exception lists." }, { "q": "Do you handle BC's posting cadence (queued vs immediate)?", "a": "Either pattern. The integration can post to BC immediately on order creation or batch into a posting queue your operations team controls. We pick the pattern at discovery based on how your finance side runs end-of-day." }, { "q": "Do you support this under SLA after go-live?", "a": "Yes. The same team that builds the integration runs it under retainer. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month." } ] }, { "slug": "woocommerce-to-netsuite", "a": "woocommerce", "b": "netsuite", "url": "https://www.ecirql.com/integrations/woocommerce-to-netsuite/", "lead": "WooCommerce keeps the storefront close to the team that owns the content. NetSuite runs the business: stock, finance, customers, fulfilment, the lot. Connecting them properly means orders land in NetSuite as real sales documents, customers post against the right subsidiaries, and inventory and pricing flow back so the storefront stays honest. We design, build and support WooCommerce-to-NetSuite integrations as a Patchworks Partner Agency, with the same engineering team carrying delivery into ongoing SLA cover.", "patchworks_angle": "WooCommerce is a WordPress plugin first and an integration target second; its REST API behaviour varies with the host, the plugin stack and the storefront theme. Patchworks normalises that out so NetSuite sees a consistent shape regardless of which Woo extensions the merchant runs. We build the flows in Patchworks against canonical shapes, version them with the merchant's deployment process, and hand over runbooks that cover the cases Woo's own logs won't show.", "flow": { "title": "Order sync: WooCommerce to NetSuite", "description": "WooCommerce orders flow into NetSuite as Sales Orders with the right item references, subsidiary and tax codes from the first run.", "steps": [ { "kind": "trigger", "system": "WooCommerce", "label": "Order completed", "detail": "order webhook" }, { "kind": "extract", "system": "Patchworks", "label": "Ingest order", "detail": "queue, dedupe" }, { "kind": "decision", "system": "Patchworks", "label": "Customer exists?", "detail": "lookup by email" }, { "kind": "transform", "system": "Patchworks", "label": "Map order", "detail": "items, taxes, subsidiary" }, { "kind": "action", "system": "NetSuite", "label": "Create Sales Order", "detail": "via SuiteTalk / RESTlet" }, { "kind": "writeback", "system": "WooCommerce", "label": "Tag order", "detail": "store NetSuite document number" } ] }, "timeline": { "weeks": "6 to 10 weeks for a standard delivery", "phases": [ { "label": "Week 1", "detail": "Discovery: Woo plugin landscape, NetSuite record-type choice, edge cases." }, { "label": "Weeks 2 to 4", "detail": "Build: orders, customers, inventory, pricing, fulfilment writeback." }, { "label": "Weeks 5 to 6", "detail": "Integration testing against real Woo and NetSuite sandbox data." }, { "label": "Weeks 7 to 8", "detail": "UAT with operations and finance teams." }, { "label": "Weeks 9 to 10", "detail": "Cutover and hyper-care into retainer." } ] }, "capabilities": [ { "capability": "order-sync", "label": "Order sync", "source": "woocommerce", "target": "netsuite" }, { "capability": "inventory-sync", "label": "Inventory sync", "source": "netsuite", "target": "woocommerce" }, { "capability": "product-sync", "label": "Product sync", "source": "netsuite", "target": "woocommerce" }, { "capability": "pricing-sync", "label": "Pricing sync", "source": "netsuite", "target": "woocommerce" }, { "capability": "customer-sync", "label": "Customer sync", "source": "woocommerce", "target": "netsuite" }, { "capability": "refund-sync", "label": "Refund sync", "source": "netsuite", "target": "woocommerce" }, { "capability": "tax-sync", "label": "Tax sync", "source": "netsuite", "target": "woocommerce" } ], "faqs": [ { "q": "We use a long stack of Woo extensions. Does that break this?", "a": "Not if we know about them at scoping. Subscriptions, Memberships, Bookings, Product Add-Ons and the popular B2B extensions all have known landing patterns into NetSuite. We map them at discovery so the build doesn't surprise either side." }, { "q": "Do we need NetSuite OneWorld?", "a": "No. The integration works with single-instance and OneWorld. OneWorld is required where you trade through multiple subsidiaries with separate ledgers; many UK Woo merchants run single-instance and that's the right call." }, { "q": "Can NetSuite be the source of truth for inventory?", "a": "Yes; that's the standard pattern. NetSuite pushes availability into WooCommerce with location-aware rules. Where you need WooCommerce to retain inventory authority (rare), the inverse is also supportable." }, { "q": "Do you support this under SLA after go-live?", "a": "Yes. The same team that builds the integration runs it under retainer. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month." } ] }, { "slug": "woocommerce-to-sage-200", "a": "woocommerce", "b": "sage-200", "url": "https://www.ecirql.com/integrations/woocommerce-to-sage-200/", "lead": "WooCommerce keeps the storefront flexible. Sage 200 keeps the UK back office honest: nominal ledger, stock, purchase orders, VAT, the whole operational accounting stack. The integration moves orders and refunds out of Woo into Sage as proper sales documents, and pushes stock and pricing back the other way so the storefront reflects what's actually in the warehouse. Built and supported as a Patchworks Partner Agency, with SLA cover from go-live.", "patchworks_angle": "Sage 200 is built around accounting conventions rather than ecommerce expectations; integrations that ignore that need rework within months. We build the WooCommerce-to-Sage 200 flows directly in Patchworks, mapping orders to the right Sage transaction types, respecting nominal codes, VAT groups and posting cadence. The runbook covers the edge cases Sage tends to flag loudest at month-end.", "flow": { "title": "Order sync: WooCommerce to Sage 200", "description": "Each Woo order lands in Sage as a structured sales document, with VAT codes, nominal accounts and customer ledger entries correct from the first post.", "steps": [ { "kind": "trigger", "system": "WooCommerce", "label": "Order completed", "detail": "order webhook" }, { "kind": "extract", "system": "Patchworks", "label": "Ingest order", "detail": "queue, dedupe" }, { "kind": "transform", "system": "Patchworks", "label": "Map to Sage", "detail": "VAT codes, nominals, customer account" }, { "kind": "decision", "system": "Patchworks", "label": "Customer exists?", "detail": "create or update" }, { "kind": "action", "system": "Sage 200", "label": "Post sales doc", "detail": "into the right batch" }, { "kind": "writeback", "system": "WooCommerce", "label": "Tag order", "detail": "store Sage document number" } ] }, "timeline": { "weeks": "5 to 8 weeks for a standard delivery", "phases": [ { "label": "Week 1", "detail": "Discovery: chart of accounts, VAT setup, posting cadence." }, { "label": "Weeks 2 to 4", "detail": "Build: orders, customers, refunds, inventory, pricing." }, { "label": "Weeks 5 to 6", "detail": "Integration testing with Sage period-end edge cases." }, { "label": "Weeks 7 to 8", "detail": "UAT and cutover into retainer." } ] }, "capabilities": [ { "capability": "order-sync", "label": "Order sync", "source": "woocommerce", "target": "sage-200" }, { "capability": "inventory-sync", "label": "Inventory sync", "source": "sage-200", "target": "woocommerce" }, { "capability": "product-sync", "label": "Product sync", "source": "sage-200", "target": "woocommerce" }, { "capability": "pricing-sync", "label": "Pricing sync", "source": "sage-200", "target": "woocommerce" }, { "capability": "customer-sync", "label": "Customer sync", "source": "woocommerce", "target": "sage-200" }, { "capability": "refund-sync", "label": "Refund sync", "source": "woocommerce", "target": "sage-200" }, { "capability": "tax-sync", "label": "Tax sync", "source": "sage-200", "target": "woocommerce" } ], "faqs": [ { "q": "Does this work with Sage 200 Standard, Professional and Online?", "a": "Yes, against any Sage 200 that exposes its SData API or supports CSV-based posting. We confirm the interface at scoping. For Sage 200 Online (cloud) we use the standard API; on-premise versions can use SData or batch CSV depending on the customer's preference." }, { "q": "How does month-end work with the integration running?", "a": "Sage 200 closes by period rather than by hour, and the integration respects that. Orders raised in a closed period either post to the next open period with a marker, or pause for finance review, depending on what you choose at discovery." }, { "q": "Can we keep Woo's inventory native, or must Sage drive it?", "a": "Either pattern is supportable. For most merchants Sage owns purchasing and warehousing so it's the source of truth for stock, with availability pushing into Woo. For pure-DTC Woo merchants the inverse can be simpler." }, { "q": "Do you support this under SLA after go-live?", "a": "Yes. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month." } ] }, { "slug": "bigcommerce-to-sage-200", "a": "bigcommerce", "b": "sage-200", "url": "https://www.ecirql.com/integrations/bigcommerce-to-sage-200/", "lead": "BigCommerce gives merchants a fast storefront without the maintenance tax. Sage 200 gives the UK back office a finance and operations spine that auditors recognise. Joining them properly means orders, customers and refunds flow into Sage as real sales documents, with VAT codes and nominal accounts correct; stock and pricing flow back out so the storefront reflects what's actually sellable. Built and supported as a Patchworks Partner Agency, with SLA-backed support from cutover.", "patchworks_angle": "BigCommerce's order schema is generous; Sage's is opinionated. The translation is where pages of edge-case spreadsheets usually appear and where bad integrations age. We build the BigCommerce-to-Sage 200 flows in Patchworks, mapping orders to the correct Sage transaction type, nominal code and VAT group, respecting Sage's batch posting cadence where finance needs it to. Runbooks cover the cases Sage flags loudest at month-end.", "flow": { "title": "Order sync: BigCommerce to Sage 200", "description": "Each BigCommerce order lands as a structured Sage sales document with nominal codes, VAT and customer account right from the first post.", "steps": [ { "kind": "trigger", "system": "BigCommerce", "label": "Order created", "detail": "store/order webhook" }, { "kind": "extract", "system": "Patchworks", "label": "Ingest order", "detail": "queue, dedupe" }, { "kind": "decision", "system": "Patchworks", "label": "Customer exists?", "detail": "lookup by email" }, { "kind": "transform", "system": "Patchworks", "label": "Map to Sage", "detail": "VAT codes, nominals, currency" }, { "kind": "action", "system": "Sage 200", "label": "Post sales doc", "detail": "into the right batch" }, { "kind": "writeback", "system": "BigCommerce", "label": "Tag order", "detail": "store Sage document number" } ] }, "timeline": { "weeks": "5 to 8 weeks for a standard delivery", "phases": [ { "label": "Week 1", "detail": "Discovery: chart of accounts, VAT, posting cadence, BC channel model." }, { "label": "Weeks 2 to 4", "detail": "Build: orders, customers, refunds, inventory, pricing." }, { "label": "Weeks 5 to 6", "detail": "Integration testing including period-end cases." }, { "label": "Weeks 7 to 8", "detail": "UAT and cutover into retainer." } ] }, "capabilities": [ { "capability": "order-sync", "label": "Order sync", "source": "bigcommerce", "target": "sage-200" }, { "capability": "inventory-sync", "label": "Inventory sync", "source": "sage-200", "target": "bigcommerce" }, { "capability": "product-sync", "label": "Product sync", "source": "sage-200", "target": "bigcommerce" }, { "capability": "pricing-sync", "label": "Pricing sync", "source": "sage-200", "target": "bigcommerce" }, { "capability": "customer-sync", "label": "Customer sync", "source": "bigcommerce", "target": "sage-200" }, { "capability": "tax-sync", "label": "Tax sync", "source": "sage-200", "target": "bigcommerce" } ], "faqs": [ { "q": "Does this support BigCommerce Multi-Storefront?", "a": "Yes. Each storefront can post into Sage against its own customer-account, nominal or analysis-code split so reporting separates the channels without manual work in finance." }, { "q": "How are BC's per-region storefronts handled for VAT?", "a": "We map each storefront to the right Sage VAT-group setup at discovery (UK VAT, EU OSS, RoW zero-rated, etc.). Tax-line variants in BC translate to Sage VAT codes deterministically." }, { "q": "Can BC retain inventory authority, or must Sage drive it?", "a": "Either pattern. Where Sage owns purchasing and warehousing the standard pattern is Sage-driven. For BC merchants without a fulfilment-side authority elsewhere, BC-led is also workable." }, { "q": "Do you support this under SLA after go-live?", "a": "Yes. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month." } ] }, { "slug": "bigcommerce-to-brightpearl", "a": "bigcommerce", "b": "brightpearl", "url": "https://www.ecirql.com/integrations/bigcommerce-to-brightpearl/", "lead": "BigCommerce keeps the storefront clean. Brightpearl runs retail operations end to end: inventory, orders, purchasing, accounting. Connecting them properly means BigCommerce drives orders into Brightpearl as real sales documents, Brightpearl pushes the only authoritative stock and pricing back, and the integration handles B2B pricing, multi-warehouse routing and tax-class translation without anyone having to think about it day to day. Built and supported as a Patchworks Partner Agency.", "patchworks_angle": "Brightpearl publishes a BigCommerce connector of its own; for many merchants that's the right place to start. Patchworks earns its place where the merchant runs multiple BC storefronts, custom price lists or non-trivial warehouse routing. We build those flows in Patchworks, version them with the merchant's release process and hand over runbooks that cover the cases the native connector silently glosses.", "flow": { "title": "Order sync: BigCommerce to Brightpearl", "description": "BigCommerce orders land in Brightpearl as sales orders with the right customer, pricing context and warehouse allocation.", "steps": [ { "kind": "trigger", "system": "BigCommerce", "label": "Order created", "detail": "store/order webhook" }, { "kind": "extract", "system": "Patchworks", "label": "Ingest order", "detail": "queue, dedupe" }, { "kind": "decision", "system": "Patchworks", "label": "Customer exists?", "detail": "lookup by email" }, { "kind": "transform", "system": "Patchworks", "label": "Map order", "detail": "SKUs, pricing, warehouse" }, { "kind": "action", "system": "Brightpearl", "label": "Create sales order", "detail": "with allocation" }, { "kind": "writeback", "system": "BigCommerce", "label": "Tag order", "detail": "store Brightpearl ID" } ] }, "timeline": { "weeks": "5 to 9 weeks for a standard delivery", "phases": [ { "label": "Week 1", "detail": "Discovery: storefront model, customer groups, warehouse routing." }, { "label": "Weeks 2 to 4", "detail": "Build: products, inventory, orders, customers, fulfilment." }, { "label": "Weeks 5 to 6", "detail": "Integration testing with real BC and Brightpearl sandbox data." }, { "label": "Weeks 7 to 9", "detail": "UAT, cutover, hyper-care into retainer." } ] }, "capabilities": [ { "capability": "order-sync", "label": "Order sync", "source": "bigcommerce", "target": "brightpearl" }, { "capability": "inventory-sync", "label": "Inventory sync", "source": "brightpearl", "target": "bigcommerce" }, { "capability": "product-sync", "label": "Product sync", "source": "brightpearl", "target": "bigcommerce" }, { "capability": "pricing-sync", "label": "Pricing sync", "source": "brightpearl", "target": "bigcommerce" }, { "capability": "customer-sync", "label": "Customer sync", "source": "bigcommerce", "target": "brightpearl" } ], "faqs": [ { "q": "How do BC customer groups map to Brightpearl?", "a": "Customer groups map to Brightpearl price lists at scoping. Orders carry the right effective price at checkout, and Brightpearl posts the matching invoice without finance having to intervene." }, { "q": "Does this handle multiple BC storefronts?", "a": "Yes. Each storefront can post against its own customer-account, channel or analysis split inside Brightpearl, so reporting separates the channels without manual work." }, { "q": "How is multi-warehouse stock allocated?", "a": "Brightpearl owns allocation logic; the integration just respects it. BC sees aggregate availability with optional channel-specific buffers, and allocation happens inside Brightpearl on order creation." }, { "q": "Do you support this under SLA after go-live?", "a": "Yes. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month." } ] }, { "slug": "shopify-to-mirakl", "a": "shopify", "b": "mirakl", "url": "https://www.ecirql.com/integrations/shopify-to-mirakl/", "lead": "Shopify is the brand storefront. Mirakl is the marketplace operator: either as a host (you're running a marketplace) or as a destination (you're listing into one of the big Mirakl-powered retailers). Connecting Shopify to Mirakl means catalogue, inventory and pricing publish onto the marketplace under the right operator rules, orders drop back into Shopify for fulfilment, and settlement data ties out against gross revenue. We design, build and support Shopify-to-Mirakl integrations as a Patchworks Partner Agency.", "patchworks_angle": "Mirakl operators each run their own attribute requirements, categorisation trees and listing rules; what works for one operator rarely works unchanged for another. Patchworks covers the canonical Mirakl shapes natively; we extend the patterns per-operator at the boundary so the merchandising team isn't stuck reconciling spreadsheets. Flows live in Patchworks with full audit trail, and runbooks cover the cases Mirakl's exception reports flag at month-end.", "flow": { "title": "Product sync: Shopify to Mirakl", "description": "Shopify's catalogue publishes onto a Mirakl operator's storefront with the right attributes, category tree and channel-specific rules enforced at the boundary.", "steps": [ { "kind": "trigger", "system": "Shopify", "label": "Product updated", "detail": "products/update webhook" }, { "kind": "extract", "system": "Patchworks", "label": "Ingest product", "detail": "queue, dedupe" }, { "kind": "transform", "system": "Patchworks", "label": "Map to operator", "detail": "attribute set, category, media" }, { "kind": "decision", "system": "Patchworks", "label": "Validates?", "detail": "required-attribute check" }, { "kind": "action", "system": "Mirakl", "label": "Publish listing", "detail": "OF24, OF25 endpoints" }, { "kind": "writeback", "system": "Shopify", "label": "Mark synced", "detail": "metafield with operator ID" } ] }, "timeline": { "weeks": "6 to 10 weeks for a standard delivery", "phases": [ { "label": "Week 1", "detail": "Discovery: operator(s), attribute requirements, category mapping, settlement model." }, { "label": "Weeks 2 to 4", "detail": "Build: products, inventory, pricing, orders, fulfilment, settlement." }, { "label": "Weeks 5 to 6", "detail": "Integration testing against operator UAT sandbox." }, { "label": "Weeks 7 to 8", "detail": "Operator-side onboarding pass; sign-off." }, { "label": "Weeks 9 to 10", "detail": "Cutover and hyper-care into retainer." } ] }, "capabilities": [], "faqs": [ { "q": "We list on three Mirakl operators. Does that mean three integrations?", "a": "One integration, three operator mappings. The Patchworks flows are operator-aware; adding a fourth is a configuration exercise, not a rebuild. The merchandising team manages per-operator overrides in one place rather than three." }, { "q": "How do orders from Mirakl land in Shopify?", "a": "Mirakl orders create Shopify Draft Orders with the marketplace tag, full customer detail and item references, then convert on confirmation. Fulfilment events from Shopify push tracking back to Mirakl on the operator's expected cadence." }, { "q": "What about settlement reconciliation?", "a": "Operator settlement reports import into a structured form so finance can reconcile gross sales, commission and fees against expected payouts. We don't store raw PDF statements; the integration pulls the structured feed where the operator exposes one." }, { "q": "Do you support this under SLA after go-live?", "a": "Yes. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month." } ] }, { "slug": "shopify-to-tiktok-shop", "a": "shopify", "b": "tiktok-shop", "url": "https://www.ecirql.com/integrations/shopify-to-tiktok-shop/", "lead": "Shopify holds the brand catalogue. TikTok Shop is the social-first sales channel, with its own rules about listings, content tagging, creator attribution and very different ideas about latency. Connecting them properly means the catalogue publishes once and stays accurate, orders drop into Shopify for fulfilment, stock moves with the rest of the channel mix, and the TikTok-specific edge cases (content-driven creators, live shopping, commission attribution) don't bleed into the merchant's main ops. Built and supported as a Patchworks Partner Agency.", "patchworks_angle": "TikTok Shop's API surface is younger than its merchant base. Patchworks isolates merchants from that volatility: when the API shape changes we update one connector and the merchant's canvases keep working. We build the publish and the order side independently so a TikTok-side incident doesn't block other channels, and the runbook tells the on-call engineer what to do when TikTok pushes rate-limit responses faster than the merchant can fulfil.", "flow": { "title": "Order sync: TikTok Shop to Shopify", "description": "Each TikTok Shop order creates a structured Shopify order ready for fulfilment, with channel attribution preserved so finance can report on TikTok independently.", "steps": [ { "kind": "trigger", "system": "TikTok Shop", "label": "Order created", "detail": "order webhook" }, { "kind": "extract", "system": "Patchworks", "label": "Ingest order", "detail": "queue, dedupe" }, { "kind": "transform", "system": "Patchworks", "label": "Map to Shopify", "detail": "SKUs, channel tag, customer" }, { "kind": "action", "system": "Shopify", "label": "Create order", "detail": "with TikTok channel tag" }, { "kind": "action", "system": "Shopify", "label": "Allocate stock", "detail": "against TikTok location" }, { "kind": "writeback", "system": "TikTok Shop", "label": "Mark received", "detail": "for operator dashboard" } ] }, "timeline": { "weeks": "5 to 8 weeks for a standard delivery", "phases": [ { "label": "Week 1", "detail": "Discovery: catalogue scope, TikTok Shop seller setup, fulfilment SLA model." }, { "label": "Weeks 2 to 4", "detail": "Build: products, inventory, pricing, orders, fulfilment writeback." }, { "label": "Weeks 5 to 6", "detail": "Integration testing under TikTok Shop sandbox." }, { "label": "Weeks 7 to 8", "detail": "Cutover and hyper-care into retainer." } ] }, "capabilities": [], "faqs": [ { "q": "Does this support TikTok's fulfilment-SLA penalties?", "a": "Yes. Order events push fulfilment status back to TikTok within the operator's expected windows. The integration alerts on flows that miss the SLA before TikTok does, so the operations team can act before penalty notices land." }, { "q": "How do affiliate-creator orders post?", "a": "Creator attribution comes through on the TikTok order payload; we surface it as Shopify order attributes so finance can split out commissioned vs direct sales, and so any downstream marketing integration sees the affiliate context." }, { "q": "Can we run TikTok Shop alongside other marketplace channels?", "a": "Yes. The integration shares inventory and catalogue logic with any other marketplace flows we've built for you (Amazon, Mirakl, ChannelEngine etc.). Stock decrements once and propagates across every channel." }, { "q": "Do you support this under SLA after go-live?", "a": "Yes. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month." } ] }, { "slug": "netsuite-to-tiktok-shop", "a": "netsuite", "b": "tiktok-shop", "url": "https://www.ecirql.com/integrations/netsuite-to-tiktok-shop/", "lead": "When NetSuite is the system of record and TikTok Shop is the channel, the integration runs ERP-first: NetSuite publishes the catalogue, owns inventory and pricing, and ingests orders for fulfilment. Settlement data flows back so finance can tie out TikTok payouts against gross sales, commission and fees. The trick is making TikTok's fast-moving operator rules and content-led merchandising fit a NetSuite item record. We design, build and support NetSuite-to-TikTok Shop integrations as a Patchworks Partner Agency.", "patchworks_angle": "NetSuite item records carry far more than any channel needs; TikTok Shop expects a tight, channel-specific shape. Patchworks does the translation at the boundary: trimming the item record to what TikTok accepts, applying channel-specific pricing, image and category rules. Flows live in Patchworks, version with NetSuite's release cadence and hand over runbooks the on-call engineer can act on without phoning the integrator at midnight.", "flow": { "title": "Order sync: TikTok Shop to NetSuite", "description": "TikTok Shop orders flow into NetSuite as Sales Orders against the right TikTok customer record, with channel-specific attribution preserved for reporting.", "steps": [ { "kind": "trigger", "system": "TikTok Shop", "label": "Order created", "detail": "order webhook" }, { "kind": "extract", "system": "Patchworks", "label": "Ingest order", "detail": "queue, dedupe" }, { "kind": "transform", "system": "Patchworks", "label": "Map to NetSuite", "detail": "items, subsidiary, class" }, { "kind": "action", "system": "NetSuite", "label": "Create Sales Order", "detail": "via SuiteTalk" }, { "kind": "action", "system": "NetSuite", "label": "Allocate stock", "detail": "against TikTok location" }, { "kind": "writeback", "system": "TikTok Shop", "label": "Acknowledge", "detail": "with NetSuite tran ID" } ] }, "timeline": { "weeks": "7 to 10 weeks for a standard delivery", "phases": [ { "label": "Week 1", "detail": "Discovery: NetSuite subsidiary model, item-record shape, TikTok seller setup." }, { "label": "Weeks 2 to 4", "detail": "Build: products, inventory, pricing, orders, fulfilment, settlement." }, { "label": "Weeks 5 to 7", "detail": "Integration testing against TikTok sandbox and NetSuite UAT." }, { "label": "Weeks 8 to 10", "detail": "Cutover and hyper-care into retainer." } ] }, "capabilities": [ { "capability": "order-sync", "label": "Order sync", "source": "tiktok-shop", "target": "netsuite" }, { "capability": "inventory-sync", "label": "Inventory sync", "source": "netsuite", "target": "tiktok-shop" }, { "capability": "product-sync", "label": "Product sync", "source": "netsuite", "target": "tiktok-shop" }, { "capability": "pricing-sync", "label": "Pricing sync", "source": "netsuite", "target": "tiktok-shop" }, { "capability": "settlement-recon", "label": "Settlement reconciliation", "source": "tiktok-shop", "target": "netsuite" } ], "faqs": [ { "q": "How does NetSuite item structure translate to TikTok listings?", "a": "Each NetSuite item maps to one TikTok Shop SKU. The integration enforces the channel-specific attribute, image and category rules at the boundary so merchandising doesn't have to maintain a parallel catalogue." }, { "q": "Do you handle TikTok's commission model?", "a": "Yes. Settlement reports import as structured finance data; commission, fees and gross sales reconcile against the expected TikTok payout. NetSuite gets the cleaned-up posting; the raw operator data stays on the integration side." }, { "q": "What about NetSuite OneWorld subsidiaries?", "a": "Orders post against the correct subsidiary based on the TikTok seller account and the shipping destination. We map the subsidiary routing at scoping so the right ledgers see the right transactions." }, { "q": "Do you support this under SLA after go-live?", "a": "Yes. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month." } ] }, { "slug": "shopify-to-zendesk", "a": "shopify", "b": "zendesk", "url": "https://www.ecirql.com/integrations/shopify-to-zendesk/", "lead": "Shopify holds the order, the customer and the fulfilment timeline. Zendesk holds the conversation, the macros and the agent workflow. Connecting them means every ticket lands with the order context already in view: status, tracking, refund history, lifetime value, last contact. Macro actions can trigger Shopify-side events without the agent switching tools. We design, build and support Shopify-to-Zendesk integrations as a Patchworks Partner Agency, with SLA-backed support from cutover.", "patchworks_angle": "Zendesk has off-the-shelf Shopify apps; for many merchants those are the right starting point. Patchworks earns its place when the support team needs more than the app exposes: data from a second Shopify store, the ERP, the WMS or the returns platform alongside the order. We build the context flows in Patchworks, surface the result as a custom Zendesk sidebar app, and version both together.", "flow": { "title": "Helpdesk context: Shopify to Zendesk", "description": "When a customer raises a Zendesk ticket, the agent sees the full Shopify order context inside the ticket view without flipping tabs.", "steps": [ { "kind": "trigger", "system": "Zendesk", "label": "Ticket opened", "detail": "ticket.created event" }, { "kind": "extract", "system": "Patchworks", "label": "Lookup customer", "detail": "by email" }, { "kind": "extract", "system": "Shopify", "label": "Get recent orders", "detail": "last 12 months" }, { "kind": "transform", "system": "Patchworks", "label": "Build context", "detail": "status, tracking, LTV, returns" }, { "kind": "action", "system": "Zendesk", "label": "Render sidebar", "detail": "via custom app" }, { "kind": "writeback", "system": "Shopify", "label": "Tag customer", "detail": "active-ticket flag" } ] }, "timeline": { "weeks": "4 to 6 weeks for a standard delivery", "phases": [ { "label": "Week 1", "detail": "Discovery: agent workflow, macro inventory, what context the team actually uses." }, { "label": "Weeks 2 to 3", "detail": "Build: context flow, custom Zendesk sidebar, macro actions." }, { "label": "Week 4", "detail": "Integration testing with the support team." }, { "label": "Weeks 5 to 6", "detail": "UAT, cutover, hyper-care into retainer." } ] }, "capabilities": [ { "capability": "customer-sync", "label": "Customer sync", "source": "shopify", "target": "zendesk" }, { "capability": "helpdesk-context", "label": "Helpdesk context", "source": "shopify", "target": "zendesk" } ], "faqs": [ { "q": "Why not just use the official Zendesk Shopify app?", "a": "If the official app does the job, you don't need us. We get the call when the support team needs context from more than one Shopify store, from the ERP or WMS, or from your returns platform alongside the order. That's where a custom integration earns its place." }, { "q": "Can macro actions in Zendesk trigger Shopify-side events?", "a": "Yes. Common patterns: 'refund this order,' 'resend tracking,' 'flag as a customer-care recovery.' The macro fires a Patchworks event which executes the Shopify-side action and writes the outcome back as a private ticket comment." }, { "q": "What about data privacy?", "a": "Customer data only flows on ticket events and only the fields the support team actually uses. We don't replicate the whole customer table into Zendesk; the agent sees fresh data pulled on demand." }, { "q": "Do you support this under SLA after go-live?", "a": "Yes. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month." } ] }, { "slug": "shopify-to-gorgias", "a": "shopify", "b": "gorgias", "url": "https://www.ecirql.com/integrations/shopify-to-gorgias/", "lead": "Gorgias is the ecommerce-native helpdesk: tickets are built around Shopify customers, orders and refunds from day one. Most merchants start with the native Shopify connector and never need more. The Patchworks integration enters the picture when the support team needs context the native connector doesn't carry: data from the ERP, WMS, returns platform or a second Shopify store, all surfaced inside the Gorgias ticket. Built and supported as a Patchworks Partner Agency.", "patchworks_angle": "Gorgias has a strong native Shopify connector. If your support stack is single-store and single-system, you don't need us. We build Gorgias integrations where the support team needs context beyond Shopify alone: order status from NetSuite, fulfilment from the WMS, return state from ReturnGO, all surfaced in the Gorgias ticket via Patchworks. Flows live in Patchworks; runbooks cover what happens when one of the upstream systems is having a bad day.", "flow": { "title": "Helpdesk context: Shopify + ops to Gorgias", "description": "Gorgias agents see the full picture inside the ticket: Shopify order data, ERP status, WMS fulfilment events, return state, all from a single sidebar.", "steps": [ { "kind": "trigger", "system": "Gorgias", "label": "Ticket opened", "detail": "ticket.created event" }, { "kind": "extract", "system": "Patchworks", "label": "Lookup customer", "detail": "by email" }, { "kind": "extract", "system": "Shopify", "label": "Get orders", "detail": "recent + LTV" }, { "kind": "extract", "system": "Other systems", "label": "Enrich", "detail": "ERP, WMS, returns" }, { "kind": "transform", "system": "Patchworks", "label": "Build context", "detail": "unified shape" }, { "kind": "action", "system": "Gorgias", "label": "Render sidebar", "detail": "via custom widget" } ] }, "timeline": { "weeks": "3 to 5 weeks for a standard delivery", "phases": [ { "label": "Week 1", "detail": "Discovery: agent workflow, which upstream systems are needed, macro inventory." }, { "label": "Weeks 2 to 3", "detail": "Build: context flow, custom Gorgias widget, macro actions." }, { "label": "Weeks 4 to 5", "detail": "UAT with support team, cutover, hyper-care into retainer." } ] }, "capabilities": [ { "capability": "customer-sync", "label": "Customer sync", "source": "shopify", "target": "gorgias" }, { "capability": "helpdesk-context", "label": "Helpdesk context", "source": "shopify", "target": "gorgias" } ], "faqs": [ { "q": "Why not just use the Gorgias native Shopify connector?", "a": "If the native connector does the job, use it. We get the call when the support team needs context that the connector doesn't carry: ERP order status, WMS dispatch info, returns state, data from a second Shopify store." }, { "q": "Can macros in Gorgias trigger upstream actions?", "a": "Yes. The macro fires a Patchworks event which runs the action against the right system (refund in Shopify, reship request to the WMS, returns label creation) and writes the outcome back to the Gorgias ticket." }, { "q": "What if one of the upstream systems is down?", "a": "The Gorgias sidebar gracefully degrades. The agent sees what's available and the missing system is flagged with a retry option; the rest of the ticket workflow keeps working. The runbook covers per-system outage patterns." }, { "q": "Do you support this under SLA after go-live?", "a": "Yes. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month." } ] }, { "slug": "shopify-to-mailchimp", "a": "shopify", "b": "mailchimp", "url": "https://www.ecirql.com/integrations/shopify-to-mailchimp/", "lead": "Shopify generates customer records and order history. Mailchimp turns them into segmented campaigns. Native connectors handle the easy cases; the Patchworks integration enters where merchants need real control over segment logic, suppression rules and what flows when. Customers, orders and product context move into Mailchimp on a predictable cadence with consent state respected end to end. Built and supported as a Patchworks Partner Agency, with the SLA picking up at cutover.", "patchworks_angle": "Mailchimp has a Shopify integration of its own and for most stores that's the right starting point. Patchworks earns its place where the merchant has multiple Shopify stores feeding one Mailchimp audience, custom segment logic the native sync can't express, or consent rules under GDPR/PECR that need an integration boundary to enforce. We build those flows in Patchworks, document the consent logic explicitly and hand over runbooks the marketing ops team can trust.", "flow": { "title": "Customer sync: Shopify to Mailchimp", "description": "Customers and order history flow from Shopify into the right Mailchimp audience, with consent state respected and segment tags applied at the boundary.", "steps": [ { "kind": "trigger", "system": "Shopify", "label": "Customer event", "detail": "create, update, opt-in" }, { "kind": "extract", "system": "Patchworks", "label": "Ingest event", "detail": "with consent state" }, { "kind": "decision", "system": "Patchworks", "label": "Consented?", "detail": "marketing opt-in check" }, { "kind": "transform", "system": "Patchworks", "label": "Build profile", "detail": "tags, segments, custom fields" }, { "kind": "action", "system": "Mailchimp", "label": "Upsert contact", "detail": "into target audience" }, { "kind": "writeback", "system": "Shopify", "label": "Tag synced", "detail": "for audit" } ] }, "timeline": { "weeks": "3 to 5 weeks for a standard delivery", "phases": [ { "label": "Week 1", "detail": "Discovery: consent model, audience structure, segment logic, suppression rules." }, { "label": "Weeks 2 to 3", "detail": "Build: customers, orders, products, consent gates." }, { "label": "Weeks 4 to 5", "detail": "UAT with marketing ops, cutover, hyper-care into retainer." } ] }, "capabilities": [ { "capability": "customer-sync", "label": "Customer sync", "source": "shopify", "target": "mailchimp" } ], "faqs": [ { "q": "Why not use the native Mailchimp for Shopify app?", "a": "If it works for you, use it. We get the call when merchants run multiple Shopify stores feeding one audience, need segment logic the native sync can't express, or need GDPR/PECR consent enforced at the integration boundary rather than per-platform." }, { "q": "How is marketing consent handled under PECR / GDPR?", "a": "Consent state is the gating signal: customers only sync to Mailchimp when their Shopify record carries the relevant marketing opt-in. Withdrawal of consent suppresses the contact in Mailchimp on the next sync cycle." }, { "q": "Can we move from one Mailchimp account to another without re-onboarding?", "a": "Yes. The integration treats Mailchimp as the destination, not the source; replacing the destination is a configuration change rather than a rebuild." }, { "q": "Do you support this under SLA after go-live?", "a": "Yes. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month." } ] }, { "slug": "shopify-to-emarsys", "a": "shopify", "b": "emarsys", "url": "https://www.ecirql.com/integrations/shopify-to-emarsys/", "lead": "Shopify holds the transactional truth: orders, customers, behaviour. Emarsys (SAP Emarsys Customer Engagement) is the enterprise engagement platform: lifecycle programmes, AI-driven segmentation, tactical content. Connecting them properly means real-time customer and order data feeds the engagement programmes; consent state is respected; product context lets recommendations reflect what's actually in the catalogue. We design, build and support Shopify-to-Emarsys integrations as a Patchworks Partner Agency.", "patchworks_angle": "Emarsys's data model rewards integration discipline: clean contact schemas, structured order shapes, product feeds that arrive on cadence. Patchworks gives the merchant a controlled boundary between Shopify's flexible storefront and Emarsys's stricter expectations. Flows live in Patchworks with full audit trail, consent gates fire at the boundary, and the runbook documents every field that crosses the wire.", "flow": { "title": "Customer + order sync: Shopify to Emarsys", "description": "Customers, orders and product context flow from Shopify into Emarsys on a real-time cadence, with consent state and segment logic enforced at the integration boundary.", "steps": [ { "kind": "trigger", "system": "Shopify", "label": "Customer / order event", "detail": "webhook" }, { "kind": "extract", "system": "Patchworks", "label": "Ingest event", "detail": "queue, dedupe" }, { "kind": "decision", "system": "Patchworks", "label": "Consented?", "detail": "channel-level opt-in" }, { "kind": "transform", "system": "Patchworks", "label": "Map to Emarsys", "detail": "contact, sales data, products" }, { "kind": "action", "system": "Emarsys", "label": "Push update", "detail": "via Suite API" }, { "kind": "writeback", "system": "Shopify", "label": "Tag synced", "detail": "for audit" } ] }, "timeline": { "weeks": "6 to 10 weeks for a standard delivery", "phases": [ { "label": "Week 1", "detail": "Discovery: contact schema, sales-data fields, product catalogue feed, consent model." }, { "label": "Weeks 2 to 5", "detail": "Build: contacts, orders, products, behavioural events, consent gates." }, { "label": "Weeks 6 to 7", "detail": "UAT with marketing automation team." }, { "label": "Weeks 8 to 10", "detail": "Cutover and hyper-care into retainer." } ] }, "capabilities": [ { "capability": "order-sync", "label": "Order sync", "source": "shopify", "target": "emarsys" }, { "capability": "customer-sync", "label": "Customer sync", "source": "shopify", "target": "emarsys" } ], "faqs": [ { "q": "Can Emarsys triggers fire from Shopify events?", "a": "Yes. Patchworks normalises the Shopify event stream and pushes the relevant signals into Emarsys so lifecycle programmes fire on real customer behaviour rather than on a daily batch." }, { "q": "How is consent state handled across channels?", "a": "Channel-level consent (email, SMS, push) is the gating signal; the integration honours each channel separately rather than treating consent as binary. Withdrawal suppresses the contact within minutes on the next cycle." }, { "q": "What about product feed depth?", "a": "Emarsys's product feed accepts as much catalogue data as the merchant wants to push. We size the feed at discovery: enough to drive recommendations and content, not so much that maintenance becomes its own project." }, { "q": "Do you support this under SLA after go-live?", "a": "Yes. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month." } ] }, { "slug": "magento-to-klaviyo", "a": "magento", "b": "klaviyo", "url": "https://www.ecirql.com/integrations/magento-to-klaviyo/", "lead": "Magento (Adobe Commerce) gives merchants control over the storefront and the catalogue. Klaviyo gives them control over the email and SMS channel. A well-built integration moves customers, orders, product context and behavioural events from Magento into Klaviyo with consent state respected end to end. Built and supported as a Patchworks Partner Agency, with the SLA picking up the moment cutover lands.", "patchworks_angle": "Klaviyo has a native Magento integration; for most merchants that's the right starting point. Patchworks earns its place where merchants run multiple storefronts feeding one Klaviyo account, have GDPR consent rules to enforce at the integration boundary, or need segment logic that the native sync can't express. Flows live in Patchworks with full audit trail; runbooks document every field that crosses the wire.", "flow": { "title": "Customer + order sync: Magento to Klaviyo", "description": "Customers, orders and behavioural events flow from Magento into Klaviyo with consent enforced and segment tags applied at the integration boundary.", "steps": [ { "kind": "trigger", "system": "Magento", "label": "Customer / order event", "detail": "platform event" }, { "kind": "extract", "system": "Patchworks", "label": "Ingest", "detail": "queue, dedupe" }, { "kind": "decision", "system": "Patchworks", "label": "Consented?", "detail": "channel-level opt-in" }, { "kind": "transform", "system": "Patchworks", "label": "Map to Klaviyo", "detail": "profile, events, segments" }, { "kind": "action", "system": "Klaviyo", "label": "Push update", "detail": "via Klaviyo API" }, { "kind": "writeback", "system": "Magento", "label": "Tag synced", "detail": "for audit" } ] }, "timeline": { "weeks": "4 to 6 weeks for a standard delivery", "phases": [ { "label": "Week 1", "detail": "Discovery: storefront count, consent model, segment logic, event taxonomy." }, { "label": "Weeks 2 to 3", "detail": "Build: customers, orders, products, events, consent gates." }, { "label": "Weeks 4 to 5", "detail": "UAT with marketing automation team." }, { "label": "Week 6", "detail": "Cutover and hyper-care into retainer." } ] }, "capabilities": [ { "capability": "order-sync", "label": "Order sync", "source": "magento", "target": "klaviyo" }, { "capability": "customer-sync", "label": "Customer sync", "source": "magento", "target": "klaviyo" } ], "faqs": [ { "q": "Why not use the native Klaviyo for Magento app?", "a": "If it does what you need, use it. We get the call when merchants run multiple storefronts feeding one Klaviyo account, need consent enforced at the integration boundary, or want segment logic the native sync doesn't express." }, { "q": "How is consent handled?", "a": "Channel-level consent (email and SMS separately) is the gating signal. Customers only sync when their Magento record carries the right channel-specific opt-in. Withdrawal suppresses the contact in Klaviyo on the next cycle." }, { "q": "What about events beyond order placed?", "a": "We push the events Klaviyo's flows actually use: Started Checkout, Placed Order, Refunded Order, Fulfilled, Subscribed, Unsubscribed. Custom events for B2B-specific lifecycles are added at scoping." }, { "q": "Do you support this under SLA after go-live?", "a": "Yes. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month." } ] }, { "slug": "shopify-to-bloomreach", "a": "shopify", "b": "bloomreach", "url": "https://www.ecirql.com/integrations/shopify-to-bloomreach/", "lead": "Shopify generates the transactional truth: orders, customers, products, behaviour. Bloomreach Engagement turns that into the personalisation, campaigns and AI-driven content the brand needs across its lifecycle. Connecting them properly means real-time events feed Bloomreach's segmentation and content engine, customer data lands in the expected schema, and consent state is respected end to end. Built and supported as a Patchworks Partner Agency.", "patchworks_angle": "Bloomreach Engagement expects a structured event stream; Shopify's webhook surface is generous but doesn't natively match. Patchworks does the translation at the boundary: normalising events into the Bloomreach event taxonomy, batching where the rate-limits require, and applying consent gates that the merchant team can audit. Flows live in Patchworks; runbooks cover the cases where Bloomreach's segment recalculation lags behind real-world behaviour.", "flow": { "title": "Customer + event sync: Shopify to Bloomreach", "description": "Customer and order events flow from Shopify into Bloomreach Engagement in real time so lifecycle programmes fire on actual behaviour, not yesterday's batch.", "steps": [ { "kind": "trigger", "system": "Shopify", "label": "Customer / order event", "detail": "webhook" }, { "kind": "extract", "system": "Patchworks", "label": "Ingest", "detail": "queue, dedupe" }, { "kind": "decision", "system": "Patchworks", "label": "Consented?", "detail": "channel-level opt-in" }, { "kind": "transform", "system": "Patchworks", "label": "Map to Bloomreach", "detail": "event taxonomy, customer properties" }, { "kind": "action", "system": "Bloomreach", "label": "Push event", "detail": "via REST API" }, { "kind": "writeback", "system": "Shopify", "label": "Tag synced", "detail": "for audit" } ] }, "timeline": { "weeks": "5 to 8 weeks for a standard delivery", "phases": [ { "label": "Week 1", "detail": "Discovery: event taxonomy, customer schema, consent model, catalogue feed." }, { "label": "Weeks 2 to 4", "detail": "Build: events, customer properties, catalogue feed, consent gates." }, { "label": "Weeks 5 to 6", "detail": "UAT with marketing automation team." }, { "label": "Weeks 7 to 8", "detail": "Cutover and hyper-care into retainer." } ] }, "capabilities": [ { "capability": "order-sync", "label": "Order sync", "source": "shopify", "target": "bloomreach" }, { "capability": "customer-sync", "label": "Customer sync", "source": "shopify", "target": "bloomreach" } ], "faqs": [ { "q": "What events do you push by default?", "a": "The canonical lifecycle events: View Item, Add To Cart, Started Checkout, Placed Order, Refunded, Subscribed, Unsubscribed. Custom events specific to the merchant's lifecycle programmes are added at scoping." }, { "q": "How is the catalogue feed sized?", "a": "Bloomreach accepts a full catalogue feed; we right-size at discovery so the feed carries enough to drive recommendations and content without becoming a maintenance burden of its own. Inventory updates flow on a separate, faster cadence than catalogue master data." }, { "q": "How is consent handled?", "a": "Channel-level consent (email, SMS, push) gates the relevant event streams. Withdrawal of consent suppresses the contact's eligibility in Bloomreach within minutes." }, { "q": "Do you support this under SLA after go-live?", "a": "Yes. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month." } ] }, { "slug": "shopify-to-algolia", "a": "shopify", "b": "algolia", "url": "https://www.ecirql.com/integrations/shopify-to-algolia/", "lead": "Shopify's native search is competent for small catalogues. Once the catalogue grows, the merchandising team needs more: synonyms, boosting rules, per-segment ranking, faceting that reflects how shoppers actually browse. Algolia gives them that. The integration moves product, variant, inventory and merchandising data from Shopify into Algolia indices on a real-time cadence so what's ranked is what's actually sellable. Built and supported as a Patchworks Partner Agency.", "patchworks_angle": "Algolia has an official Shopify app; many merchants run on it happily. Patchworks earns its place where the merchant indexes across multiple Shopify stores, blends catalogue data from a PIM or ERP, or needs index updates to fire on inventory and price changes rather than just product edits. Flows live in Patchworks with full audit trail; runbooks cover the cases where Algolia's reindex queue lags behind merchandising changes.", "flow": { "title": "Product + inventory sync: Shopify to Algolia", "description": "Catalogue and inventory updates flow from Shopify into Algolia in real time so search reflects what's actually in stock and currently merchandised.", "steps": [ { "kind": "trigger", "system": "Shopify", "label": "Product / inventory event", "detail": "webhook" }, { "kind": "extract", "system": "Patchworks", "label": "Ingest", "detail": "queue, dedupe" }, { "kind": "transform", "system": "Patchworks", "label": "Build record", "detail": "facets, ranking signals, locale" }, { "kind": "decision", "system": "Patchworks", "label": "In stock?", "detail": "availability gate" }, { "kind": "action", "system": "Algolia", "label": "Index update", "detail": "partial / full as required" }, { "kind": "writeback", "system": "Shopify", "label": "Tag indexed", "detail": "for audit" } ] }, "timeline": { "weeks": "4 to 7 weeks for a standard delivery", "phases": [ { "label": "Week 1", "detail": "Discovery: index structure, faceting, ranking signals, multi-store needs." }, { "label": "Weeks 2 to 3", "detail": "Build: catalogue feed, inventory updates, merchandising overrides." }, { "label": "Weeks 4 to 5", "detail": "Integration testing against staging Algolia indices." }, { "label": "Weeks 6 to 7", "detail": "Cutover and hyper-care into retainer." } ] }, "capabilities": [], "faqs": [ { "q": "Why not use the official Algolia Shopify app?", "a": "If it does what you need, use it. We get the call when merchants index across multiple Shopify stores, blend Shopify with PIM/ERP catalogue data, or need real-time inventory-aware index updates rather than scheduled reindex." }, { "q": "How do you handle out-of-stock products in the index?", "a": "Configurable at scoping. The two common patterns are 'hide out-of-stock' (remove from index, easy) and 'show but de-rank' (keep in index with reduced ranking signals). The integration enforces whichever the merchandising team picks." }, { "q": "Can ranking respect customer segment?", "a": "Yes. Algolia supports per-segment ranking; the integration pushes the segment signals (B2B price tier, locale, customer group) so search ranks correctly for the logged-in shopper." }, { "q": "Do you support this under SLA after go-live?", "a": "Yes. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month." } ] }, { "slug": "plytix-to-shopify", "a": "plytix", "b": "shopify", "url": "https://www.ecirql.com/integrations/plytix-to-shopify/", "lead": "Plytix gives lean merchandising teams a PIM that doesn't fight them. Shopify is where the storefront lives. The integration moves product master data, channel-ready variants and media from Plytix into Shopify on publish so the storefront reflects the canonical catalogue without the merchandising team copy-pasting between tools. Built and supported as a Patchworks Partner Agency, with the SLA picking up the moment cutover lands.", "patchworks_angle": "Plytix's channel feeds are clean but generic; Shopify has specific expectations about metafields, variant structure, image sizes and publication state. Patchworks does the translation at the boundary so merchandising stays in Plytix while the storefront receives the Shopify-ready shape. Flows version in Patchworks against the merchant's release cadence and the runbook covers the cases where Shopify rejects payloads Plytix considers valid.", "flow": { "title": "Product sync: Plytix to Shopify", "description": "Products publish from Plytix into Shopify with the right variant tree, media, metafields and category mappings on each publication event.", "steps": [ { "kind": "trigger", "system": "Plytix", "label": "Product published", "detail": "channel publish event" }, { "kind": "extract", "system": "Patchworks", "label": "Ingest product", "detail": "queue, dedupe" }, { "kind": "transform", "system": "Patchworks", "label": "Map to Shopify", "detail": "variants, metafields, images" }, { "kind": "decision", "system": "Patchworks", "label": "Exists in Shopify?", "detail": "lookup by SKU" }, { "kind": "action", "system": "Shopify", "label": "Create or update", "detail": "via Admin API" }, { "kind": "writeback", "system": "Plytix", "label": "Mark synced", "detail": "with Shopify ID" } ] }, "timeline": { "weeks": "4 to 6 weeks for a standard delivery", "phases": [ { "label": "Week 1", "detail": "Discovery: catalogue depth, variant model, media strategy, metafield use." }, { "label": "Weeks 2 to 3", "detail": "Build: products, variants, media, metafields, publication gate." }, { "label": "Week 4", "detail": "Integration testing against staging Shopify." }, { "label": "Weeks 5 to 6", "detail": "Cutover and hyper-care into retainer." } ] }, "capabilities": [ { "capability": "product-sync", "label": "Product sync", "source": "plytix", "target": "shopify" }, { "capability": "product-syndication", "label": "Product syndication", "source": "plytix", "target": "shopify" } ], "faqs": [ { "q": "How are variants modelled?", "a": "Plytix's variant axes map onto Shopify's three-option variant model at scoping. Where Plytix has more axes than Shopify allows, we collapse the least-significant axes into metafields and document the trade-off explicitly." }, { "q": "What about media?", "a": "Images publish from Plytix's media library into Shopify with the right alt text, ordering and per-variant assignment. Updates flow on republish; the integration doesn't re-upload identical media on every cycle." }, { "q": "How does publication state work?", "a": "Plytix's channel publish state is the gate. A product reaches Shopify only when merchandising explicitly publishes it on the Shopify channel; status changes propagate immediately." }, { "q": "Do you support this under SLA after go-live?", "a": "Yes. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month." } ] }, { "slug": "salsify-to-shopify", "a": "salsify", "b": "shopify", "url": "https://www.ecirql.com/integrations/salsify-to-shopify/", "lead": "Salsify treats commerce experience management as a discipline: structured product data, multi-channel publishing, enrichment as a first-class workflow. Shopify is one publication destination among several. The integration moves product master data, variants and channel-ready content from Salsify into Shopify on publish so the storefront receives the canonical content without merchandising duplicating work. Built and supported as a Patchworks Partner Agency.", "patchworks_angle": "Salsify publishes via its Channel mechanism; Shopify's data model needs careful translation around variants, metafields and media. Patchworks gives the merchant a controlled boundary: Salsify owns the master data, Shopify receives the storefront-ready shape, and merchandising never edits product data in two systems. Flows version in Patchworks against the merchant's release process and the runbook covers the cases where Shopify rejects payloads Salsify considers valid.", "flow": { "title": "Product sync: Salsify to Shopify", "description": "Products publish from Salsify into Shopify with the right variant tree, media, metafields and category mappings on each channel publish event.", "steps": [ { "kind": "trigger", "system": "Salsify", "label": "Channel publish", "detail": "Salsify Channel event" }, { "kind": "extract", "system": "Patchworks", "label": "Ingest product", "detail": "queue, dedupe" }, { "kind": "transform", "system": "Patchworks", "label": "Map to Shopify", "detail": "variants, metafields, media" }, { "kind": "decision", "system": "Patchworks", "label": "Exists in Shopify?", "detail": "lookup by SKU" }, { "kind": "action", "system": "Shopify", "label": "Create or update", "detail": "via Admin API" }, { "kind": "writeback", "system": "Salsify", "label": "Mark synced", "detail": "with Shopify ID" } ] }, "timeline": { "weeks": "5 to 8 weeks for a standard delivery", "phases": [ { "label": "Week 1", "detail": "Discovery: Salsify Channel setup, variant model, metafield use, media." }, { "label": "Weeks 2 to 4", "detail": "Build: products, variants, media, metafields, publication gate." }, { "label": "Week 5", "detail": "Integration testing against staging Shopify." }, { "label": "Weeks 6 to 8", "detail": "Cutover and hyper-care into retainer." } ] }, "capabilities": [ { "capability": "product-sync", "label": "Product sync", "source": "salsify", "target": "shopify" }, { "capability": "product-syndication", "label": "Product syndication", "source": "salsify", "target": "shopify" } ], "faqs": [ { "q": "How are Salsify Channels and Shopify publications related?", "a": "Each Shopify channel (Online Store, Point of Sale, Hydrogen, etc.) can map to a Salsify Channel if needed. Most merchants publish via a single Shopify-bound Channel; we model multi-channel at scoping where it's needed." }, { "q": "What about variants and Shopify's three-option limit?", "a": "Where Salsify carries more variant axes than Shopify's three-option model allows, we collapse the least-significant axes into metafields. We document the trade-off explicitly so merchandising knows what's going where." }, { "q": "How does this handle Salsify enrichment workflows?", "a": "Salsify's workflow state is the gating signal. Products only publish to Shopify when the relevant readiness state is reached, so partially-enriched records don't leak onto the storefront." }, { "q": "Do you support this under SLA after go-live?", "a": "Yes. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month." } ] }, { "slug": "salsify-to-mirakl", "a": "salsify", "b": "mirakl", "url": "https://www.ecirql.com/integrations/salsify-to-mirakl/", "lead": "Salsify holds the canonical product master data. Mirakl operators each have their own attribute requirements, category trees and listing rules. The integration moves product data from Salsify into Mirakl operators with each operator's specific rules enforced at the boundary so the merchandising team works in one system rather than reconciling spreadsheets per operator. Built and supported as a Patchworks Partner Agency.", "patchworks_angle": "This is one of the integrations Patchworks is best suited to: many-to-many mapping between Salsify's canonical product shape and the per-operator Mirakl requirements. We build operator-aware transforms in Patchworks, each one a versioned canvas, and the merchandising team manages overrides centrally rather than operator-by-operator. Runbooks cover the cases Mirakl's exception reports surface at month-end.", "flow": { "title": "Product sync: Salsify to Mirakl", "description": "Salsify product master data publishes onto each Mirakl operator with the operator-specific attribute set, category and listing rules enforced at the integration boundary.", "steps": [ { "kind": "trigger", "system": "Salsify", "label": "Channel publish", "detail": "per-operator channel" }, { "kind": "extract", "system": "Patchworks", "label": "Ingest product", "detail": "queue, dedupe" }, { "kind": "transform", "system": "Patchworks", "label": "Map to operator", "detail": "attribute set, category, media" }, { "kind": "decision", "system": "Patchworks", "label": "Validates?", "detail": "operator-specific rules" }, { "kind": "action", "system": "Mirakl", "label": "Publish listing", "detail": "OF24, OF25 endpoints" }, { "kind": "writeback", "system": "Salsify", "label": "Mark synced", "detail": "with operator + SKU" } ] }, "timeline": { "weeks": "6 to 10 weeks for a standard delivery", "phases": [ { "label": "Week 1", "detail": "Discovery: operator landscape, attribute mapping, category trees, media." }, { "label": "Weeks 2 to 4", "detail": "Build: per-operator transforms, validation rules, publish flows." }, { "label": "Weeks 5 to 7", "detail": "Integration testing against operator UAT sandboxes." }, { "label": "Weeks 8 to 10", "detail": "Cutover and hyper-care into retainer." } ] }, "capabilities": [ { "capability": "product-sync", "label": "Product sync", "source": "salsify", "target": "mirakl" }, { "capability": "product-syndication", "label": "Product syndication", "source": "salsify", "target": "mirakl" } ], "faqs": [ { "q": "We list on five operators. Does that mean five integrations?", "a": "One integration, five operator transforms. The Patchworks canvases are operator-aware; adding a sixth is a configuration exercise, not a rebuild." }, { "q": "How are operator-specific category trees handled?", "a": "Each operator's category tree maps to Salsify's master taxonomy via per-operator translation tables. Mapping changes happen in one place; downstream operators inherit the updates." }, { "q": "What about operator-specific image and content rules?", "a": "Enforced at the integration boundary. Image dimensions, alt-text length, attribute formatting and content-tag rules are validated before publish; rejected payloads land in a queue for merchandising review rather than blocking the rest of the catalogue." }, { "q": "Do you support this under SLA after go-live?", "a": "Yes. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month." } ] }, { "slug": "shopify-to-channelengine", "a": "shopify", "b": "channelengine", "url": "https://www.ecirql.com/integrations/shopify-to-channelengine/", "lead": "Shopify is the brand storefront. ChannelEngine is the marketplace aggregator: connect once and reach dozens of marketplaces from a single dashboard. Connecting Shopify to ChannelEngine means the catalogue, inventory and pricing publish onto every chosen marketplace under ChannelEngine's operator rules, orders drop back into Shopify for fulfilment, and settlement data ties out against actual gross revenue. Built and supported as a Patchworks Partner Agency, with the SLA picking up at cutover.", "patchworks_angle": "ChannelEngine handles the per-marketplace operator complexity; Patchworks handles the Shopify side of the boundary so merchandising and operations only deal with one source of truth. The integration publishes Shopify catalogue + inventory into ChannelEngine on change, and ingests orders back as Shopify orders with channel attribution preserved. Flows live in Patchworks; runbooks cover the cases ChannelEngine surfaces when an operator changes its rules upstream.", "flow": { "title": "Order sync: ChannelEngine to Shopify", "description": "Orders from any of ChannelEngine's connected marketplaces drop into Shopify with channel attribution preserved so reporting splits out marketplace revenue cleanly.", "steps": [ { "kind": "trigger", "system": "ChannelEngine", "label": "Order created", "detail": "order webhook" }, { "kind": "extract", "system": "Patchworks", "label": "Ingest order", "detail": "queue, dedupe" }, { "kind": "transform", "system": "Patchworks", "label": "Map to Shopify", "detail": "SKUs, channel, customer" }, { "kind": "action", "system": "Shopify", "label": "Create order", "detail": "with marketplace tag" }, { "kind": "action", "system": "Shopify", "label": "Allocate stock", "detail": "against ChannelEngine location" }, { "kind": "writeback", "system": "ChannelEngine", "label": "Acknowledge", "detail": "with Shopify order ID" } ] }, "timeline": { "weeks": "5 to 8 weeks for a standard delivery", "phases": [ { "label": "Week 1", "detail": "Discovery: marketplace scope, catalogue filter, fulfilment SLA model." }, { "label": "Weeks 2 to 4", "detail": "Build: catalogue, inventory, pricing, orders, fulfilment, settlement." }, { "label": "Weeks 5 to 6", "detail": "Integration testing against ChannelEngine sandbox." }, { "label": "Weeks 7 to 8", "detail": "Cutover and hyper-care into retainer." } ] }, "capabilities": [], "faqs": [ { "q": "How does this differ from connecting directly to Amazon or eBay?", "a": "ChannelEngine consolidates dozens of operators behind one connector, which is the right call when you want marketplace breadth without per-operator integration work. For a single high-volume operator (Amazon US, say), a direct integration is sometimes a better fit. We help merchants pick at scoping." }, { "q": "What about per-marketplace SLA requirements?", "a": "ChannelEngine surfaces operator-specific SLA requirements; the integration pushes fulfilment events back within the right windows. The runbook documents what to do if any operator-side SLA looks at risk." }, { "q": "Can we restrict which products publish to which operators?", "a": "Yes. Per-marketplace catalogue filtering happens at the integration boundary; the merchandising team controls eligibility in one place rather than in ChannelEngine and Shopify separately." }, { "q": "Do you support this under SLA after go-live?", "a": "Yes. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month." } ] }, { "slug": "shopify-to-returnless", "a": "shopify", "b": "returnless", "url": "https://www.ecirql.com/integrations/shopify-to-returnless/", "lead": "Shopify holds the order; returnless owns the returns experience: customer-facing portal, label generation, exchange offers, refund logic. Connecting them means returnless authorises returns against real Shopify orders, refunds and exchanges write back as proper Shopify events, and the operations team sees the same return state wherever they look. We design, build and support Shopify-to-returnless integrations as a Patchworks Partner Agency.", "patchworks_angle": "returnless has a native Shopify connector and for many merchants that's the right starting point. Patchworks earns its place when the merchant runs multiple stores into one returnless tenant, needs ERP- or WMS-side awareness of the return alongside Shopify, or has bespoke rules about which orders are returnable. We build those flows in Patchworks and hand over runbooks that cover the edge cases the native connector glosses past.", "flow": { "title": "Returns sync: returnless to Shopify", "description": "A return raised in returnless becomes a structured event against the Shopify order: refund or exchange, the right line items, customer notification, restocking writeback.", "steps": [ { "kind": "trigger", "system": "returnless", "label": "Return raised", "detail": "RMA webhook" }, { "kind": "extract", "system": "Patchworks", "label": "Ingest event", "detail": "queue, dedupe" }, { "kind": "decision", "system": "Patchworks", "label": "Refund or exchange?", "detail": "branch" }, { "kind": "action", "system": "Shopify", "label": "Create return", "detail": "via Admin API" }, { "kind": "action", "system": "Shopify", "label": "Refund / exchange", "detail": "as required" }, { "kind": "writeback", "system": "returnless", "label": "Acknowledge", "detail": "with Shopify return ID" } ] }, "timeline": { "weeks": "3 to 5 weeks for a standard delivery", "phases": [ { "label": "Week 1", "detail": "Discovery: returns policy, RMA workflow, refund vs exchange rules." }, { "label": "Weeks 2 to 3", "detail": "Build: returns ingestion, Shopify writeback, refund logic." }, { "label": "Weeks 4 to 5", "detail": "UAT with operations, cutover, hyper-care into retainer." } ] }, "capabilities": [ { "capability": "order-sync", "label": "Order sync", "source": "shopify", "target": "returnless" }, { "capability": "customer-sync", "label": "Customer sync", "source": "shopify", "target": "returnless" }, { "capability": "returns-sync", "label": "Returns sync", "source": "returnless", "target": "shopify" }, { "capability": "refund-sync", "label": "Refund sync", "source": "returnless", "target": "shopify" } ], "faqs": [ { "q": "Why not use the native returnless app?", "a": "If it does the job, use it. We get the call when merchants run multiple Shopify stores into one returnless tenant, need ERP or WMS visibility on each return alongside Shopify, or have bespoke returnable-order rules." }, { "q": "How are exchanges handled?", "a": "Exchange flows create a structured Shopify return + a draft order for the replacement, linked together so finance can audit the trail. The customer notification flows on returnless's standard cadence." }, { "q": "Can the integration block returns against certain orders?", "a": "Yes. Eligibility rules (final-sale items, beyond-policy-window, gift recipient rules) fire at the integration boundary so returnless's customer-facing portal reflects the merchant's actual policy." }, { "q": "Do you support this under SLA after go-live?", "a": "Yes. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month." } ] }, { "slug": "shopify-to-shipbob", "a": "shopify", "b": "shipbob", "url": "https://www.ecirql.com/integrations/shopify-to-shipbob/", "lead": "Shopify is the storefront. ShipBob is the 3PL: warehouses around the world, two-day delivery promises, and an API surface that rewards integration discipline. Connecting them properly means orders drop into ShipBob for despatch, inventory and tracking flow back so Shopify stays honest, and the operations team sees one fulfilment picture across every region. Built and supported as a Patchworks Partner Agency.", "patchworks_angle": "ShipBob's native Shopify integration is a fine starting point. Patchworks earns its place where the merchant runs multiple Shopify stores into one ShipBob tenant, blends ShipBob with another fulfilment provider for non-US regions, or needs ERP-side awareness of the despatch alongside Shopify. We build those flows in Patchworks; runbooks cover the cases ShipBob's exception reports flag on busy days.", "flow": { "title": "Order sync: Shopify to ShipBob", "description": "Each Shopify order drops into ShipBob for despatch, with tracking and fulfilment events writing back to Shopify on the expected cadence.", "steps": [ { "kind": "trigger", "system": "Shopify", "label": "Order paid", "detail": "orders/paid webhook" }, { "kind": "extract", "system": "Patchworks", "label": "Ingest order", "detail": "queue, dedupe" }, { "kind": "transform", "system": "Patchworks", "label": "Map to ShipBob", "detail": "SKUs, ship-to, service level" }, { "kind": "action", "system": "ShipBob", "label": "Create order", "detail": "for despatch" }, { "kind": "trigger", "system": "ShipBob", "label": "Shipment update", "detail": "tracking + status events" }, { "kind": "writeback", "system": "Shopify", "label": "Fulfil order", "detail": "tracking, carrier" } ] }, "timeline": { "weeks": "3 to 5 weeks for a standard delivery", "phases": [ { "label": "Week 1", "detail": "Discovery: ShipBob warehouse footprint, service-level mapping, exception handling." }, { "label": "Weeks 2 to 3", "detail": "Build: orders, inventory, tracking, returns writeback." }, { "label": "Weeks 4 to 5", "detail": "UAT, cutover, hyper-care into retainer." } ] }, "capabilities": [ { "capability": "order-sync", "label": "Order sync", "source": "shopify", "target": "shipbob" }, { "capability": "inventory-sync", "label": "Inventory sync", "source": "shipbob", "target": "shopify" }, { "capability": "fulfilment-sync", "label": "Fulfilment sync", "source": "shipbob", "target": "shopify" }, { "capability": "tracking-sync", "label": "Tracking sync", "source": "shipbob", "target": "shopify" }, { "capability": "returns-sync", "label": "Returns sync", "source": "shopify", "target": "shipbob" } ], "faqs": [ { "q": "Why not use the native ShipBob Shopify app?", "a": "If it does the job, use it. We get the call when merchants run multiple stores into one ShipBob tenant, blend ShipBob with another 3PL for non-US regions, or need ERP visibility on every despatch alongside Shopify." }, { "q": "How is inventory kept honest across regions?", "a": "ShipBob is the source of truth for sellable stock at each fulfilment centre; Shopify receives location-aware availability so the storefront reflects the regional warehouse split. Safety-stock buffers configure at scoping." }, { "q": "What happens on a missed despatch?", "a": "ShipBob's exception report imports into the runbook; the on-call engineer sees missed orders by reason code and can act before the customer-care side does." }, { "q": "Do you support this under SLA after go-live?", "a": "Yes. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month." } ] }, { "slug": "shopify-to-gxo", "a": "shopify", "b": "gxo", "url": "https://www.ecirql.com/integrations/shopify-to-gxo/", "lead": "Shopify is the storefront. GXO is enterprise-grade contract logistics: warehouses at scale, integrated with their own WMS, with the operational rhythm a large brand expects. Connecting them properly means orders flow to GXO for despatch on the right service level, inventory and tracking writebacks keep Shopify honest, and exception handling is structured rather than ad-hoc. Built and supported as a Patchworks Partner Agency.", "patchworks_angle": "GXO integrations are project-grade: file specifications, structured EDI or API exchanges, formal UAT cycles. Patchworks gives the merchant a controlled boundary between Shopify's event stream and GXO's batch-oriented expectations. Flows live in Patchworks with full audit trail; runbooks cover what to do when a GXO batch lags or rejects, and the on-call engineer sees the picture before customer care does.", "flow": { "title": "Order sync: Shopify to GXO", "description": "Shopify orders flow to GXO on the agreed batch cadence with the right service-level mapping; tracking and fulfilment events write back to Shopify as despatch completes.", "steps": [ { "kind": "trigger", "system": "Shopify", "label": "Order paid", "detail": "orders/paid webhook" }, { "kind": "extract", "system": "Patchworks", "label": "Queue for batch", "detail": "configured cadence" }, { "kind": "transform", "system": "Patchworks", "label": "Map to GXO", "detail": "service level, address, items" }, { "kind": "action", "system": "GXO", "label": "Send batch", "detail": "via API or SFTP" }, { "kind": "trigger", "system": "GXO", "label": "Despatch event", "detail": "tracking + carrier" }, { "kind": "writeback", "system": "Shopify", "label": "Fulfil order", "detail": "tracking, carrier" } ] }, "timeline": { "weeks": "8 to 12 weeks for a standard delivery", "phases": [ { "label": "Week 1 to 2", "detail": "Discovery: GXO spec, file formats, service-level mapping, exception model." }, { "label": "Weeks 3 to 6", "detail": "Build: orders, inventory, despatch, tracking, returns writeback." }, { "label": "Weeks 7 to 9", "detail": "Integration testing through GXO UAT cycles." }, { "label": "Weeks 10 to 12", "detail": "Cutover and hyper-care into retainer." } ] }, "capabilities": [ { "capability": "order-sync", "label": "Order sync", "source": "shopify", "target": "gxo" }, { "capability": "inventory-sync", "label": "Inventory sync", "source": "gxo", "target": "shopify" }, { "capability": "fulfilment-sync", "label": "Fulfilment sync", "source": "gxo", "target": "shopify" }, { "capability": "tracking-sync", "label": "Tracking sync", "source": "gxo", "target": "shopify" }, { "capability": "returns-sync", "label": "Returns sync", "source": "shopify", "target": "gxo" } ], "faqs": [ { "q": "Is this API-based or file-based?", "a": "Either, depending on GXO's contract setup. We've shipped both. The integration approach is the same; only the connector at the GXO end changes. We confirm the interface at discovery." }, { "q": "How is exception handling structured?", "a": "GXO's exception report imports into a structured queue; missed orders, address failures and stock exceptions land in the runbook by reason code so the on-call engineer can act on them before customer care does." }, { "q": "Can we run GXO alongside another fulfilment provider?", "a": "Yes. The Patchworks routing layer decides per-order which provider handles the despatch based on rules (region, service level, SKU eligibility) you set at discovery. Common pattern: GXO for high-volume domestic, alternative provider for outliers." }, { "q": "Do you support this under SLA after go-live?", "a": "Yes. Monitoring on every shipped flow, on-call cover, monthly health checks and tiered response SLAs from £750/month." } ] } ], "audit": { "slug": "integration-audit", "name": "Integration audit", "url": "https://www.ecirql.com/services/integration-audit/", "pricing": [ { "sku": "audit-standard", "name": "Standard integration audit", "fee_gbp": 1500, "duration": "10 working days", "deliverables": [ "PDF report covering flow inventory, failure modes, operational handover quality and cost posture", "Follow-up call (60 minutes) to walk through findings" ], "credit_terms": "Fee credited in full against project work or a support retainer commissioned within 30 days of the report." }, { "sku": "audit-tapestry-to-core", "name": "Patchworks Tapestry to Core migration audit", "fee_gbp": 750, "duration": "10 working days", "deliverables": [ "Scoped specifically for Patchworks Tapestry estates planning migration to Patchworks Core", "PDF report + follow-up call" ], "credit_terms": "Fee credited in full against the subsequent migration engagement." } ], "contact": { "email": "contact@ecirql.com", "form": "https://www.ecirql.com/contact/" } }, "retainers": { "name": "Support retainers", "url": "https://www.ecirql.com/services/support-retainers/", "starting_fee_gbp_per_month": 750, "summary": "Monitored process flows, on-call engineering cover, monthly health checks and a tiered response SLA." }, "contact": { "email": "contact@ecirql.com", "form": "https://www.ecirql.com/contact/", "linkedin": "https://www.linkedin.com/company/ecirql", "ask_endpoint": "https://www.ecirql.com/api/ask", "mcp_endpoint": "https://www.ecirql.com/api/mcp" }, "reference_files": { "llms_txt": "https://www.ecirql.com/llms.txt", "llms_full_txt": "https://www.ecirql.com/llms-full.txt", "agents_md": "https://www.ecirql.com/agents.md", "sitemap": "https://www.ecirql.com/sitemap-index.xml", "agentic_sitemap": "https://www.ecirql.com/sitemap_agentic.xml", "agent_discovery": "https://www.ecirql.com/.well-known/agent-discovery.json" } }