DEV Community: WESWOO

Building a Shopify B2B Store: Company Accounts, Contextual Pricing and ERP Order Flow

WESWOO — Thu, 08 Oct 2026 12:30:04 +0000

A wholesale storefront can look deceptively simple: authenticate a buyer, show a negotiated price, accept an order, and send it to fulfillment. The hard part is preserving the business context at every step. A person may buy for one branch today and another tomorrow; one company may have separate tax settings, shipping addresses, payment terms, and product access by location. The price on screen must match the order record, and the order handed to an ERP must remain traceable if a network call fails.

This guide uses a hypothetical outdoor-supply brand that sells to consumers and to wholesale retailers with several branches. The example is illustrative, not a customer deployment or a claim about results.

01 | Start with the current plan capability, not the plan label

Shopify B2B is available on Basic, Grow, Advanced, and Shopify Plus. Features depend on plan, configuration, or rollout status, so check the live store’s plan, API version, and admin controls before designing around a capability. The B2B features by plan and B2B requirements and considerations are good starting points.

One concrete catalog limit affects early modeling: on Basic, Grow, and Advanced, a store can assign up to three active catalogs across all B2B markets combined. That is a store-wide limit, not three per market. Direct catalog assignment to a company location is a Plus capability. A store that can express its initial tiers with a small set of market catalogs may not need location-specific assignment on day one; a business whose branches need individual assortments or negotiated prices should model that requirement and confirm plan fit before implementation.

Source: Shopify Help Center

02 | Model the company, location, and contact separately

Use the structure that reflects the commercial relationship. The company is the parent organization. A company location is the buying context for a B2B transaction. A customer is the human contact who signs in and acts for the business. Shopify describes locations as independently configurable for details such as shipping and billing addresses, tax settings, pricing, payment terms, checkout settings, and contacts; the company and customer guide explains the roles, and the CompanyLocation API object documents the transaction context.

For the hypothetical outdoor supplier, “North Ridge Outfitters” could be one company with separate city branches. Each branch may need its own ship-to address, tax treatment, and terms. A purchasing manager can be a contact with permission to buy for one or more assigned locations. Do not treat the contact’s email or customer ID as the company identity. On sign-in, the experience must resolve which company location the buyer is acting for and show a clear way to switch when the contact is authorized at multiple branches.

Before importing records, agree on source-of-truth identifiers for company, location, contact, address, and tax registration. Decide how duplicates, renamed branches, closed locations, and staff turnover will be handled. Activate new customer accounts for B2B: Shopify’s current requirements say legacy customer accounts cannot be used for B2B orders and customers.

03 | Choose a blended or dedicated storefront deliberately

A blended store shares one online store for retail and wholesale buyers, while presenting a different contextual experience where supported. It can reduce duplicated merchandising and brand work when retail and wholesale share products, content, and operational ownership. But the team must check which content, discounts, payment options, apps, and checkout customizations can distinguish the two audiences. Shopify’s store-type guidance and its compatibility notes should be reviewed against the current configuration.

A dedicated B2B store can make sense when wholesale has a distinct assortment, commercial language, navigation, or operating team.

Use a decision workshop to map real buyer journeys rather than choosing by URL preference. Can the retailer find case packs, technical documents, reorder tools, and account terms? Can a retail customer avoid seeing wholesale-only products and prices?

Source: Shopify Help Center

04 | Design catalogs and pricing around overlap

Start with a product-access matrix. Rows are products or variants; columns are retail, wholesale tiers, markets, and any company locations that require exceptions. For each cell, record whether the item is visible, its intended price source, minimum or maximum quantity rules, increments, volume breaks, currency, and effective date.

Shopify catalogs can control product availability and pricing, with price adjustments or fixed prices, and can support quantity rules and volume pricing. See Shopify’s catalog documentation. Basic, Grow, and Advanced can assign up to three active catalogs across B2B markets total; Plus also allows direct company-location assignment.

When a location receives both market and location catalogs, Shopify’s documented pricing behavior depends on that relationship; the more specific company-location catalog can determine the displayed item price in an overlap. Multiple catalogs assigned at the same level have their own rules. Do not reduce this to a universal “lowest price wins” assumption. Review the current catalog rules, then verify the rendered price and checkout line for each relevant overlap in the store’s actual setup.

The hypothetical supplier might sell a tent as a retail unit and to a retailer in case packs. If the example uses order increments of six or twenty-four, label them as that supplier’s hypothetical commercial rules, not general Shopify defaults. Decide how pack quantity is represented in the product model, how inventory is counted, and whether the ERP expects eaches or cases. Keep the source of each price and quantity rule legible to merchants so a commercial exception can be reviewed instead of hidden in theme code.

05 | Design the procurement UI in Figma around states

A polished catalog screen is only one state in a purchasing workflow. In Figma, map the decision points: signed out, account pending, signed in without an assigned location, one location selected, multiple locations available, no catalog match, restricted item, quantity below minimum, valid quantity, unavailable inventory, draft submitted, and order confirmed. Add responsive layouts, keyboard focus, validation errors, empty states, and loading or retry behavior for integrations that inform availability.

