Understanding the flow
Separating sales journeys from back-office systems
- 1
Business sources
ERP, PIM and stock
- 2
Integration
APIs and events
- 3
Commerce capabilities
Catalogue, cart and orders
- 4
Sales channels
B2B, B2C and partners
Simplified teaching diagram. Steps and technical choices depend on the context; this is not a delivered client architecture.
When commerce depends on too many systems
A catalogue is prepared in a PIM, prices and customer accounts live in ERPs that are sometimes distinct, availability comes from stock, campaigns depend on marketing tools, and orders must reach the right legal entities to be delivered and invoiced. Adding a B2B or B2C site to that set immediately exposes inconsistencies.
At that point the question is no longer which framework to choose. It is how to sell without exposing the weaknesses of internal systems directly to buyers.
A shared core oriented to business capabilities
From interoperability and commercial-architecture work, one approach is to separate customer journeys from internal data processing. Business APIs expose useful functions: product search, account-specific prices, authorised catalogue, cart, availability, order and progress status.
A read-oriented data layer can feed search and catalogues without querying a transactional ERP on every click. Updates can then be propagated by events, APIs or ETL according to the freshness required. There is no single architecture that fits every volume and every constraint.
Availability: do not promise the impossible
Saying that a site will never be unavailable is not credible. Architecture can, however, limit interruptions: caching some reads, controlled degradation when the ERP is slow, processing queues, recovery after an incident, monitoring and load tests.
A catalogue read can sometimes remain available during a synchronisation incident. An order, a stock reservation or a contractual price requires suitable validation. Stale data should not be displayed as if it were guaranteed in real time.
What role for a data lake or analytical warehouse?
A data lake or an analytical platform such as Snowflake can help consolidate sources, measure sales, feed analyses and distribute controlled data. That does not automatically replace the order system, nor the consistency rules needed for operations.
Transactional data, views destined for commercial channels, control history and analytical uses should be distinguished. That separation helps keep a fast experience without losing operational traceability.
AI-assisted search and commercial automation
Semantic search, catalogue enrichment or recommendations can help teams and customers when references are numerous. AI should work on governed data, and its proposals should remain explainable and controllable. A search result must not invent a price or an availability.
Useful automations depend on the business: qualifying requests, handing over to a sales team, replenishment to review, marketing content to validate or product anomalies to flag. Value is measured in the real journey, not in an isolated demonstration.
What Mahthildis can take on
Paulo Castro can connect business requirements, architecture, PIM, ERP, APIs, data, search and operations; design the structuring choices, coordinate teams and lead a delivery scope. The options mentioned here are design avenues, not a claim that they were all deployed together.
An omnichannel platform should simplify the customer journey without denying the complexity of existing systems.
About these field situations
These situations combine lessons from Paulo Castro's professional experience. Organisations and operational details are not identified. They illustrate issues and possible approaches, not a claim that all suggested solutions were delivered together or that they are Mahthildis client references.
