Industry
Selling in more than one place is an inventory problem before it is a marketing problem.
Operations
Common situations to examine during discovery with the people who do the work.
We oversell every time something goes viral.
Channels each hold their own stock number, so a spike sells the same unit three times and the refunds follow.
Orders are copied into the fulfilment system by hand.
Someone exports a spreadsheet every morning. It works until volume doubles or that person is away.
The platform fee is now our biggest line item.
Percentage based platform pricing scales with revenue whether or not the platform is doing more work.
Our products do not fit the product model.
Configurable items, made to order goods, bundles and trade pricing all get forced into a variant structure that was not designed for them.
Nobody can explain the stock figure.
Quantities are edited rather than derived, so a discrepancy cannot be traced and stock takes become negotiations.
Returns are handled in email.
Authorisation, receipt, inspection and refund happen across messages, with no record and no effect on stock until someone remembers.
Software capabilities
Define which system owns SKUs, variants, product media and available stock. Reservation, shipment and return are different inventory movements. A website should not sell a cached quantity as if it were a confirmed warehouse allocation.
Create orders from verified payment events, then send eligible items to the fulfillment provider. Preserve external order identifiers, shipment updates and partial fulfillment states. Print-on-demand items need the correct design and variant references.
Track return authorization, inspection, stock disposition and processor refund independently. Reconcile payouts to orders and fees so the accounting export explains the deposit rather than merely recording its total.
Related solutions
Integration
Identify the system of record, available interfaces and vendor access before defining the integration scope.
| Storefront | A custom store or a headless front end over an existing platform, built for your catalogue and fulfilment model. |
|---|---|
| Inventory ledger | One stock position derived from immutable movements, serving every channel, so oversell is a decision rather than an accident. |
| Order management | Orders from web, marketplace and counter in one lifecycle, allocated, picked, shipped and returned through a state machine. |
| Fulfilment routing | Per line routing between your own stock, dropship suppliers and print on demand providers, with tracking merged on the order. |
| Payment processing | Checkout through a processor using hosted fields or a managed checkout page, with orders created from verified webhooks. |
| Reporting | Margin, turns, fill rate, stockouts and channel performance computed from the ledger rather than exported and pivoted. |
Security and implementation
Use hosted payment capture, scoped administrative roles and signed fulfillment webhooks. Protect customer exports and account recovery. A hosted checkout reduces card-data exposure but does not eliminate merchant PCI responsibilities.
The final stack depends on existing systems, device requirements and data access.
Your team
Every engagement has a dedicated project manager and a team lead with years of industry experience. Onshore and offshore engineering teams are both available, and the mix is agreed with you.
| Project manager | Dedicated to your engagement, responsible for scope, cadence and delivery |
|---|---|
| Team lead | Years of industry experience, accountable for technical decisions |
| Engineers | Onshore and offshore, sized to the scope agreed in writing |
| Quality assurance | Testing against the specification rather than against the code |
| Coverage | Time zone coverage for North America and Europe |
| Support | Support in English, French, Spanish and Filipino |
FAQ
Yes, once one ledger owns the position and both channels post movements to it. The limiting factor is how quickly each channel reports a sale, which sets the buffer on fast moving lines.
Sometimes. It becomes worth it when platform fees are material, when your product or pricing model does not fit, or when the workarounds have their own maintenance cost. If none of that applies, staying is the honest answer.
Yes, with customer group pricing, minimum quantities and separate visibility, so a trade buyer sees trade terms on the same product.
Events are stored by processor identifier and order creation is keyed, so a repeated webhook is acknowledged and dropped rather than creating a second order.
Yes. Orders route per line to a fulfilment partner, with the submission, status and tracking written back to the order.
No. Card details go from the browser to the processor through hosted fields or a managed checkout, and your systems only ever see a token.
Tell us where the current process breaks down. We can map the workflow, examine the integration requirements and define a practical scope for the build.