Make the buying context visible near the page title and cart: company name, selected location, currency, and any relevant order constraints. Give buyers a deliberate location switch and confirm that changing it refreshes prices, product availability, shipping, and terms. Do not use a generic “Wholesale” badge as a substitute for showing which branch is buying. Where the design includes a contract price, show unit and extended totals consistently and explain pack sizing in the product’s own commercial language.

Create a clickable prototype for the whole journey and annotate which values are native Shopify data, theme presentation, an extension, or external ERP/WMS data. That boundary matters when the design is implemented. WESWOO’s brand and Figma design work can align procurement screens with the retail identity while making account context and purchasing rules easy to scan.

06 | Keep Liquid or headless presentation context-aware

A Liquid storefront can use Shopify’s native theme and customer context, with targeted templates and sections for B2B purchasing. Keep business rules in Shopify’s supported configuration or integration layer where possible; avoid burying price entitlement or company identity in fragile client-side checks.

A headless storefront offers greater control over the buyer experience and can fit a broader digital platform, but it also means the implementation team owns more of the account journey, data fetching, cache behavior, and integration testing. Make sure the storefront preserves company-location context through product discovery, cart, checkout handoff, and order confirmation. Authentication alone is not enough; the active purchasing location must be part of the request and state model.

Document the boundary: Shopify is authoritative for the B2B transaction and catalog behavior it manages; an ERP may own customer numbers, credit status, or product master data; a WMS may own fulfillment availability. Define which system wins when updates arrive out of order. Shopify’s B2B APIs support app-based catalog management, but API access, scopes, version, and plan-dependent operations need to be verified in the target store. Liquid or headless, use contract tests around context selection and inspect the final cart and order rather than trusting a product-page mock.

Source: Shopify Help Center

07 | Separate merchant review from buyer-side approval

An order submitted as a draft for review is a merchant-side workflow. Shopify lets a merchant require B2B orders to be submitted as drafts by company location, so the merchant can review or change an order before confirming it. It does not by itself create an arbitrary internal approval chain in which one buyer submits and another buyer at the customer’s company approves. The B2B feature overview describes draft submission as merchant review.

If the retailer needs buyer-side controls—such as spend limits, department approval, or a second approver—write that workflow separately. Determine whether an existing procurement or ERP system owns it, whether an app covers the requirement, or whether custom development is justified.

Payment terms are another separate dimension. Assign terms by company location where the commercial agreement requires it, and confirm what the buyer sees at checkout and on the resulting order. A draft awaiting merchant review should not look like a confirmed order or imply that credit approval has happened. In the interface, use distinct statuses and clear next steps for “submitted for merchant review,” “awaiting buyer approval” if a separate workflow exists, “confirmed,” and “payment due.”

08 | Map ERP order flow, retries, and reconciliation

Before connecting systems, draw the data contract. Map Shopify company and location IDs to ERP customer and ship-to codes; map variant IDs and SKUs to ERP item identifiers; and agree how tax, currency, PO number, discounts, freight, payment terms, and fulfillment status are represented. Store cross-system identifiers in stable fields and record the source of truth for each. Validate addresses and item mappings before an order becomes eligible for export.

Treat the integration as a state machine, not a one-time webhook. An order can be created, held for merchant review, confirmed, partially fulfilled, canceled, or updated. Define which states the ERP should receive and when. Make the application idempotent: receiving the same event again should not create a second ERP order. Use a durable queue or equivalent retry mechanism, bounded backoff, and a dead-letter path for cases that need human repair. Do not report success until the ERP acknowledges the mapped order.

Plan reconciliation in both directions. Agree how manual edits, returns, partial shipment, and cancellation propagate. Shopify supports integrations with ERP and other systems, but the connector’s behavior depends on the mapped systems and design; the B2B integration guidance is a starting point, not an API guarantee. WESWOO’s Shopify development and ERP/WMS integration work should make these ownership and recovery rules explicit before the first pilot order.

09 | Validate with an acceptance matrix and staged pilot

Build a matrix that crosses buyer identity, company location, catalog overlap, payment terms, inventory state, and order outcome. Include at least one retail user, one wholesale user with one location, and one contact authorized for multiple locations. Test a correct price, a location-specific exception, a product excluded from a catalog, and a quantity-rule boundary. Verify the account must use new customer accounts, and test invitation, login, recovery, and permissions.

For every case, inspect three views: what the buyer sees, what Shopify stores on the cart or order, and what the ERP/WMS receives. Confirm company location, line prices, quantities, PO number, addresses, tax treatment, and terms at each boundary. Exercise retries by replaying an integration event in a controlled environment; confirm duplicate delivery does not create duplicate ERP orders. Test a deliberately invalid SKU or address and verify that it enters a visible repair path instead of disappearing.

Run a pilot with a small set of consenting wholesale accounts and a representative order mix. Expand only after the business owner, operations team, and technical team agree that the acceptance cases pass and unresolved exceptions have clear owners.

10 | Make the implementation fit the operating model

