The part nobody quotes for
Product data lives in one system and prices in another. Stock is right on the shop and wrong in the warehouse. Order confirmations come from the platform, abandoned carts from the email tool, and neither knows what the other sent. Refunds never reach the CRM, so lifetime value is fiction.
What we do about it
We treat the store as one system rather than a shopfront with add-ons. Product and order data syncs in a direction you chose deliberately. Fulfilment and post-purchase email run off the same order record. Revenue reconciles against what your finance team sees, so the dashboard and the bank statement agree.
What you get
Included as standard
- Shopify and WooCommerce storefronts, themes and custom blocks
- Product, price and stock synchronisation with your source of truth
- Order, fulfilment and refund flows wired end to end
- Post-purchase, win-back and replenishment sequences on real order data
- Revenue and margin reporting that reconciles with finance
The chain
How the pieces connect
- Product source
- Storefront
- Order
- Fulfilment
- CRM and email
- Revenue reporting
The catalogue needs one home
The most common structural problem in an ecommerce stack is that nobody can say where product data lives. Prices are edited in the storefront, descriptions in a spreadsheet, stock in the warehouse system, and images in a shared drive. Each is authoritative for something and none is authoritative for everything.
The result is predictable. A price is corrected in one place and not another. A product is discontinued in the warehouse and stays purchasable online for a fortnight. Stock says four, the shelf says zero, and a customer finds out after paying.
The fix is to name a single source for each attribute and then enforce it, which is a smaller job than replacing systems and delivers most of the benefit. Sometimes that means a dedicated product information system; more often it means deciding that the ERP owns price and stock, the storefront owns merchandising copy, and the sync runs one way for each. Written down, agreed, and implemented so the wrong system simply cannot write the field.
Orders, fulfilment and refunds are one chain
Order data is where ecommerce reporting quietly breaks, and refunds are almost always the specific point of failure. An order is created, it flows to fulfilment, it appears in analytics and in the email tool. Then it is refunded, and that refund is recorded in exactly one system.
From that moment every downstream number is wrong in the same direction. Revenue only ever goes up. Lifetime value is inflated. A customer who returned everything they ever bought sits in a high-value segment and receives a loyalty campaign.
Treating the chain as one system means the refund is an event with the same status as the purchase, propagated to the same places. It also means partial refunds, exchanges and cancellations each have a defined behaviour rather than being handled ad hoc by whoever is in the admin panel that day.
Post-purchase should run on order data, not an email list
Most post-purchase marketing is built on lists, which is why it so often lands wrongly. A win-back campaign goes to someone who bought last week. A replenishment reminder arrives for a product they returned. A review request goes out before the parcel arrived.
Running these off live order data instead fixes the timing problem structurally rather than through careful list management. Replenishment timing derives from what was bought and its actual consumption period, not a fixed thirty days for everything. Review requests trigger on delivery confirmation rather than on dispatch. Win-back triggers on time since last order relative to that customer normal cadence, which for a monthly buyer is a different number than for an annual one.
This is more work to set up and considerably less work to run, and it stops the recurring embarrassment of a campaign that contradicts what the customer just experienced.
Revenue that reconciles with finance
The test we apply to an ecommerce reporting setup is simple: does the number in the dashboard match the number finance uses, and if not, can you explain the gap in one sentence.
Usually the gap has understandable causes: tax handled differently, shipping included in one figure and not the other, revenue recognised at order in one system and at fulfilment in another, currency converted on different dates, refunds lagging. None of those are wrong individually, and all of them need to be known and documented rather than discovered during a board meeting.
Once the definitions agree, the dashboard becomes something people act on instead of something they argue about, and the marketing team stops having to defend its numbers before it can discuss what they mean.
Before you ask
Questions we get
Shopify or WooCommerce?
Shopify carries less operational burden and fewer decisions, which is usually the right trade for a team without dedicated technical support. WooCommerce gives more control and lower platform fees at the cost of owning updates, hosting and security yourself. The honest answer depends more on who maintains it than on the feature comparison, and if you already run one well, that is normally a stronger argument than anything on a feature list.
Should we go headless?
Usually not, and it is asked for more often than it is needed. Headless is worth it when you genuinely have multiple front ends, unusual performance requirements, or a content model the platform cannot express. It costs you the platform ecosystem, a lot of the built-in functionality, and a permanent development dependency. If the motivation is page speed, there is normally a cheaper answer first.
Do you do the storefront design as well?
We build storefronts, themes and custom blocks, and we work to a design rather than replacing a designer. Where we add most is behind the storefront: the product, order and fulfilment plumbing that determines whether the operation actually works. If you need brand and creative direction, we will say so rather than improvising it.
We sell subscriptions. Does that change things?
Considerably, and mostly in the reporting. Subscription businesses need churn, retention and revenue recognition treated properly, and most default analytics setups quietly report a subscription as a single purchase, which makes lifetime value meaningless. Dunning and failed payment recovery also need to be part of the design rather than left to the platform default.
What breaks first as we grow?
Almost always the manual steps. A process where someone exports orders each morning and uploads them somewhere works fine at twenty orders a day and fails at two hundred, usually silently and usually during a peak. Those steps are worth finding and automating before the volume arrives rather than during it.
Scope, plainly
What this is not
Worth saying before you write, so nobody wastes a fortnight finding out.
- Brand, creative direction or product photography. We build to a design; we do not originate one.
- Paid media and marketplace management. We make the data usable; someone else spends against it.
- Warehouse or logistics operations. We integrate with your systems; we do not run them.
Rarely done alone
What this usually comes with
- Tracking and dashboards Revenue only reconciles once the order chain is right, so these two are usually scoped together.
- Campaigns and automation Post-purchase flows run on the order data this service puts in order.
- Custom development The missing twenty per cent between platforms is normally a small piece of custom middleware.
Also on the chain
Nothing here works alone
Every one of these connects to the others. That is the point of the way we work.
Start with the gap
Tell us where the chain breaks.
One reply from the person who would do the work, not a sales desk.
Tell us about itor write straight to hello@dot-connectors.net