Connecting the web, stores, and operations with Shopify POS

A customer can discover a product online, check its availability, try it in store, order it to a different address, and return it at a point of sale. For them, the journey belongs to one brand. For your teams, it crosses several tools, stock rules, and areas of responsibility.

Shopify POS can bring online commerce and retail closer together. The quality of the result, though, depends on very concrete decisions: which stock is visible, which source is authoritative, how a reservation expires, where an order gets prepared, how a return is logged, and which data follows the customer.

We lay these decisions out in the open. The goal isn't to erase all complexity, but to keep it from being discovered at the counter, or after launch.

We start from the situations teams and customers actually experience. A map connects each journey to the data, systems, and rules it needs.

The work can cover:

• stock visibility online and per store;
• click and collect, from the availability promise to pickup;
• shipping from a store, or transfers between locations;
• returns and exchanges between web and retail;
• customer accounts, purchase history, and consent;
• gift cards, perks, and loyalty programs;
• catalogs, prices, taxes, and payment methods applicable by location;
• local services such as reservations, personalization, or appointment booking;
• in-store team roles and permissions.

Not every topic necessarily calls for custom development. We separate what Shopify and Shopify POS already handle, what an app can cover, and what needs to connect to the information system.

Stock is often the starting point, but rarely the only one. An ERP may carry the accounting data, an OMS may orchestrate orders, a PIM may maintain product data, and a loyalty tool may hold customer perks. Adding Shopify POS without specifying each one's role creates duplicates and gaps that are hard to diagnose.

We document the sources of truth, the events exchanged, and the behavior on error. For a stock flow, that means specifying, for example, where the quantity comes from, the sync frequency, which reservations are accounted for, and how the team handles a discrepancy. For an order, you need to know who accepts, prepares, cancels, or refunds it.

This architecture stays proportionate to the project. A brand with a few locations and a simple catalog doesn't need the same setup as a distributed network with several fulfillment modes.

Omnichannel design isn't just about adding a "Pick up in store" button. We work through the information the customer needs at every step: which store has it, the stated timeframe, pickup conditions, the confirmation message, ID to bring, and the procedure if the product is no longer available.

The store locator needs to serve an action too. It can expose hours, services, contact details, and useful availability, then guide toward directions, a reservation, or a purchase. The content needs to stay manageable by the teams who know the network.

On the staff side, the interface and the rules need to match what actually happens on the floor. We validate the simple, nominal cases, but also the exceptions that eat up time in store: item missing, partial pickup, exchange, refund, local discount, or a customer who can't be found.

1. Observing the journeys and the constraints

We bring retail, e-commerce, operations, and engineering together around the same scenarios. Store, network, and hardware constraints are identified as dependencies, even when they're outside BlackSwan's scope.

2. Deciding on the architecture

We define the sources of truth, the flows, the responsibilities, and the recovery rules. These decisions are written down, so two teams don't end up applying different rules.

3. Configuring, connecting, and testing

We configure Shopify within the agreed scope, build the necessary connections, and test the journeys end to end. QA covers the web, the back office, and the actions carried out in store.

4. Preparing the rollout

Teams get documentation and verification scenarios suited to their role. Launch can be staged when the network or the architecture calls for it.

5. Evolving the setup

Feedback from the field feeds the roadmap. A rule that's hard to apply, unreliable data, or a repetitive task becomes something to fix, not a habit to work around.

BlackSwan works on Shopify strategy, the web experience, platform configuration, integrations, and QA when they're part of the agreed scope. We can coordinate the teams who own the ERP, OMS, loyalty, or payment to keep the architecture coherent.

POS hardware, network coverage, physical installation, local tax obligations, and store-specific procedures all need named owners. This page presents them as dependencies to scope, never as topics automatically covered.

The project is ready to be detailed once the expected services are prioritized, the stock sources are known, the business owners are available, and the main exceptions are described. On the other hand, a general promise of "unified stock" with no allocation rule or operational owner needs to be clarified before any development starts.

A scoping workshop turns intentions into testable scenarios. You come away with a view of the journeys, the systems involved, the open decisions, and the evidence to gather before deployment.

Le Coq Sportif, a French sports brand since 1882: Shopify Plus and Shopify POS, with click and collect, gift cards, and product personalization.

Ogier, a mountain sports house since 1948: Shopify POS, click and collect, pre-order, and product personalization.

Atelier Marius, a fine Provençal grocer since 1958: Shopify POS, store locator, click and collect, and gift cards.