A successful B2B storefront connects brand expression to commercial operations. WESWOO can bring together Shopify B2B planning, brand and Figma design, Liquid or headless development, Plus capability assessment when the requirements call for it, ERP/WMS integration, and testing for an incremental release. The starting point is a documented model of companies, locations, contacts, catalogs, approvals, payment terms, and order states, checked against the current Shopify store and the systems that will exchange data with it.

For the hypothetical outdoor-supply brand, that means the buyer knows which branch is purchasing, sees the catalog and terms intended for that branch, and can place an order whose identifiers and commercial details remain consistent through ERP and warehouse processing. The practical deliverables are a capability and data map, a blended-versus-dedicated recommendation, a pricing and product-access matrix, a Figma procurement prototype, a storefront implementation plan, integration contracts, and an acceptance and pilot checklist.

No single plan tier or architecture is right for every wholesaler. Start with the buyer and operations workflows, verify current Shopify capabilities, and make every system boundary testable. To discuss a Shopify B2B build or integration plan, visit WESWOO.

Written with AI assistance and reviewed against the linked primary sources. Screenshots are excerpts from official Shopify Help Center documentation and are included for technical discussion. Sources are identified in each image caption.

Ecommerce GEO on Shopify: Validate Product Data, AI Citations and Checkout

WESWOO — Thu, 08 Oct 2026 08:34:40 +0000

When a shopper asks an AI assistant for a desk that fits a small room, supports a dual-monitor setup, and ships to Germany, a brand needs more than a mention. The recommendation needs a foundation: dimensions, installation conditions, the right product version, local pricing, delivery eligibility, and a clear returns process.

A journey remains incomplete if the assistant cites an old specification, the landing page shows a different price, or the shopper discovers a delivery restriction only after choosing a colour.

For an ecommerce website, generative engine optimization (GEO) can become a practical implementation process: make the intended public information discoverable, make product facts understandable, support buying advice with evidence, and connect the resulting demand to a working purchase or enquiry journey.

At WESWOO, we approach this through the work a Shopify project actually requires: information architecture in Figma, product fields in Liquid or a headless frontend, consistency between the storefront and commerce systems, and evidence for release acceptance. The following framework brings those responsibilities together.

01 | Diagnose the discovery route before choosing the fix

A page being cited in an AI answer and a product appearing in an AI shopping channel are different outcomes. They can overlap, but they depend on different inputs and need separate verification.

Route	What to inspect	Evidence to retain
Public-web retrieval and answers	Access to product, category, guide, and policy pages; readable content and supporting sources	Page checks, indexing observations, answer captures, and cited URLs
Product catalogs and shopping channels	Product fields, variant grouping, catalog mappings, channel eligibility, and available markets	Mapping records, catalog checks, channel status, and purchase-path tests

Google states that AI Overviews and AI Mode use the foundations of Search and do not require special structured-data markup. Crawlability, indexing, useful text, and consistent information therefore remain implementation priorities. Google's AI features guidance

Shopify has both a Catalog route and public-web discovery routes. Allowing a crawler does not establish eligibility for a particular shopping channel. Changing robots.txt does not disable an activated Catalog distribution route. Shopify product discovery guidance

The first deliverable should identify the target market, the AI experience being observed, the desired outcome, and the current failure point. A record that says only “plugin installed” cannot answer those questions.

02 | Establish product facts before rewriting the page

Consider a hypothetical modular-desk brand, used here as a planning example rather than a customer case. It sells two desktop widths, several finishes, and separate accessories to buyers in the United States and Germany. An external system participates in inventory management.

“Suitable for home offices” cannot resolve a monitor-arm compatibility question. “Worldwide delivery” cannot establish whether a particular configuration can reach a German address. Those questions need explicit facts, conditions, and ownership.

Start with representative products and variants that are likely to expose errors, then build a product fact register.

Information	What must be clear	Where to maintain or reconcile it
Product identity	Brand, model, product and variant IDs, SKU	Shopify records and external-system mappings
Selection conditions	Dimensions, installation conditions, accessory compatibility, measurement method	Product fields, technical documents, and visible copy
Versions	Which choices are variants and which items are separate accessories	Product structure, selectors, and catalog grouping
Commercial terms	Market price, currency, promotion scope, sellable state	Market configuration, catalog, and checkout
Delivery commitments	Eligible destinations, inventory location, lead-time conditions and exceptions	Inventory, shipping rules, and policy content
Evidence and ownership	Approved source, applicable version, update date, responsible person	Content records and change log

Assign a source of truth for price and stock, and an approved source for specifications and compatibility. If an ERP holds the dimensions but an editor changes only the text embedded in a page image, other outputs may retain the old value. The repair needs to address data flow, failure detection, and responsibility.

Stores using metafields or metaobjects for descriptions or categories should also inspect the source actually used by Catalog. Shopify Catalog Mapping supports configuring those sources. Its preview is not an exact representation of an AI channel's final display, and changes can take time to process. Shopify Catalog Mapping documentation

Verify the same product, variant, and market across each output. “The field exists,” “the page displays it,” and “the catalog receives it” are three separate checks.

03 | Turn buying questions into product-page hierarchy

Product-page design determines whether buyers can understand these facts. During WESWOO's brand and Figma work, the information can be organized into four layers before the visual treatment and interactions are finalized.

