TL;DR — Eight posts from the week on enterprise commerce, all circling the same point: vendors sell capabilities as checkboxes and merchants ship them as contracts. Composable, net terms, single customer view, BOPIS, reorder — the demo is a feature, the production version is an org chart.
The theme
The steering-committee vocabulary of enterprise commerce — composable, unified, single customer view, BOPIS, reorder — survives the vendor deck but rarely survives month six. Not because the platforms are bad. Because each of those words is being asked to stand in for a decision nobody has actually made: who owns the integration tax, who carries the AR risk, which system writes the customer record, which VP signs the pick SLA. The "feature" is always the easy part.
The honest read across this week's eight pieces is that enterprise commerce is mostly a contract problem dressed up as a platform problem. A toggle in an admin UI does not underwrite a credit limit, picking labor does not appear in a storefront changelog, and "integration" and "unification" describe two different architectures no matter how the slide deck merges them. The brands that ship the deck version end up with workarounds. The ones that ship the contract version end up with a working stack that looks boring and compounds.
1. Composable Commerce: The Honest Tradeoffs Nobody Pitches (original)
Overview
Composable commerce is sold to the mid-market the way microservices were sold a decade ago: pick best-of-breed, swap at will, never lock in. What shows up in production is a six-month integration project followed by a permanent four-engineer line item to keep the seams from tearing. The pitch trades platform risk for integration risk, and integration risk compounds. At forty engineers that compounding is rounding error. At a $40M DTC brand with four engineers, it eats the roadmap.
Technical
The cleaner version of the argument anchors composable on a strong base layer — cart, checkout, orders, tax, fraud, payments — and composes only the pieces where best-of-breed moves a number. That is a very different bet from full MACH purism, where you assemble the core itself from separate services behind an orchestration layer. Two brands in the $50–150M band attempted full rebuilds recently — both documented in the composable post-mortems making the rounds, not projects I was inside. One finished in fourteen months and now requires a six-person platform team. The other rolled back to a monolith after seven figures of spend. Both had smart teams. Neither hit the ROI the deck promised. The operating cost of a composable stack never shows up in the original TCO model — it shows up two quarters in, when the first integration breaks during peak and there is no vendor to call.
Takeaway
Before committing, name the specific capability you cannot get from a strong base layer. Model three years of two dedicated platform engineers and add it to TCO. Ask your vendors what happens when an integration breaks on Black Friday and listen for who answers something other than "your team handles it." Composable is the right answer to a real problem, just rarely the problem mid-market brands actually have.
2. Net Terms Without Chargebacks: A B2B Credit Playbook (original)
Overview
Net-30 is not a checkout toggle. It is an unsecured loan with no underwriting, no servicing, and a collections process that lands on an accounting clerk chasing a $4,200 invoice in Ohio. Platforms — Shopify included — increasingly frame terms as a per-company payment method, which is exactly the trap. Clean UX makes a credit decision feel like a feature flag. If you offer terms, you are running a small commercial lending operation. Treat it that way, or hand the paper to Resolve, Balance, or TreviPay and let them carry it.
Technical
A real terms program has four pieces and you need all four. First, underwriting at signup: a D&B Paydex pull or fintech credit check, with a limit set by score and trade references — not by what the buyer asks for. The Shopify B2B admin lets you set per-company terms but does not enforce a credit ceiling that decrements as orders ship; you build that with a metafield and a Function, or you bolt on a credit-as-a-service vendor. Second, dynamic limits that grow with on-time payers and shrink with slow payers automatically, wired to AR aging. Third, reconciliation through a real AR system — Versapay, BillTrust, HighRadius, or a NetSuite connector — because the commerce platform is not your AR system and trying to make it one is how invoices go missing. Fourth, a written collections playbook with automated escalations at day 30, 45, 60, 75, 90.
Takeaway
Monday: write the one-page credit policy, decide whether you are carrying paper or outsourcing it, and build the AR aging job that gates new orders against open balance — even if v1 is a spreadsheet updated daily. Cleaning this up after a $200K writeoff is ten times more painful than laying the rails before the first invoice.
3. The Single Customer View Lie Most Stacks Tell (original)
Overview
Every unified commerce pitch opens on a clean circle with channels feeding in and marketing flowing out. Six months later the email team is deduplicating profiles by hand because the POS writes guest checkouts as new records, loyalty has its own ID space, and the site issues anonymous cookies that only stitch at logged-in checkout. The "single" view is four views joined nightly by a Python notebook owned by one analyst who is about to quit. The operational definition of SCV is narrow: one ID every system agrees on, one row that is the durable source of truth. Anything else is a join.
Technical
Three failure modes repeat. ID collision at the POS: a phone-only record from an in-store guest checkout and a logged-in online profile with the same phone formatted differently, which the CDP cannot deterministically match and which loyalty refuses to migrate points across. Latency lies: a CRM showing an LTV from last night's warehouse job while the customer just dropped $4,000 in-store two hours ago. Conflict resolution nobody wrote down: Mike vs Michael vs Mick, and whichever system wrote last wins the holiday campaign greeting. The vendor playbook — buy a CDP, point sources at it, configure resolution — only works if the CDP also writes back to source systems or if source systems read from it at runtime. Almost nobody does either, so the CDP becomes a read-only reporting layer that drifts within hours. Unification means one writer, everyone else reads, sub-second.
Takeaway
Pick a customer from your top decile. Screenshot their profile in every system that touches them. Put the screenshots side by side. Ask one question: which of these is the truth? The fight that follows is the actual unified commerce roadmap. Skip the project until you have had it.
4. Catalog Rules for Multi-Account B2B Buyers, Done Right (original)
Overview
The DTC-to-wholesale mistake is treating a catalog as one list with a wholesale price metafield gated by customer tag. Six months in one account wants private SKUs, another has negotiated early access to the fall line, a third refuses to see men's categories. The one-catalog-many-discounts model collapses. What you need is a rules engine where each buyer's catalog is computed from policy — tier, region, category, launch window — not stored as a static list. Design for rules from day one, even at two accounts.
Technical
Shopify B2B gives you the bones: catalogs as first-class objects, price lists per catalog, visibility per company location. The platform deliberately leaves composition to you. A B2B account has three layers — parent company, locations, buyer users — and catalog assignment matters at each. Encode tier, region, and category permission as metafields on the company and as tags on the catalog. A webhook on company update re-binds the company to the right catalog. Promoting a buyer from silver to gold touches no catalogs. Private SKUs are uglier: create them as regular products filtered by a Shopify Function reading a "private to company X" metafield — the filter must be applied everywhere including search index and recommenders, but at least the rule lives at the platform level instead of in theme code. Per-account launch windows get modeled as an early_access_date product metafield compared to an early_access_tier company metafield inside a Function. Brittle, but workable.
Takeaway
Do not start in the admin UI. Start in a spreadsheet. Accounts down rows, axes across columns. Wherever a value repeats twenty times, you have found a rule. Encode the rule, not the result. Wire a derivation job so catalog assignment is computed, not hand-set by the rep who closed the deal.
5. Integration Is Not Unification, and Your Stack Knows It (original)
Overview
"We already do unified commerce, we just call it differently" usually means an iPaaS, nightly batch jobs, and a Slack channel where ops fights data eng. That is integration. It is a legitimate architecture for some businesses. It is not unification. The in-between state — where leadership thinks they bought unification and engineering shipped integration — is where the tax gets paid without the simplicity of either extreme.
Technical
Four telltales separate the two. Reconciliation job count: a unified stack has zero jobs to make inventory match itself, because there is only one inventory record. Source-of-truth diagram: draw orders, inventory, customers, pricing. If any box has arrows going in multiple directions, or the answer is "depends on which channel," it is integration. Mean time to reflect a price change across web, app, POS, marketplace, ads feed: integrated stacks measure in hours, unified stacks in seconds. Cost of adding a channel: a new connector plus a reconciliation job plus a monitoring alert plus an on-call rotation means integration; "configure the storefront, point it at the existing data layer" means unification. Integration is the right answer when channels are genuinely independent — different brands, different markets, different fulfillment — and an OMS-as-aggregator pattern works when you commit to it. The failure mode is the OMS that is trying to be a CDP that is trying to be an inventory master that is trying to be a pricing engine and doing none of those four well.
Takeaway
Run the four telltales next sprint. If three come back integrated, stop calling it unified in decks. Either commit to integration with eyes open and budget the tax, or commit to real unification and pick which system wins. The half-step is where money goes to die.
6. Replatforming Fears vs Reality: What Actually Breaks at Month Six (original)
Overview
Every replatform kickoff names the same fears: data loss, SEO collapse, cutover downtime, payment compatibility, the legacy ERP integration. Those are real and every consultancy has a playbook for them. They almost never break the project. What breaks it is the merchandising lead's quiet refusal to learn the new admin, the ops manager with a personal Excel layer on top of the old order export, the CMO deciding at month four that the new PDP "doesn't feel like us," and the senior engineer who quits because their three-year migration is now two of someone else's tickets.
Technical
The actually-breaks list, ranked by frequency: merchandising revolts because the new workflow takes nine clicks instead of six and the team starts shadow-using the old admin. A single integration nobody owned — usually a 2021 Zapier flow powering a $400K B2B reorder — blows up at cutover. The CMO triggers a brand refresh mid-project; nothing dies faster than a project with two missions. Historical revenue reports stop matching because the new platform sums returns differently and finance loses trust in the dashboard with nobody free to reconcile. A senior engineer quits at month four carrying institutional knowledge nobody documented. The pattern worth naming: most replatform failures become visible at month six, not month one. Month one is the honeymoon. Month three is the first real production load. Month six is when operating cadence settles and the team realizes how much friction was added to their daily work.
Takeaway
Build a workarounds tracker and review it weekly. Every shadow spreadsheet, every "I just export it manually," every Slack thread where someone is hand-fixing what the platform should automate. By month three the pile predicts month-six survival. The brands that ship replatforms are the ones whose merchandising leads were in the room from week one and had veto power over workflow changes.
7. BOPIS Is an Ops Contract, Not a Storefront Feature (original)
Overview
Every retailer ships BOPIS thinking they are shipping a customer feature — PDP changes, order routing, pickup emails, press release. Eight weeks later half the orders go unpicked, ready-for-pickup emails fire for items not on the floor, and store managers are quietly blocking BOPIS in their POS because it is tanking their hourly metrics. The digital team did everything right from the digital perspective. Store ops was not in the meetings. BOPIS is not a feature. It is a contract between e-commerce, store ops, and inventory accuracy.
Technical
Four things have to be true before the button on the PDP means anything. SKU-by-store inventory accuracy above 97%, measured by physical audit, not system count. Most retailers have that at the warehouse; very few have it for the long tail at the store level, which is exactly where BOPIS demand concentrates. Pick labor in the store schedule, not bolted on: 50 BOPIS orders a day is 4–7 hours of labor, and if it is not budgeted the store manager will deprioritize and the queue will silently stall. Pickup handoff designed for the actual store layout, where the counter is six feet from returns and the 4pm price-check stack, which means BOPIS customers wait 12 minutes for a 30-second handoff. Cancellation handling that refunds instantly, notifies instantly, and updates store inventory immediately — most stacks fail at least one of the three, and a bad cancellation costs you the customer's next two purchases.
Takeaway
Get the digital VP and the store ops VP in a room and make them sign a one-page contract: pick SLA, inventory audit cadence, labor allocation, cancellation policy. Then look at SKU-by-store accuracy for your top 500 SKUs in your top 50 stores. If it is below 97%, BOPIS becomes an inventory project for two quarters before anything ships customer-facing. That feels like a delay. It is the only way to ship BOPIS that does not burn customers.
8. B2B Reorder UX That Actually Ships, Not the Demo Version (original)
Overview
DTC obsesses over first-purchase conversion because the average lifetime is two orders. B2B should obsess over reorder because the average lifetime is forty. A monthly wholesale buyer over two years is worth more than a thousand DTC buyers, and the only thing between you and that revenue is whether the fourteenth order is faster than emailing the sales rep a spreadsheet. Most B2B portals are built by people who have never watched a buyer reorder — beautiful product grid, category nav, hero banner, Amazon-ish search — while the buyer sighs and pastes a SKU list one at a time.
Technical
A reorder flow that actually works has four pieces. A persistent editable reorder list with quantities pre-populated from typical patterns, shown on login instead of a marketing banner, one button to place the order. Paste-to-cart: a textarea that accepts "SKU123 x 12, SKU456 x 6" or a CSV and resolves into a cart, with fuzzy SKU matching, validation errors, partial-failure handling, and an opinion about what to do with out-of-stock lines. One-click order-history-to-cart with pagination, search-within-order, and line-level omit so a 200-line order is workable. Scheduled reorders with real B2B gating around credit, terms, PO capture, and per-occurrence quantity edits — which is where DTC subscription primitives start to creak and you end up writing the layer yourself. Search should weight SKU matches absurdly higher than names; a B2B search for BL-001-XL-NAVY wants that SKU and nothing else, bypassing the recommender entirely. Mobile matters because the buyer at the warehouse counter is on a 5-inch screen counting boxes.
Takeaway
This week, log in as one of your top ten buyers and time placing an order from scratch. If it takes more than 90 seconds for a buyer who knows what they want, the reorder UX is broken. Almost all the time will have gone to navigation, not deciding. Fix that — paste-to-cart, persistent list, one-click history reorder — before you ship another personalization feature or homepage refresh. A 5% improvement in reorder cadence on a top-ten account beats a year of homepage CRO.
Original sources
- Composable Commerce: The Honest Tradeoffs Nobody Pitches — originally published 2026-01-17
- Net Terms Without Chargebacks: A B2B Credit Playbook — originally published 2026-01-18
- The Single Customer View Lie Most Stacks Tell — originally published 2026-01-19
- Catalog Rules for Multi-Account B2B Buyers, Done Right — originally published 2026-01-20
- Integration Is Not Unification, and Your Stack Knows It — originally published 2026-01-21
- Replatforming Fears vs Reality: What Actually Breaks at Month Six — originally published 2026-01-23
- BOPIS Is an Ops Contract, Not a Storefront Feature — originally published 2026-01-24
- B2B Reorder UX That Actually Ships, Not the Demo Version — originally published 2026-01-25