Product and fit. Place the current model, meaningful differences, and applicable use conditions near the title and selectors. A buyer should be able to find dimensions without first reading the brand's entire story.

Selection evidence. Explain the two desktop widths with actual measurements, diagrams, and readable copy. Images communicate spatial relationships; text supplies units, conditions, and limitations. A photograph showing a monitor arm should be accompanied by the installation conditions the buyer must verify.

Supporting evidence. A measurement needs its method. A test conclusion needs its conditions. Customer feedback needs its real source. Manufacturer statements, independent tests, and user reviews can all help, provided readers can distinguish who supplied each conclusion.

Commercial commitments. The selected version's price, availability, delivery conditions, and returns information should appear along the decision path. Bulk purchases and special delivery requirements need suitable enquiry routes.

The Figma specification should cover mobile layouts, long titles, unavailable variants, selection changes, restricted delivery, and enquiry states. When a finish becomes unavailable, does an old “ready to ship” message remain? This kind of state omission harms both shopping clarity and information consistency.

A useful acceptance question is whether the page lets a buyer determine product fit, choose the right version, and decide whether to purchase or contact sales.

04 | Verify what the website actually exposes

Development acceptance should cover both visible content and data outputs. The checks below are implementation recommendations, not a formula for third-party model rankings.

Select a sample covering a main product page, an unavailable variant, a target-market version, a category, a buying guide, and a policy page. Check HTTP responses, indexing directives, canonical URLs, internal links, and essential copy. Keep the inspection results. If a retrieval system encounters an access screen, an error, or another language version, the content project has a technical dependency to resolve.

For Liquid themes, inspect the relationship between components, app scripts, and product fields. For Hydrogen or another custom frontend, compare server responses, browser-rendered content, and the version accessible through search inspection tools. A page displaying correctly in the team's browser proves only one part of that chain.

Then verify the facts in structured data. Google's merchant guidance covers Product and Offer information, while its variant guidance provides ProductGroup-based grouping approaches. Choose an implementation that matches the actual product and URL structure. Google merchant listing documentation, product variant documentation

Common implementation risks include conflicting outputs from a theme and an app, local prices paired with default-market markup, availability that fails to update, and variant links that open a different selection. They are worth checking explicitly rather than treating a successful validator run as the entire acceptance process.

Retain a page–variant–market–output comparison. A structured-data test is evidence that an implementation was checked. Search presentation and AI citation are separate observations.

05 | Build evidence around purchasing decisions

Once product facts are organized, identify questions that the product page alone cannot answer. Customer support, sales, and returns records are useful starting points for a content plan.

For the desk brand, three groups could shape the first content batch:

Selection: How should a buyer choose between desktop widths? What must be measured before fitting a monitor arm?
Conditions: What clearance does installation require? Which conditions affect delivery to a particular region?
Risk: What happens if an accessory is incompatible? How do transit damage and an ordinary return differ?

Each article should have someone who can verify it. Product staff approve specifications; operations check shipping conditions; installation guidance identifies the applicable model and revision. Those details give readers something more useful than an unsupported claim of expertise.

Comparisons also need stated dimensions. Comparing the brand's own models by footprint, installation, and purchase conditions can be useful. Comparisons with other brands need current sources and product versions.

Connect the content to a usable reading journey. A selection guide should lead to the relevant category or product. A product page should expose installation and policy information. Technical documents need a stable entry point. When a model changes, the team should be able to identify the guides and accessory explanations affected by that change.

For multilingual stores, manage terminology and units alongside market conditions. Converting centimetres to inches does not complete localization: delivery promises, pricing context, and the buyer's decision vocabulary also need review. Designers, editors, and developers should work from the same fact register.

06 | Inspect native agent discovery before customizing files

Some GEO projects make llms.txt their central deliverable. On Shopify, inspecting existing platform capabilities should come first.

Shopify currently provides a managed agents.md file, with llms.txt and llms-full.txt mirroring its content by default. The developer guidance recommends the managed version for most stores. A custom template transfers ongoing maintenance responsibility to the merchant's team. Shopify agents.md documentation

A discovery document can describe commerce capabilities and entry points. It does not replace accurate product data, usable pages, or complete policies. A manually maintained summary can introduce another inconsistency if the store changes and the file does not.

Capture the default response and identify a genuine requirement before customizing. Record an owner and the conditions that trigger reinspection, such as a theme change, domain change, or adjustment to commerce capabilities. Whether a particular AI system retrieves and uses the file should be established from available access evidence or platform documentation.

07 | Carry the original demand into a working transaction

A GEO project needs to follow the shopper beyond an answer capture. The website should continue the decision that brought the person there.

If a recommendation points to one desk width, the landing page should make the current model clear. If the question includes delivery to Germany, the relevant market's language, price, stock, and delivery conditions should remain verifiable. A bulk procurement enquiry should enter the appropriate sales process.

Create repeatable journey tests: open the intended landing page, select a variant, verify price and availability, enter the cart, and inspect delivery and payment. For enquiry-based purchases, test the form, model information, target market, and sales follow-up state. Clearly identify test environments or authorized test orders so they do not enter growth reports as new sales.

In an ERP or WMS integration, stock and price changes need timestamps and visible exception handling. Orders and fulfillment need reconciliation. More incoming demand otherwise exposes the same operational inconsistency to more shoppers.

WESWOO can inspect information architecture, theme implementation, and system interfaces along this shared journey. Designers see the states they must communicate, developers see the field sources, and operations know which step owns an exception.

08 | Separate citations, visits, and commercial outcomes

A single AI visibility score can obscure the questions an ecommerce team needs to answer. A layered record is more useful.

Layer	What to record	What it establishes
Implementation	Field completeness, page inspection, catalog mapping, transaction tests	Whether agreed changes were completed and checked
Answer observations	Brand mentions, source URLs, and factual accuracy under a fixed question set	Presentation and citation in sampled conditions
Website behavior	Identifiable referrals, landing pages, selection activity, cart actions, valid enquiries	Observable demand and on-site actions
Commercial results	Paid orders, qualified opportunities, refunds, fulfillment	Transaction and sales-follow-up outcomes

For example, Bing's AI Performance reports citation activity and cited pages. Microsoft explicitly says these measures do not establish rankings or a page's importance within an individual answer. Other platforms need their own recorded definitions. Microsoft's AI Performance explanation

Build a question set around real buying decisions. Keep the platform, market, language, wording, and observation conditions consistent. Save a baseline before the release and repeat the checks at agreed review points. A factual error matters as much as a missing brand mention.

Where AI referral traffic is identifiable, follow the landing page and commercial actions. Check source classification, consent, cross-domain behavior, and returning visits before interpreting the result. Unknown-source visits should remain unknown. Changes in direct traffic or brand searches can support investigation, but cannot independently prove AI attribution.

Distinguish changes the team implemented, changes observed on an external platform, and business changes that cannot yet be attributed. If advertising, prices, and promotions changed during the same period, record them. An increase in orders alone cannot isolate GEO's contribution.

09 | Organize the work into verifiable deliverables

A WESWOO Shopify project can connect five deliverables:

Diagnosis and baseline: Target markets, buying questions, page samples, and failure points across Catalog and the public web.
Product and content specification: Field ownership, variant relationships, market conditions, evidence, and update responsibility.
Design and development package: Figma hierarchy and states, Liquid or headless components, structured data, and actual field mappings.
Release acceptance package: Page checks, catalog reinspection, purchase or enquiry tests, version records, and rollback procedures.
Observation and iteration log: Citations, referrals, valid enquiries, and orders recorded separately, with the next change justified by evidence.

Scope should follow diagnosis. One store may have a custom description missing from Catalog. Another may keep essential specifications only in images. A third may already receive citations but lose qualified demand through market-specific delivery or purchase problems. They need different combinations of content, design, development, and operations work.

WESWOO brings brand design and Shopify implementation together around those failure points: turn buying questions into page structure, connect that structure to maintainable data and components, and retain evidence that the release works. Third-party platforms determine their own answers; the project remains accountable for its agreed diagnosis, implementation, and acceptance work.

Start with representative products

A useful first scope can be small: one important market, representative products, and a set of real buying questions. Verify whether the facts agree, the pages answer those questions, and the transaction works. Use that evidence to decide how far the next iteration should extend.

Sources checked on October 8, 2026. The desk brand and workflow are illustrative. Platform capabilities and eligibility should be checked against current official documentation and the store's actual configuration.

Written with AI assistance and reviewed against the linked primary sources. Screenshots are official documentation excerpts used for technical discussion.

Integrating Jev with Shopify: A Practical AI Shopping Architecture

WESWOO — Tue, 22 Sep 2026 07:26:52 +0000

Most shoppers do not begin with a SKU. They begin with a constraint: “I need a dual-monitor arm for a shallow desk, and I cannot drill holes.” A useful shopping assistant must turn that request into a checkable product choice, then connect the choice to a real Shopify cart.

This article proposes an implementation for Shopify developers. The monitor-arm examples are hypothetical, not a live customer project. Images are excerpts from TypeSafe's official pages, included for technical analysis. This article was written with AI assistance and checked against the linked documentation.

What Jev should do in the stack

Jev is presented by TypeSafe as an early-access decision component for structured judgments. Its documentation describes three primitives: Choice selects from defined options, Score assigns a score, and Noul returns a 0–1 judgment for a statement. Choice and Score also return probability distributions and confidence. See the TypeSafe introduction.

That output should sit inside a layered system:

Deterministic rules check numbers and transaction facts: weight limits, VESA patterns, desk thickness, price, market, inventory and purchase eligibility.
Catalog retrieval finds the products that could be relevant.
Jev helps interpret an incomplete preference, compare already eligible candidates, or decide which question to ask next.
UI components explain the result and expose product details, alternatives and actions.
Shopify and connected systems remain the source of truth for products, carts, checkout and orders.

Do not ask a model to decide whether a 12 mm desk is inside a 10–50 mm clamp range. Write that as code. A semantic question such as “Does this shopper prioritize saving desk space or frequent monitor adjustment?” can be a reasonable model input after hard compatibility has been checked.

Build the catalog before the assistant

An AI layer cannot repair incomplete product data. For each purchasable variant, keep a structured record containing:

product and variant IDs;
load range, VESA pattern and supported desk thickness;
clamp, grommet or other mounting method;
adjustment characteristics and space requirements;
market, currency, current price and selling status;
source, revision and last-updated time for important fields.

Use the same fields to render the product page and to evaluate compatibility. Keep time-sensitive data such as price and availability in a live lookup path, and recheck it immediately before a cart mutation. If a field is missing, represent it as unknown. Missing load data must not be treated as “no load limit.”

A six-stage request flow

The first version can be modeled as:

capture needs
  -> retrieve candidates
  -> validate hard constraints
  -> ask Jev a small decision question
  -> ask the shopper to confirm
  -> create or update the Shopify cart

The following is pseudocode, not a Jev or Shopify SDK example:

const needs = collectNeeds();                 // unknown values stay unknown
const candidates = retrieveCatalog(needs);
if (requiredInputsMissing(needs)) return askForMissingData();
const eligible = candidates.filter(p => verifiedHardRulesPass(p, needs));
if (eligible.length === 0) return showNoMatchOrEscalate();

const decision = await jevChoice({
  question: "Which eligible option best matches the shopper's stated priority?",
  options: [...eligible.map(p => p.internalKey), "NO_MATCH", "ASK"],
  state: { needs, candidates: eligible.map(p => ({
    key: p.internalKey, verifiedFacts: p.facts, sourceRevision: p.revision
  })) }
});
if (["NO_MATCH", "ASK"].includes(decision.value)) return routeFallback(decision);
if (!passesValidatedDecisionGate(decision)) return showComparison(eligible);
const selected = mapAndRecheck(decision.value, eligible);
return showForConfirmation(selected);

The server must own the mapping from an internal candidate key to a real variantId. Never let a model invent a variant ID. After the shopper confirms, fetch current selling status and price again, then perform the cart operation.

Confidence is a signal, not an accuracy claim

TypeSafe's confidence documentation describes confidence as derived from the probability distribution and reflecting how concentrated the result is. It is not a measured business accuracy rate. Noul does not expose this same confidence field.

If two eligible products are close, show their differences and let the shopper decide. If the model is highly concentrated but the monitor weight is still unknown, the system must still ask for the weight. A practical gate is:

required data complete
AND deterministic compatibility passes
AND the model result meets a threshold validated on local review cases
=> show a recommendation
otherwise => ask, compare, or escalate

The threshold is an application policy that needs real, manually reviewed examples. It should not be copied from a universal number or treated as a promise across languages, categories or markets.

Connecting the recommendation to a real Shopify cart

For a Storefront API implementation, Shopify's cartCreate mutation can create a cart and return a checkoutUrl. The response also needs to be checked for userErrors and warnings. Existing theme stores should first decide whether the assistant will use the current theme cart or a Storefront Cart flow. Running a second, hidden cart can create the confusing state where the assistant says “added” while the site's cart icon is empty.

Use this sequence for the mutation:

Resolve the confirmed selection on the server to the current variant.
Recheck price, inventory, market, quantity limits and any customer-specific rules.
If a fact changed, show the updated result and ask for confirmation again.
Add the variant and quantity to the chosen cart implementation.
Inspect errors, warnings and the returned cart contents before showing success.
Offer the checkout link only after the cart state is known.

Handle double clicks and uncertain network responses. Give each client action an application-level operation ID; when a request times out, query the cart or mutation result before retrying. This is an application design responsibility, not a guarantee that every Shopify or model interface automatically deduplicates requests.

Payment, order creation and refunds belong to the transaction system. A model response can describe a recommendation, but it cannot establish that an order succeeded.

Failure paths are part of the product

Design the fallback before launch:

Jev unavailable: preserve the collected constraints and return ordinary filters or a product list.
Required catalog field missing: explain what needs confirmation instead of claiming compatibility.
Price or inventory changed: refresh and request confirmation.
Several products fit: present a comparison.
CRM or downstream sync fails: retain the inquiry and surface a recoverable status.

Keep secrets on the server, give the model only the data needed for the current judgment, and avoid granting it permission to change products, prices or refunds. Log model and question versions, catalog revision, routing result and error reason without retaining unnecessary personal data.

How to validate the first release

Create manually reviewed cases covering clear requirements, missing information, contradictory constraints, no-match results and multilingual phrasing. Run the assistant in shadow mode first so it records recommendations without changing the shopper's result. Check whether suitable products enter the candidate set, unknowns remain unknown, hard rules are respected, follow-up questions are necessary, and the ordinary shopping path survives a timeout.

Only then compare a small set of flows. Track recommendation acceptance, add-to-cart, checkout completion, human escalation and return reasons. A higher click rate alone does not prove better product selection. Measure the full path: retrieval, rule checks, model call, rendering and cart mutation.

WESWOO focuses on Shopify storefront design and development, with B2B, Plus and systems integration when a project requires it. In this type of project, that can include structured product pages, comparison components, mobile interaction, cart integration and an explicit test plan. Learn more at WESWOO's Shopify design and development services. The implementation scope and data sources should be confirmed for each store; this article does not claim that WESWOO has deployed Jev or this workflow for a named customer.

Connecting a LinkedIn Carousel to a Shopify B2B Inquiry Workflow

WESWOO — Mon, 21 Sep 2026 14:52:03 +0000

A LinkedIn carousel can earn a click. A useful B2B workflow has to do more: preserve why the buyer clicked, show the promised information on Shopify, save a complete inquiry, and give sales a clear next state.

This is a practical implementation guide for Shopify teams. The examples are planning examples, not results from a real customer or a real LinkedIn campaign. The accompanying images are AI-generated concepts, not product engineering drawings.

1. Start with the ad format and one buyer action

This article is about LinkedIn Campaign Manager's carousel image ad format. LinkedIn currently documents two to ten cards, a recommended 1080 × 1080 pixel square image, a 10 MB maximum file size per image, JPG/PNG/non-animated GIF support, and no video in this format. Card headlines have a 45-character limit; introductory text can be up to 255 characters, with 150 recommended to reduce truncation. See LinkedIn's specifications and creation guidance.

Choose one audience and one next action before writing cards. For example: “A project buyer should submit enough information for an initial product recommendation.” Then make every card support that action: identify the use case, explain a product difference, point to a verifiable specification, explain the buying process, and state what the inquiry needs.

LinkedIn recommends starting with three to five cards and testing the order or adding more cards later. Each card should make sense if it is the first one a buyer opens. Different cards can use different destination URLs; if you use a LinkedIn Lead Gen Form, the cards connect to the same form. Keep those two paths explicit in the campaign plan.

2. Make the Shopify page answer the card's promise

The destination page should make the transition obvious. A card that says “Compare series” should land on the comparison section. A card offering technical material should expose the correct file, model and revision. A card asking for a project quote should explain which inputs are needed and what happens after submission.

For a shared buying task, one page with clear sections can work well: use case, selection guidance, specifications, files, purchasing notes and inquiry form. For different product families, separate collection or solution pages may be easier to maintain. In either case, test mobile layout, anchor links and direct entry to a middle section.

On Shopify, reusable theme sections and blocks can hold these modules. That makes it easier to update product data, language versions and campaign-specific content without rebuilding every page. The implementation should still define the source of truth for specifications and document ownership of each field.

3. Preserve source context from the first click

Use stable naming for every campaign, card and revision. One example is:

utm_source=linkedin
utm_medium=paid_social
utm_campaign=project_selection_en
utm_content=series_compare_v1_card02

This is an internal naming convention, not a LinkedIn requirement. Shopify Campaigns supports UTM parameters and can use utm_content to distinguish creative elements when the matching rule is configured accordingly. Extra parameters do not automatically become fields in a custom inquiry form or CRM. Define the handoff and test it. See Shopify's Campaigns documentation.

Preserve the source values in a first-party form field, session storage or another approved mechanism, subject to the site's privacy notice and consent requirements. Avoid putting personal information into public URLs. The saved inquiry should include the landing page, campaign, card/version, selected product, form revision and submission ID where those fields are relevant.

4. Submit and validate on the server

The browser can display a success message before an API request has been stored. Treat “submit” as an event only after the server has validated and saved the inquiry. A practical sequence is:

Validate required fields and consent on the server.
Create a durable inquiry record with a unique submission ID.
Save attribution and product context alongside the record.
Return a status the page can safely display.
Send the record to the CRM or queue, with retry and error handling.

If the CRM handoff fails, the inquiry should remain recoverable and the customer-facing message should not claim that a sales record was created. A response-time statement should match what the team can actually meet. “We received your request” is different from “Your quote is confirmed.”

For LinkedIn conversion measurement, teams may send the same event through the Insight Tag and Conversions API. LinkedIn's deduplication documentation says the browser and server events need corresponding conversion rules and the same eventId for the same account and event. Sending through both methods alone does not prove that deduplication works; verify the conversion breakdown and event counts.

5. Give sales meaningful CRM states

Do not treat every form submission as a qualified lead. A simple state model might be:

Received: the server saved the inquiry.
Needs review: required business context is missing or unclear.
Qualified: sales confirmed a relevant product, market and buying need.
Quote in progress: product, price and delivery conditions are being checked.
Proposal sent: the commercial response was delivered.
Closed: the agreed business outcome is recorded.

For merchants that require a wholesale account, separate “application received,” “account approved,” and “catalog or price access granted.” A public inquiry should not silently grant wholesale pricing, credit terms or restricted catalog access.

Shopify B2B catalogs can control product availability and pricing, with quantity rules and volume pricing. Current Shopify documentation says Basic, Grow and Advanced plans can assign up to three active catalogs across B2B markets; Plus adds unlimited catalogs and direct assignment to companies and locations. Check the store's current plan and required feature before promising a specific setup. See Shopify's catalog guidance.

6. Diagnose the whole path

Review the path in order: impressions and card clicks, landing-page visits, valid submissions, qualified inquiries and commercial progress. If clicks are high but valid inquiries are low, inspect the card promise, mobile page and form. If inquiries are plentiful but qualification is poor, inspect targeting and the fields that identify project fit. If qualified inquiries stall, inspect sales handoff and quoting rather than changing the carousel by default.

Change one major variable at a time and give sales enough time to classify new submissions. A high click rate on a later card does not prove that moving it to the first position will improve performance.

WESWOO focuses on Shopify storefront design and development, with Plus/B2B and systems integration when a project requires it. See WESWOO’s Shopify services. The practical goal is a traceable path from ad promise to page content, validated inquiry and sales action—not a claim about guaranteed campaign performance.

Prepared with AI assistance and checked against the cited documentation. Developed from Shopify’s carousel guide, with WESWOO implementation analysis. Concept images are not real customer projects.

Designing a Shopify Freight Workflow: Data, Quote Validity and Failure Paths

WESWOO — Mon, 21 Sep 2026 10:03:29 +0000

For developers integrating Shopify with a freight rate provider or warehouse system, the important contract is the shipment the warehouse will execute. Shipping is part of the product promise. A customer needs to understand where the shipment will be delivered, what unloading assistance is included and how the price was calculated.

Shopify's introduction to less-than-truckload freight explains how merchants can share truck capacity when their shipments are unsuitable for ordinary parcel delivery but do not require a full truck. This article develops that starting point into an implementation framework for Shopify merchants. Read Shopify's LTL guide.

1. Model the shipment, not just the product

An assembled desk's dimensions are useful to a shopper. A freight quotation needs the dimensions and weight of the shipment that will leave the warehouse.

Create a shipping record for each SKU: packaged dimensions and weight, package count, approved pallet rules, stackability, eligible origin warehouses and handling restrictions. Where relevant, confirm the applicable freight classification with the carrier or freight specialist. NMFTA describes classification in terms of density, stowability, handling and liability; product weight alone is not a complete classification method. NMFTA guidance.

Choose a source of truth for this data. Shopify metafields, an ERP or a warehouse system can play a role, but assigning fields does not automatically make a rate provider consume them. Specify who maintains the records and what happens when packaging changes or required data is missing.

2. Treat receiving conditions as order requirements

Collect the information that changes the service: destination type, unloading facilities, liftgate requirements and any appointment or additional delivery services.

A liftgate assists with lowering freight to ground level. It does not include inside delivery, upstairs carrying or installation unless separately confirmed.

A business name does not establish that a destination has a loading dock. Explain the delivery scope in plain language and confirm it with the carrier. Keep the customer's selected service attached to the order so the warehouse and delivery team receive the same instructions.

Use the product page for delivery eligibility and service explanations. Use the cart or quotation flow for receiving details. Use order confirmation to restate the agreed scope.

3. Match the quotation method to the order

Fixed or zone-based rates: useful when packaging, origins, destinations and included services are sufficiently predictable. Define exclusions and review collected freight against actual costs.

Live rates: useful when shipment data and the rate integration can represent the real order. Test multiple packages per SKU, pallet consolidation, non-stackable items, service selections and split origins. A returned number does not prove that the warehouse will ship the same configuration.

As checked on September 21, 2026, Shopify documents third-party carrier-calculated shipping as available on Advanced and Plus, with additional eligibility options for Grow. The chosen app and carrier account must also support the actual freight service. Shopify plan requirements.

Reviewed quotations: appropriate for complex wholesale, unusual packaging and special destinations. Preserve the shopping list and receiving details, confirm freight, then send a payment request. Shopify draft orders can support invoices with secure checkout links. Draft-order documentation.

4. Make quote validity explicit

As a proposed system design, associate each quote with the SKU quantities, packaging version, origin, destination, selected service and expiry. Re-evaluate it when a material input changes.

Do not assume a custom field added to the storefront will appear in a shipping-rate callback. Check the actual request contract and the integration's method for passing additional receiving information. Shopify rate-callback documentation.

For example, a hypothetical order for six chairs and two tables should first be assigned to its origin warehouse or warehouses, then packaged according to validated rules, then quoted against the destination's actual receiving conditions. Simple unit-rate multiplication should only be used where the business has verified that it is appropriate.

5. Design the failure path before launch

Test quantity changes, mixed parcel-and-freight carts, destination changes, added services, split shipments, rate-provider timeouts and unsupported destinations.

An unavailable quote is not a zero-cost shipment. Route the customer to a reviewed quote or a deliberately calculated fallback. Shopify also notes that eligible flat rates can remain selectable even when live rates work, so a fallback configuration needs commercial review. Shipping-rate guidance.

Track quote success, collected freight versus actual fulfillment costs, and the causes of adjustments. Separate intentional shipping subsidies from quotation errors.

Where WESWOO fits

At WESWOO, Shopify storefront development, Plus/B2B workflows, brand experience design and systems integration can be scoped around this complete transaction: explain delivery clearly, capture the right inputs, choose a quotation path, and pass the agreed requirements into fulfillment.

Carriers and logistics partners define their transport services and charges. The ecommerce implementation should make those confirmed conditions understandable to customers and executable by the systems and teams handling their orders.

The practical goal is a consistent promise from product page to delivery—not merely a shipping number at checkout.

Prepared with AI assistance and checked against the cited documentation. Images are AI-generated concepts, not real facilities or customer projects.