Blog | foobar Agency

Gartner Magic Quadrant 2026: What It Means for Your Platform Decision

Matthias Dietrich — Mon, 26 Oct 2026 00:00:00 GMT

Gartner has published a new edition of its Magic Quadrant for Digital Commerce, and many CIOs and CDOs are asking themselves the same question. Does the new quadrant change anything about our platform decision? Our assessment is that it rarely calls existing decisions into question. It does, however, clearly shift the criteria by which you should measure your platform over the next two to three years.

In 2026, Gartner mainly changed the rules of the game. What is new is which vendors are included at all and which capabilities a platform must bring. To read the new positions correctly, you first need to look at these rules.

What Has Changed Since 2025

In 2025, almost all evaluation criteria were weighted high. In 2026, Gartner concentrates the weight on product, viability, pricing, market understanding and innovation, while customer experience, marketing strategy and sales strategy now only count as medium. The biggest changes, however, are in the market definition, the mandatory scope and the inclusion criteria.

Aspect	2025	2026
Report title	Digital Commerce	Digital Commerce Platforms
Buyers per definition	Customers	Customers and AI agents
Mandatory capabilities	Storefront through checkout, pricing, business tooling, API interoperability	additionally digital experience composition, personalization, low-/no-code integration, B2B basics (entitlements, buyer organizations, quotes, PO numbers) and post-purchase (order status, tracking, returns)
New as optional		AI agents and copilots, third-party agent integration via MCP, digital sales rooms
Removed		Live commerce, sales associate integration, basic PIM
Inclusion criterion	Software revenue between USD 28M and 65M with growth requirements	more than 70 production customers, at least 10 new customers in 2025, relevance to Gartner clients as judged by analysts
Regional spread measured by	Revenue	Customer count
Vendors evaluated	19	14
Honorable mentions	Baozun, Liferay, Ultra Commerce	Centra, Commerce Layer, DJUST, Emporix, PrestaShop

Gartner names three core criteria for buyers in 2026. They are readiness for agentic AI, a flexible architecture and proven scalability for B2B and B2C on a single platform.

New Positions Mostly Reflect New Rules

If a vendor sits in a different spot in 2026 than in 2025, it is often because the field has changed. With five fewer vendors, relative positions shift even when the products themselves have changed little.

On top of that comes the switch from revenue to customer count. From 2026, the number of deals matters more than their size. That likely explains why WooCommerce is new in the quadrant, while Sana, Infosys Equinox, Virto, Elastic Path and HCL are no longer included. Analyst judgment also now ranks first among the inclusion criteria and officially carries more weight.

For you as a platform operator, this means the following. A platform that fit your processes well a year ago fits them just as well today. A drop in the quadrant is a reason to take a closer look. On its own, it is rarely a reason to switch platforms.

Measure Agentic Readiness by What Runs Today

For the first time, Gartner includes AI agents as buyers in its market definition. A platform should enable both customers and agents to buy. As a result, roadmap and agentic capabilities gain weight, while customer experience and go-to-market execution lose relative importance.

The weighting shows how far the lens has shifted. Customer experience, which reflects the satisfaction of reference customers, now counts as medium instead of high. At the same time, some of the agentic capabilities Gartner rates positively are, according to the vendors themselves, still in beta or on the roadmap.

It is also clear which kind of AI counts. One vendor was downgraded because its AI investments are mostly tools for developers. Gartner counts agents and interfaces that reach the customer as readiness.

We think the direction is right. In day-to-day retail, however, we see a different pace. Agents that buy autonomously on behalf of end customers are still the exception today. Agents already deliver measurable value internally, for example in order processing, customer service and data maintenance, and in B2B processes such as replenishment and quoting.

That is why we recommend checking agentic readiness against concrete points. What matters are open interfaces, clean data access to products, prices and inventory, and the ability to connect your own agents through standards such as MCP. A platform that can do this today is well prepared for the agentic future, regardless of what the roadmap slide says.

AI Costs and B2B Automation Become the Benchmark

The cautions Gartner lists for individual vendors show more clearly than the weighting tables what platforms are measured against in 2026. Three topics stand out.

The first is the cost of AI capabilities. For several large vendors, Gartner explicitly flags token- or usage-based AI add-ons as a cost risk. What convinces in a demo can noticeably change the total cost of ownership at full usage.

The second is automation in B2B sales. The benchmark now includes AI capabilities that capture orders from unstructured documents such as PDFs and emails and help negotiate quotes. For manufacturers and wholesalers, this is the most tangible point in the entire report. Manual order entry ties up a lot of capacity in many inside sales teams, and that is exactly where AI already lowers costs and shortens lead times today.

The third is open protocols. Gartner counts support for standards such as MCP, ACP and UCP, through which agents communicate with a platform, as a strength.

The Broader Mandatory Scope Strengthens Composable Architectures

With digital experience composition, personalization, B2B basics and post-purchase as mandatory, the bar for a platform is significantly higher. A pure commerce core barely meets the definition anymore.

Companies therefore have two paths. They opt for a large suite that delivers everything from a single source. Or they connect specialized components into a platform that fits their processes exactly. The new honorable mentions show that Gartner takes the second path seriously. With Commerce Layer, Emporix and DJUST, several API-first vendors with a strong focus on MCP are represented. The group is also considerably more European than last year.

For companies in the DACH region with grown system landscapes, this is good news. ERP, PIM and data platform stay where they are, and the commerce platform grows by the capabilities Gartner now expects. The effort shifts from licensing to integration. That is where a composable platform shows whether it delivers on its advantages.

Gartner applies a strict standard here. Capabilities that are only available through third-party solutions are still counted against composable vendors as a weakness. In 2025 this concerned CMS and personalization, in 2026 mainly AI assistants in the storefront.

At the same time, the report describes two developments side by side, the continued shift toward composable and a consolidation toward end-to-end suites. The quadrant does not make the architecture decision for you. It depends on your processes, your system landscape and how well the components are integrated.

Six Questions for Your Next Platform Review

The quadrant provides good market orientation. These six questions answer the decision for your company more precisely.

Which of the new mandatory capabilities does your platform cover today, and which do you actually need for your business?
How are AI capabilities priced in your contract, and what will they cost at full usage over the entire term?
Can your own or third-party agents access products, prices, inventory and orders today, for example via MCP?
Do you run B2B and B2C on a single platform, or do you operate the same capabilities twice?
Where does your platform tie up the largest share of budget and team capacity today, and would switching change that?
How quickly can you bring a new capability such as automated order capture or a service agent live?

Our Conclusion

The 2026 Magic Quadrant describes a commerce platform that does more than sell. It composes experiences, serves B2B and B2C together and opens up to agents. This direction matches what we see in projects with retail and manufacturing companies.

Reading the positions in the quadrant as a ranking easily leads to the wrong conclusions. Using the new criteria as a checklist for your own platform gives you a clear plan for the next stages of development. We would be happy to discuss with you where your platform stands today and which steps pay off for your business.

This article is based on the Gartner reports “Magic Quadrant for Digital Commerce” (2025) and “Magic Quadrant for Digital Commerce Platforms” (2026). The assessment reflects the views of foobar Agency.

This post was first published on foobar.agency. https://foobar.agency/en/blog/gartner-magic-quadrant-2026-digital-commerce-plattformentscheidung

From Snowflake to AI: Predictions and LLMs on the Commerce Data Model

Dominik Thalmeier — Thu, 25 Jun 2026 00:00:00 GMT

When the CDO asks in the quarterly review, "where do we stand on AI?", the honest answer is rarely a single use case — it's a map. On that map, three maturity stages sit side by side: deterministic calculations (revenue by region, stock coverage, margin per SKU), probabilistic predictions (CLV, churn probability, next-best-action), and LLM-driven decisions (service co-pilot with order history, generated product descriptions, semantic search across the catalogue). Across Snowflake projects at foobar Agency, we see that clients need all three — but rarely operate at the same level in each. This post closes the data series and shows what Snowflake Cortex and Snowpark ML deliver today, where LLMs add weight on structured commerce data, and which prerequisites need to be in place before the data model becomes the contract between classical models and language models.

Three maturity stages, one architecture

The three maturity stages differ not in the data they consume but in the question they answer. Deterministic calculation answers "how much?" and "when?" — precise, reproducible, traceable in any dashboard. Probabilistic prediction answers "how likely?" — it delivers expected values with confidence intervals, carried by feature engineering and a trained model. LLM-driven decision answers "what fits here?" — it processes unstructured text, combines it with structured context and returns an answer that varies in form.

In Snowflake, the foundation for all three sits in the same lakehouse architecture. dbt-modelled marts-layer tables feed deterministic reports, Snowpark ML trains and versions prediction models, and Snowflake Cortex exposes LLM functions directly as SQL — `COMPLETE` for responses, `EMBED_TEXT_768` and `EMBED_TEXT_1024` for vector representations, `EXTRACT_ANSWER` for question-answering on unstructured text, `SUMMARIZE` for summarisation. The models run managed within the Snowflake region; custom models can be operated through Snowpark Container Services.

Architecturally, this means the data model becomes the contract. The same marts-layer tables that train the CLV model deliver the context for the service co-pilot. The same product and category embeddings that drive semantic search (see Semantic Search and Agentic Search in B2B) deliver candidates for the LLM-driven answer. Skip this separation and you build a dedicated pipeline for every use case — and lose the scaling.

What Snowflake Cortex delivers today

Snowflake Cortex makes pre-trained models available as managed SQL functions. The models run inside the Snowflake security perimeter; data does not leave the Snowflake region when the chosen function is available there. For commerce projects, four function classes are relevant from our perspective.

First: `COMPLETE` calls a language model with a prompt and optional conversation context. Available models range from Snowflake's own Arctic through Mistral and Meta Llama to Anthropic models — selection depends on region and pricing. Practically usable for product description drafts from PIM attributes, categorisation of free-text service requests, and analysis of review text.

Second: `EMBED_TEXT_768` and `EMBED_TEXT_1024` produce vector embeddings from text. Combined with Snowflake's vector data type and the `VECTOR_COSINE_SIMILARITY` function, embedding-based search and recommendation pipelines can be expressed entirely in SQL — without a separate vector database. For mid-sized catalogues (up to low millions of SKUs), this is a pragmatic path. For very large catalogues or sub-100-ms requirements, a specialised vector engine remains relevant.

Third: `EXTRACT_ANSWER` answers questions from supplied text context. For service co-pilots and FAQ flows, this is the most honest variant — the answer is forced to come from the supplied context, not from the model's memory. The hallucination risk drops because the model has no source in which to roam freely.

Fourth: `SUMMARIZE` and helper functions like `TRANSLATE` or `SENTIMENT`. These sit in the second row — not because they're unimportant, but because they appear as building blocks in larger pipelines rather than as use-case drivers.

Those who need more control — custom models, custom tokenisers, custom inference logic — go through Snowpark Container Services. That's the variant for industrial clients with existing ML investments who don't want to migrate to managed models but want to use Snowflake as their data and compute platform.

LLMs on structured commerce data

LLMs deliver the strongest leverage where structured commerce data meets unstructured queries or unstructured text. Three use cases recur in DACH projects.

Embedding-based search and recommendation. Product and category text is converted into vectors with `EMBED_TEXT_768`, stored in a marts-layer table, and matched at search time against the embedding of the query. This complements — rather than replaces — the classical SKU and facet search we describe in Why B2B Search Plays by Its Own Rules. In B2C, the pattern works for discovery-heavy assortments (furniture, fashion, drugstore). In the B2B industrial context (see Data Foundation for B2B Industry), it returns hits for queries that fail in classical full-text search — for example "replacement part for fuse that failed after rain".

Generative product descriptions from PIM data. From structured attributes (materials, dimensions, norms, application fields), a prompt with `COMPLETE` produces a first draft of a description. The value does not lie in final quality — that's an editorial job — but in scaling across catalogues with tens of thousands of SKUs and multiple languages. Prerequisite: a PIM data set that maintains the relevant attributes cleanly. Without clean input, the model hallucinates because specifics are missing.

Service co-pilot with order and service history as context. A service request comes in — the co-pilot pulls the customer's order history, recent service tickets and related product master data in a Snowflake query, and passes them along with the incoming request as context to `COMPLETE` or `EXTRACT_ANSWER`. The model doesn't formulate a free suggestion but an answer anchored in the context. Hallucination risk drops, service quality rises, without each agent walking through every data source by hand.

What unites these three use cases: they access the same data model. The same customer, order and product tables that feed deterministic reports are the source of the LLM context. If the shared data model we describe in Snowflake in Commerce holds, the LLM use cases hold.

Four prerequisites before LLMs touch your commerce data

Before an LLM accesses commerce data in production, four prerequisites should be in place. Skip them and you build demos — not load-bearing use cases.

#	Prerequisite	Why it has to hold
1	Marts-layer data with clear modelling	LLMs are only as good as their context. If customer, order, product aren't modelled cleanly, the model hallucinates around the gaps.
2	Embedding strategy with an update path	Once generated, an embedding index goes stale as catalogues or text change. Whoever uses embeddings needs a mechanism for incremental updates — otherwise relevance erodes quietly.
3	Eval set-up before go-live	"Looks good to me" is not enough. Use-case-specific eval sets — gold-standard question-answer pairs, measured hit rates, hallucination checks — belong before the first production rollout. Without evals, no one measures regressions when the model changes.
4	Governance: who is allowed to see what?	LLM answers must not exfiltrate data the requester is not allowed to see. Row-access and masking policies in Snowflake have to take effect before the LLM layer — not in a downstream filter.

GDPR, region and sovereignty

"Is this GDPR-compliant?" is the most frequent question in the AI workshop and the most imprecise one. GDPR compliance is not a switch but a bundle of data residency, processing agreements, access controls, and the question of who is ultimately empowered, legally, to access what. Three mechanisms should be named in every Cortex project.

Region pinning. Snowflake Cortex LLM functions are available regionally — not every function in every region. Pinning to an AWS or Azure EU region keeps inference there. Before rollout, check which function is available in the target region and which model sits behind `COMPLETE`; otherwise cross-region inference can quietly become active and replicate data into other regions.

Schrems II and the CLOUD Act. An EU region with a US hyperscaler does not fully resolve the Schrems II question. US providers are subject to US law — including for data physically located in Frankfurt. Where strict sovereignty is required (public sector, critical infrastructure, certain regulated industries), the architecture must be evaluated with legal counsel and possibly sovereign cloud providers. For most commerce projects, the combination of EU region, data processing agreement and consistent pseudonymisation in the marts layer is workable — but not "automatically".

Hallucination control as a GDPR concern. An LLM answer that invents personal data ("Ms Schmidt ordered last week") is not a malfunction — it is, in case of doubt, a GDPR incident. Whoever exposes LLMs to customer data needs retrieval-augmented generation with unambiguous sources, eval sets for hallucination detection, and logging that traces the source of every answer.

What doesn't hold: the marketing line "is GDPR-compliant" without concrete mechanisms. What does hold: region pinning, data residency, pseudonymisation in the data model, defined models, documented processing agreements.

When LLM, when classical model

Not every use case deserves an LLM. A CLV prediction on RFM features is a gradient-boosting model — not an LLM job. A stock-coverage calculation is a SQL query — not an LLM job. An LLM justifies itself when three conditions coincide: the input is unstructured or the output varies linguistically, the problem has high heterogeneity (each request is different), and structured context is available.

Forcing LLMs onto use cases where a deterministic or probabilistic model is stronger, cheaper, and more auditable builds in a risk that surfaces at the first audit. Conversely, forcing classical models onto use cases that need real language processing produces workarounds that collapse with every new assortment or language. The maturity logic from the first section is not a hierarchy — it's an assignment.

LLMs on commerce data carry weight exactly when the structured world is in place first. We regularly see projects where a gradient-boosting model solves CLV prediction better, cheaper and more auditably than any LLM approach — and at the same time, service queries where only a RAG set-up with clean order context brings wait times under control. The craft is not to put LLMs everywhere but to pick the right maturity stage for each use case.
— Dominik Thalmeier, Team Lead Data Science foobar Agency

Frequently asked questions

What is Snowflake Cortex?

Snowflake Cortex is the AI layer inside Snowflake. It exposes pre-trained language and embedding models as SQL functions — `COMPLETE` for responses, `EMBED_TEXT_768` and `EMBED_TEXT_1024` for vector embeddings, `EXTRACT_ANSWER` for question-answering, `SUMMARIZE` for summarisation. The models run managed within the Snowflake region and data does not leave the Snowflake perimeter when the function is available regionally.

Do I need my own GPUs for LLMs on commerce data?

For the models available in Cortex, no — Snowflake provides compute and model, billed via credit-based pricing per token. Custom GPUs only become relevant when you operate your own models in Snowpark Container Services or use models Cortex does not cover. For most commerce use cases — product descriptions, embeddings, service co-pilot — the managed path is sufficient.

How does this work with GDPR?

GDPR viability hinges on concrete mechanisms, not a label. Three points belong in every project: region pinning to an EU region including a check of function availability; pseudonymisation in the marts layer so that only the personal data required for the use case reaches the LLM context; and data processing agreements that address the Schrems II question. For strict sovereignty requirements, an evaluation with legal counsel needs to be added — an EU region with a US hyperscaler does not fully resolve CLOUD Act topics.

AI workshop on the commerce data model

In two hours at foobar Agency, we work with you on which maturity stage fits which use case, what your Snowflake data model already supports today and where Cortex, Snowpark ML or classical pipelines are the better choice.

This post was first published on foobar.agency. https://foobar.agency/en/blog/snowflake-ki-llm-commerce-datenmodell-predictions

Semantic Search and Agentic Search in B2B: When Vector Embeddings, When LLM Agents?

Matthias Dietrich — Mon, 22 Jun 2026 00:00:00 GMT

Semantic search is no longer a research topic in eCommerce. Vector embeddings run in production inside Algolia NeuralSearch, Constructor, Coveo and Bloomreach Discovery; native pipelines can be built on Snowflake with Cortex. In parallel, "Agentic Search" has arrived as a new stage — the LLM agent as advisor, querying multiple sources, asking follow-up questions, guiding multi-step conversations. In a B2B context this does not mean: everything must become AI. It means: you now have three maturity stages — keyword plus synonyms, semantic with embeddings, agentic with LLM — and you have to decide which fits which search occasion. This article closes our B2B search series with the question that comes up most often in architecture workshops: what does AI actually contribute to search — and what does it cost?

Semantic Search: When Embeddings Are Measurably Better

Vector embeddings turn search queries and products into mathematical vectors whose proximity reflects semantic similarity. A search for "slip-resistant protective gloves for oil environments" then also surfaces products titled "nitrile gloves, grip coating, oil-grip" — without anyone maintaining synonyms by hand.

B2C studies regularly report double-digit conversion lifts from semantic search. Those numbers should not be carried over to B2B unchecked — search occasions are different, the catalog is smaller, click behavior is different. Where embeddings do deliver measurably in B2B, it is in three constellations: long natural-language queries like "lubricant for high-temperature bearings up to 250 degrees", queries with descriptive vocabulary instead of SKUs, and catalogs with pronounced synonym variety across DIN/ISO designations, brand names and industry jargon.

Where embeddings do not deliver is just as clear: in pure SKU and part-number search. Pure dense vector search degrades on exact product IDs, SKUs, measurement designations — precisely the behavior that accounts for the larger share of B2B search. The productive consequence is hybrid search: keyword (BM25) and vector run in parallel, the result sets are merged and ranked together. Algolia NeuralSearch does this in a single API; Elastic, OpenSearch and Snowflake's native Cortex Search service do too. Anyone thinking about semantic search in a B2B setup is in practice thinking about hybrid search.

Agentic Search: The Agent as Advisor, Not a Result List

Agentic search is not the next version of semantic. It is a different interaction model. A classic search system answers a query with a result list. An agentic search assistant breaks a request into multiple subtasks, calls tools — product catalog, availability, configurator, ERP — and runs a dialogue until the request is resolved. Amazon has had this pattern in production with Rufus since February 2024 in B2C.

In B2B this shifts search toward configurator logic. A request like "We are building a conveyor system for bulk material up to 80 tons per hour, outdoor use, FDA-compliant — which bearings fit?" cannot be answered with a meaningful result list from a classic index. An agent that clarifies the application parameters, then filters the catalog, checks datasheets, adds cross-sell components and finally presents three candidates with reasoning is closer to what buyers know from personal sales conversations. This is exactly where cross-sell potential sits: not in "customers also bought", but in context-driven combinations — matching lubricants for the bearing recommendation, matching fasteners for the construction.

The architecture behind this is not trivial. A productive agent needs tool use (API calls to catalog, pricing, inventory), multi-turn state (the system remembers what has already been clarified), and an abort logic when the agent drifts into a hallucination zone. In B2B there is an additional requirement that the B2C discovery context does not have: the agent must not invent a recommended component. It must exist in the catalog, the customer must be allowed to order it, and the price must be the contract price.

Tech Stack: Native Platform Features or Your Own Pipeline?

For implementing semantic and agentic in B2B there are two realistic paths — rarely either-or, often a deliberate split.

Path A: Native search platform. Algolia NeuralSearch delivers hybrid search from one API; Constructor and Coveo bring similar capabilities. Advantage: time-to-market in weeks rather than months, latencies below 50 ms, no embedding service of your own, no vector store of your own. Limit: embedding models are vendor-proprietary, re-ranking logic is partly a black box, adaptation to industry-specific vocabulary happens via tuning rather than model swaps. For classic eCommerce search in B2B this is the pragmatic path in most cases.

Path B: Your own embedding pipeline on Snowflake/Cortex. Anyone already running on Snowflake — increasingly the case among foobar clients — can generate embeddings natively via Cortex (EMBED_TEXT_768, EMBED_TEXT_1024) and operate them with Cortex Search as a managed vector service. This opens use cases beyond the storefront: semantic search over datasheets, service manuals, contract documents, internal knowledge bases. Economically relevant: Cortex Search bills embedding indexing per token and index hosting per GB-month — which means it costs even without queries. That is a model you have to represent honestly in the calculation.

For agentic search the focus today is clearly on the second path: LLM agent (via OpenAI, Anthropic or Snowflake Cortex AI SQL) plus tool calls into the commerce platform. We go deeper on the data and AI pipeline in our parallel series on Snowflake — see the post From Snowflake to AI: Predictions and LLMs on the Commerce Data Model. Further reading on agent patterns in commerce: Agents for your customers.

Honest Limits: Hallucination, Compliance, Explainability

The three limits most frequently underestimated in B2B implementations do not come from the technology but from the procurement context.

Hallucination. An LLM agent that recommends a product to a buyer that is not in the catalog is not producing a "creative suggestion" — it is producing a complaint case and, in the worst case, a compliance breach. Agentic search in B2B needs hard tool constraints: the agent may only recommend from the released catalog, every recommendation must be validated against an authoritative source of truth, the price comes from the pricing engine, not from the model.

Compliance. In industrial B2B, catalogs are shaped by regulation — REACH, RoHS, export control, industry-specific standards. An agent that recommends an item to a customer in country X that may not be shipped there is not "almost right". Compliance filters must take effect before the LLM response, not after.

Explainability. Buyers want to know why a specific product is recommended — to a supervisor, an auditor, the QA department. "The model produced it" does not carry. A productive B2B agent must be able to surface sources, datasheet references and the filters applied. Where that is not feasible, the classic result list with facets remains the cleaner approach.

Four Decision Questions Before the AI Search Pilot

Before a pilot starts, these four questions should be answered. They decide whether an AI search project becomes an investment or a showcase.

#	Question	What the answer decides
1	Which queries fail today — SKU or natural language?	SKU weakness is solved through indexing logic, not embeddings. Natural-language weakness is the embedding case.
2	Is there a clear use case for multi-turn dialogue (configurator, technical consultation)?	Without a multi-turn use case, agentic search is overengineering. Hybrid search is enough.
3	Are catalog, price and compliance modeled cleanly per customer?	Without that foundation every agent hallucinates — and produces complaints instead of orders.
4	Who carries the running cost — index hosting, token consumption, model updates?	Embedding indexing and LLM calls are consumption-based. The TCO line has to exist before the pilot.

Embeddings are not a cure-all. In B2B projects we regularly see that an honest hybrid search on Algolia or Elastic already lifts the search several notches — and for agentic use cases we then layer the LLM on top only where the multi-turn dialogue genuinely makes money. The model logic delivers nothing if the catalog and contract data underneath are not clean.
— Dominik Thalmeier, Team Lead Data Science, foobar Agency

Frequently Asked Questions

Does semantic search make sense for a small catalog?

With a few thousand SKUs and manageable synonym complexity, a well-maintained keyword index with synonym lists often delivers 80 percent of the effect — at a fraction of the running cost. Semantic pays off as soon as long natural-language queries, heavy industry jargon or multilingual technical terms show up in the logs.

How can LLMs be integrated into an existing search without rebuilding everything?

The pragmatic route is an upstream query-understanding layer: the LLM classifies the query, rewrites it (for instance extracting filter parameters from natural language) and forwards it to the existing search API. Index, ranking and entitlement logic stay untouched — the LLM layer is a translator, not a replacement.

What does hosting embeddings and vector search cost?

With native platforms like Algolia it is part of the NeuralSearch license. With your own pipelines on Snowflake there are two cost blocks: embedding generation per token (per Snowflake documentation in the range of 0.03 to 0.07 credits per million tokens depending on the model) and index hosting per GB-month — the latter also without active queries. Specific numbers only come from a pilot calculation against the real catalog.

AI Search Pilot or Hybrid Search Audit

In a two-hour architecture workshop we clarify with you whether your B2B search genuinely improves with hybrid search, embeddings or an agentic layer — based on your search logs, your catalog and your tech stack. No slides — architecture decisions with effort and cost picture.

This post was first published on foobar.agency. https://foobar.agency/en/blog/semantic-search-agentic-search-b2b-vektor-embeddings-llm-agenten

Data Foundation for B2B Industry: Forecasting, After-Sales, Service Data Flows

Dominik Thalmeier — Thu, 18 Jun 2026 00:00:00 GMT

In B2B industry setups, the data foundation is rarely a Snowflake project with a commerce use case on top. It is a project between S/4HANA or ECC, a CRM (often Salesforce), a service tool (ServiceNow, SAP Service Cloud, or in-house), an MES and — increasingly — IoT platforms with sensor data from the field. Anyone copying B2C commerce logic one-to-one ends up with a foundation that supports reporting dashboards after launch but breaks on the first real industry question: "Which spare parts will we need in Q3 in the southern region, depending on which machines were shipped in 2022?"

This article shows three use cases that can be activated quickly on a properly built Snowflake foundation for B2B industry — forecasting, after-sales prediction, and service data flow back into commerce — and describes what is standard about the ERP, CRM and service connection, what requires craft work, and where the lessons from industry projects between safety, connectivity and power-tool manufacturers sit.

Why commerce data alone falls short

In B2C commerce the data world is manageable: sessions, orders, customers, products, marketing channels, a bit of loyalty. In B2B industry, a second world is added that does not originate in the shop — and that in many foundation projects is either connected too late or not at all.

Service tickets are the smallest, often underestimated unit. A technician documents that on machine X, component Y was replaced, that screw joint Z showed signs of wear, and that the customer asked about Z spare parts during the visit. This information sits in the service tool. It is not in the shop, not in the CRM, and usually not in the ERP. Without it, every re-order recommendation in the B2B portal is a guess.

Maintenance cycles and lifecycle data are the second layer. B2B industry products have lifecycles of five to fifteen years — significantly longer with some manufacturer setups. Anyone building a foundation on a 24-month window (typical in retail) loses half the information that is relevant for after-sales predictions.

Sensor and IoT data are the third layer. Vibration, temperature, pressure, cycle counts — modern machines deliver this data continuously. With its Manufacturing Data Cloud offering and partners like HighByte, Crosser and Cirrus Link, Snowflake has established an architecture in which OT and IT data land in the same platform. What was a standalone Industrial IoT project five years ago is in 2026 a layer in the foundation — provided the foundation is planned accordingly.

Master-data hierarchies and substitution rules are the fourth, quietest topic. In B2B industry, a single customer rarely places the order. A purchasing organisation orders for several plants, with different shipping addresses, with substitution rules for holiday cover, with approval thresholds by position. This logic lives spread across ERP, CRM and partly the shop. Anyone failing to model it cleanly in the Snowflake foundation builds forecasts on customer IDs that do not actually trigger the order in reality.

The consequence is not academic. It shows up on the day the first forecast evaluation is presented to the head of sales — and he says: "That cannot be right, those are three different plants of the same group."

Three B2B use cases on Snowflake

A Snowflake foundation that brings ERP, CRM, service and IoT together is not an end in itself. It is the prerequisite for three use cases that regularly deliver the first business case in B2B industry projects.

1. Forecasting — volumes, seasonality, capacity planning. Classic demand planning gains a different quality from machine learning. Gradient boosting methods (XGBoost, LightGBM) and LSTM models reduce forecast errors in industry studies by 20 to 50 percent compared with standard statistical methods. The prerequisite is a foundation that brings order history, seasonality signals, marketing activities and external drivers (weather, industry indices, project pipeline from CRM) together in a modelled layer — typically in dbt models with clearly separated staging, intermediate and mart layers. What Snowflake delivers here is the compute for thousands of SKU forecasts in parallel, not the ML magic itself.

2. After-sales — re-order probability, wear-out signals, wear-part forecasting. This is the use case that convinces industry CIOs fastest — because it lifts a margin lever in the spare-parts business, which is the most profitable segment on many manufacturer balance sheets. Three signals come together: order history (who bought what, when), service tickets (where was what replaced, when) and — where available — sensor data (which machines show anomalies). The result is a re-order probability per customer × item × time window, surfaced as a recommendation in the B2B portal, as a lead list in CRM, or as a trigger for outbound service calls. Important: this after-sales prediction is not the same as predictive maintenance. Predictive maintenance forecasts the failure of a specific machine based on sensor data — an engineering discipline that sits deep in OT data and models like Remaining-Useful-Life estimates. After-sales prediction forecasts the buying and service behaviour of entire customer segments — a commerce and CRM discipline. Both benefit from the same foundation, but they answer different questions.

3. Service data flow — field service ↔ commerce. The third use case is the one most often underestimated. A technician swapping a component on-site generates information that should trigger a real-time re-order recommendation in the customer portal. Today this information typically sits on a mobile service device, moves into ServiceNow or SAP Service Cloud, and ends there. Anyone closing the data loop — service ticket → Snowflake → event in commerce platform → re-order recommendation — does not just close a data gap. They turn every maintenance visit into a semi-automated sales touch.

ERP, CRM, service: what is standard, what is craft work

Connecting source systems to Snowflake is no longer an act of invention in 2026 — the majority of paths are documented. What matters is the separation between technical connection (available as standard) and semantic modelling (which remains craft work).

The connectors are standard. For SAP S/4HANA and ECC, four main paths are established in the market: SAP-native ODP / CDS view extraction via SAP Datasphere, third-party CDC at database level (BryteFlow, Fivetran HVR, SNP Glue, Theobald), classic batch ETL via the SAP application layer (a phase-out model), and — new for 2026 — SAP Business Data Cloud Connect for Snowflake with zero-copy and bidirectional access (availability per SAP roadmap H1 2026). Which path holds depends on three questions: how sensitive is SAP system load? How much business logic should stay in the source system? How close to real-time must replication be? For Salesforce, ServiceNow, HubSpot or Microsoft Dynamics, the standard answer is usually an ELT tool (Fivetran, Airbyte, Matillion) with a native connector — set up quickly, often in days rather than weeks.

Modelling is craft work. What the connectors deliver are tables — not data models. A forecast-capable foundation needs a semantic layer in which material numbers, customer hierarchies, substitution rules and time validities are linked such that ML models do not stumble over inconsistencies. In dbt that means: consistent separation between staging (1:1 to the source), intermediate (clean business concepts) and marts (use-case-specific tables for forecasting, after-sales prediction, service reporting). Anyone cutting corners here ends up with a reporting warehouse, not an analytical platform.

Master-data hierarchies also remain craft work. In B2B industry setups, the question "who is the customer?" is rarely trivial. A group orders for 14 plants; each plant has a technical buyer who orders and a plant manager who approves; in holiday cover another plant steps in. In ERP these relationships are often modelled in multiple levels, in CRM differently, in the shop different again. Mapping these discrepancies early — before the first ML model is trained — decides whether the foundation holds or whether a second wave of modelling effort becomes necessary six months later.

In industry projects between safety, connectivity and power-tool manufacturers we see the same pattern: the technical part is set up in weeks. The master-data discussion takes months. Anyone reversing the sequence and starting with master-data work saves themselves the loops.

Four B2B use cases that activate quickly

Once the foundation is in place — ERP replication running, dbt models cleanly cut, master-data hierarchies mapped — there are four use cases that regularly become realistic in B2B industry setups within the first six to nine months. Not because they are trivial, but because the data is being lifted anyway.

#	Use case	Data sources	First output	Typical lever
1	Demand forecast per SKU × region	ERP order history, CRM pipeline, seasonality, plant hierarchies	Rolling 12-month forecast with confidence intervals	Reduced safety stock, fewer high-season stock-outs
2	After-sales score (re-order probability)	Order history, service tickets, sensor anomalies (where available)	Customer × item × time-window with probability	Higher spare-parts margin, targeted outbound service calls
3	Service ticket → re-order recommendation	Field-service tool, machine master-data, commerce catalogue	Event-driven recommendation in customer portal	Shortened re-order cycles, fewer phone orders
4	Capacity and bottleneck early warning	MES, ERP order backlog, supplier lead-times	Weekly bottleneck list with top risks	Earlier escalation, fewer delivery delays

What connects these four use cases: they all draw from the same sources — ERP, CRM, service, optionally IoT — and they all benefit when the Snowflake foundation builds the semantic layer with B2B industry logic from the start, not with retail defaults.

Anyone planning the foundation itself will find the platform decision argument in Snowflake in Commerce: From Data Silo to Shared Architecture. Anyone looking at the commerce side, meaning customer-specific search and assortments, will find the logic in Customer-specific Search: When Every Buyer Sees a Different Assortment.

In one industry project we mirrored the service tickets from the field-service tool into Snowflake and joined them with the order history from S/4HANA. After eight weeks the first after-sales score was running, after four months the recommendations landed in the customer portal. The hardest part was not the pipeline — it was the master-data hierarchies between group parent, plant and technical buyer. We know this because we do this.
— Matthias Dietrich, CEO foobar Agency

Frequently asked questions

Do I need different models for B2B than for B2C?

The ML algorithms are largely the same — gradient boosting, LSTM, classic time-series methods. What differs are data structures and features: B2B customer hierarchies (group → plant → buyer), contract terms, lifecycle data for machines, service-ticket histories, technical master-data with standards designations. Anyone applying a B2C forecasting model to B2B data without modelling these features cleanly gets numerically valid but operationally unusable forecasts.

How do I connect SAP to Snowflake?

Four paths are established: SAP-native ODP / CDS view extraction via SAP Datasphere, third-party CDC at database level (BryteFlow, Fivetran HVR, SNP Glue, Theobald Xtract Universal), classic batch ETL (declining), and from H1 2026 SAP Business Data Cloud Connect for Snowflake with zero-copy access. The decision depends on system load, real-time requirements, and whether business logic should stay inside SAP or be rebuilt in dbt.

How long until the first forecast?

In industry projects with a reasonably clean SAP source, we typically reach a first productive forecast after eight to twelve weeks — provided master-data hierarchies are clarified in the first weeks. Anyone failing to clarify them sees the first forecast after six months, because the model has to be retrained twice in between.

Foundation audit for B2B industry

In a half-day workshop, foobar Agency evaluates your existing data landscape — SAP, CRM, service, IoT — against the requirements of forecasting, after-sales prediction and service data flow. You receive a concrete architectural path and an effort estimate, not slides.

This post was first published on foobar.agency. https://foobar.agency/en/blog/daten-foundation-b2b-industrie-forecasting-after-sales

Customer-specific Search: When Every Buyer Sees a Different Assortment

Matthias Dietrich — Mon, 15 Jun 2026 00:00:00 GMT

In B2B implementations, we see the same key scene over and over: Two buyers open the same shop, type the same search term — and see different result lists, different prices, sometimes even different products. This is not a system error; it is the requirement. In B2B, the contract defines which assortment is visible; the pricing engine defines which price applies; the ERP defines which stock is bookable. Search is the frontend where these three worlds must come together — synchronously, performantly, and traceably. In this post, we cover three implementation patterns for customer-specific search indexes, how contract prices become visible in result lists, and which sync strategies between ERP, PIM, and search index actually hold up. If you want one layer deeper — how the data foundation in B2B industry that feeds these setups looks — see Data Foundation for B2B Industry.

Three Patterns for Customer-specific Search Indexes

Anyone modelling customer-specific assortments has, at heart, three architectural options — and none of them is universally right. The choice depends on assortment size, number of customer groups, contract dynamics, and performance budget.

Pattern 1: Multi-tenant indexes — one index per customer group. Each customer group (or, in extreme cases, each key account) gets its own index containing only the assortment visible to them. The advantage: a search query hits only the relevant index, with no downstream visibility filter. This scales well in performance — until the index explosion problem. Anyone with several thousand customers, each with their own assortment, quickly hits the limits of cluster metadata, as Elastic describes in detail in its guide on multi-tenancy with Elasticsearch and OpenSearch.

Pattern 2: Filtered index — shared index with visibility filter. A single index holds the entire assortment; each product document carries a list of permitted customer groups, business units, or contract numbers. At query time, a filter predicate ("visibility_groups contains $customerGroup") is appended. This scales effortlessly in the number of customers, but pays for that scaling with two burdens: every product update must keep all eligible customer groups current, and result-list sorting must cope with the fact that different customers see different subsets.

Pattern 3: Server-side re-ranking. The search returns a raw result set; a re-ranking layer behind the index decides which hits are visible for the logged-in buyer, in which order they appear, and which price is displayed alongside. This pattern is the most flexible option — it decouples entitlement logic from the index — and at the same time the most critical in terms of latency and load. Anyone building this buys architectural freedom at the cost of response times that need to be monitored closely.

In B2B projects at foobar Agency, we most often see hybrid forms: a shared index for the standard assortment plus dedicated indexes for the ten to fifty largest accounts with strongly individual assortments. This is the variant that is least often "elegant" — but most often holds.

Making Contract Prices Visible — Pre-Compute or Live Call

Once customer-specific assortments are in place, the second, often harder question follows: which price appears next to the hit? In B2B, list prices are a fiction — what counts is the contract. Filters ("price ascending"), sorting, and trust in the result list hinge on this directly. There are two viable architectural paths.

Path A: Pre-compute — prices into the index. Contract prices are computed in advance and written into the search index per customer or per customer group. The result list renders in the same query that fetches the products. Performance is excellent; the burden shifts to the sync path. With thousands of customers on individual conditions, the index grows accordingly, and every price change in the ERP triggers a wave of re-indexing. Algolia explicitly documents this approach for B2B scenarios via segment- or buyer-specific price fields; comparable patterns are common in Elastic setups.

Path B: Live call at query time — prices from the pricing engine. Search delivers only product information; a pricing service or the ERP is queried at search time and returns the final prices. Advantage: no index bloat, prices always current. Disadvantage: every search request produces a synchronous call to the pricing engine — with large result lists and pagination, this is where latency tips over. In practice, this path is almost always cushioned by a caching layer, such as Redis with a short TTL per customer-product combination.

Which path holds depends on three levers: price volatility (do contracts change daily or quarterly?), the number of customers with individual prices, and the requirement for real-time consistency (does the buyer see the price that will hit the cart?). A valid third option does not exist: showing list prices in search and correcting them in the cart is the fastest way to forfeit trust in the shop.

ERP and PIM Integration: How Current Is Current Enough?

Search is only as good as the sync that feeds it. Three sync strategies are routinely on the table in B2B setups — they differ in latency, implementation effort, and the consistency they can guarantee.

Event-driven sync. ERP and PIM publish changes via a message broker (Kafka, RabbitMQ, AWS SNS/SQS); a consumer writes to the search index. Latency: typically seconds to sub-minute. Prerequisite: the source systems can produce events — straightforward with modern ERPs, often only achievable via middleware with older SAP ECC setups.

Change Data Capture (CDC). Changes are read directly from the database transaction logs — log-based CDC with tools like Debezium is the industry standard. Latency lies in the seconds-to-minutes range, with minimal load on the source system. CDC is the pragmatic choice when the source does not deliver clean domain events but you do not want to lag by hours. The dbt Labs overview of data-movement patterns explicitly positions CDC between batch and streaming as the pattern that most often holds up in practice.

Batch / scheduled sync. Classic nightly full or delta import. Latency: hours to days. For stable master data (dimensions, standard designations, design attributes) entirely sufficient; for prices and stock, rarely. Anyone syncing stock only once per night will produce orders for goods that are no longer available — that is the point at which search, not the ERP, loses trust.

In most B2B implementations we see a mixed architecture: batch for product master data from the PIM (daily, sometimes more often), CDC or event-driven for prices and stock from the ERP (sub-minute). Which frequency holds for which field is a decision per field — not per system. That belongs in the architecture sketch, not the sprint backlog.

If this sync architecture is to run over Snowflake as a central data platform — which we regularly recommend for B2B industry clients — you will find the deep dive in Data Foundation for B2B Industry.

Five Pitfalls in Customer-specific Search Indexes

These five mistakes surface regularly in architecture audits — and usually cost considerably more than a clean design up front.

#	Pitfall	What happens	What it costs
1	Visibility filter only in the frontend	The index returns the full assortment; the UI hides invisible hits	Wrong hit counts, wrong sorting, latent data leaks
2	List price in the index, contract price in the PDP	"Price ascending" sort produces customer-individually wrong order	Complaints, manual corrections in sales
3	Multi-tenant index without index lifecycle	Hundreds of indexes grow uncontrolled, cluster metadata tips over	Performance collapse, unplanned reindex migrations
4	ERP sync without idempotency	Doubly processed events let indexes drift apart	Creeping inconsistencies, hard-to-reproduce bugs
5	Representation rules / delegates ignored	Anyone purchasing for a colleague sees their own instead of the represented assortment	Wrong orders, shadow workflows by phone

Customer-specific Search is the point at which B2B eCommerce graduates from being a catalogue frontend to being a true contract interface. Our clients tackle this question precisely when their first key account expects a personalised view — and realise in the same moment that the answer hangs on three places simultaneously: index, pricing, sync. Those who build this cleanly now make the next contract escalation solvable in IT rather than in sales.
— Philipp Krueger, Co-CEO foobar Agency

Frequently Asked Questions

How current do prices in search need to be?

The answer depends on the contract type. Long-term accounts with annually negotiated conditions do not need second-level freshness — a nightly sync is sufficient. Project business with daily-negotiated prices, spot conditions, or dynamic volume discounts, on the other hand, requires sub-minute. In mixed assortments, differentiation per product category pays off: stable master data in batch, volatile prices event-driven. More important than absolute frequency is that the price in the result list matches exactly what applies in the cart.

How does this scale with many customers?

The scaling limit rarely lies in the index itself but in the sync path and the entitlement logic. Multi-tenant indexes scale well into the low four-digit range of tenants; beyond that, the advantages of a filtered index dominate. With contract prices, the critical figure is customers multiplied by articles with individual pricing — once that grows into the tens of millions, segmentation into pricing groups beats fully individual conditions.

What happens with representation rules and delegates?

In B2B day-to-day, buyers regularly operate "on behalf of" — for instance when a central purchasing department orders for several sites, or when a deputy covers for an absent colleague. In that case, search must evaluate the effective context (for which account, business unit, contract number is the search being performed?) — not just the user ID of the logged-in employee. Platforms like commercetools and Spryker model this via business units and account switchers in the UI; search must carry this context through every request and respect it in the index.

Architecture Workshop: Customer-specific Search

In a two-hour workshop, we clarify with you which index pattern fits your customer structure, how contract prices become visible, and which sync strategy holds between ERP, PIM, and search — along your platform and your contract landscape.

This post was first published on foobar.agency. https://foobar.agency/en/blog/customer-specific-search-kundenindividuelle-sortimente-preise

RFM and CLV: Who Your Most Valuable Customers Are — and Which Ones You’re Losing

Dominik Thalmeier — Thu, 11 Jun 2026 00:00:00 GMT

Most eCommerce organisations know with reasonable precision who bought a lot in the last quarter. They are less sure about who will buy a lot in the next quarter — and they are rarely able to identify the loyal customers who are quietly slipping away. A Customer Lifetime Value prediction closes exactly that gap: it turns order history into a robust expectation of how much revenue an individual customer will contribute over the next twelve or twenty-four months. In our work at foobar Agency, this step rarely fails because of the method. It fails because RFM analyses and CLV calculations sit side by side instead of building on each other. This article walks through the bridge from RFM to probabilistic CLV, explains what BG/NBD and Gamma-Gamma actually deliver in day-to-day operations — and shows which business decisions get made differently as a result.

We build on the first article in this series, which covered the Snowflake foundation as a shared data base — and we place the use case into the maturity path we keep seeing at retail and B2C clients across DACH.

RFM: Three Numbers That Say More Than a Dashboard

RFM stands for Recency, Frequency and Monetary — three metrics per customer derived from order history: When did this customer last buy? How often have they bought in a defined time window? What is the average value of their orders? In the classic variant, each of the three dimensions is split into five quintiles, and every customer gets a three-digit profile — from 1-1-1 (gone for a while, rarely bought, small amounts) to 5-5-5 (recently active, frequent buyer, high value).

What sounds dry is in practice often the first point at which marketing leaders see clearly who their most valuable customers actually are. The typical realisations: top-frequency customers are not automatically top-monetary customers. Reactivation candidates can be precisely scoped — not "all customers who haven't bought in 90 days", but "customers with historically high frequency whose recency score is now slipping into the second quintile". And marketing spending that was previously distributed evenly across the database gets its first proper hierarchy.

RFM has two limits worth knowing. First, it describes the past, not the future — today's 5-5-5 customer may already be a churner without showing it in the score. Second, it treats all customers with the same recency score as equivalent, even though a customer with 180 days of recency and a historical buying frequency of one month is a very different case from a customer with 180 days of recency and a frequency of six months. This is exactly where probabilistic models come in.

Probabilistic CLV: What BG/NBD and Gamma-Gamma Actually Do

Probabilistic CLV models treat every customer as an individual probability distribution — not as a point in a quintile grid. The standard setup in non-contractual eCommerce, meaning anywhere customers buy without a subscription or contract, consists of two models building on each other: BG/NBD for the question "how often will this customer buy again?" and Gamma-Gamma for the question "how much will they spend per order?".

BG/NBD — Beta-Geometric / Negative Binomial Distribution — was introduced in 2005 by Fader, Hardie and Lee as a pragmatic evolution of the older Pareto/NBD model (Schmittlein/Morrison/Colombo, 1987). Both models answer the same questions; BG/NBD is just considerably easier to estimate and more numerically stable. The core in two sentences: an active customer's purchase frequency follows a Poisson process with an individual rate; the probability that a customer drops out after a transaction follows a beta distribution. Only the transactions are observed — from those, the model derives the probability that a customer is still active and the expected number of their purchases in a future time window.

Gamma-Gamma models the average order value. The assumption is that a customer's expected order value scatters around an individual mean, and these means are gamma-distributed across the customer base. Important: Gamma-Gamma formally requires frequency and order value to be uncorrelated — an assumption that is checked before model training in practice, because it doesn't hold in every assortment.

The product of expected future order count (from BG/NBD) and expected order value (from Gamma-Gamma) yields the individual CLV forecast over a defined horizon. The standard implementation in Python is the `lifetimes` library by Cam Davidson-Pilon — it turns a transactional order table into a per-customer CLV value in a few steps.

What matters in day-to-day work: the output per customer is not a point estimate but a value with an indication of uncertainty. Marketing leaders who internalise that start asking different questions — not "how high is the CLV?", but "how confident are we that this customer is still active?".

A DACH Multi-Channel Retailer on Snowflake

For a DACH multi-channel retailer, we built exactly this bridge: RFM analysis and probabilistic CLV in one data model on Snowflake, transformed with dbt, with clean interfaces into marketing and service tooling.

Verankert. The starting point was a concrete business question from the marketing organisation: which share of the upcoming acquisition budget is genuinely worth spending on acquisition, and which share should actually go into retention? You can't answer that without CLV — and existing RFM reports only gave the answer from a backward-looking perspective. The project therefore did not start with the model, but with the business decisions the model was supposed to support: spending allocation between acquisition and retention, CRM triggers for reactivation, prioritisation of service cases by customer value.

Vernetzt. The data foundation sat in Snowflake — order data from the commerce system, returns, customer attributes from the CRM. A layer of RFM models was built in dbt: per customer, Recency, Frequency and Monetary, plus the quintile scores, plus a stable segment assignment. The probabilistic CLV calculation builds on the same layer: training and holdout time windows are defined in dbt, the actual model training runs in a Python environment against Snowflake (using Cam Davidson-Pilon's `lifetimes` library), and the predictions — expected purchases in the next twelve months, expected order value, the resulting CLV — flow back into the dbt model as new columns. Deterministic calculations (RFM quintiles, historical values) and probabilistic predictions (BG/NBD, Gamma-Gamma) sit in the same data table, side by side, with the same keys — and are consumed by service and marketing tooling through the same customer ID.

Vorausgedacht. The architecture is deliberately cut so that further predictions can be added without new data pipelines — next-best action, churn classification, category-specific CLV views. Snowflake is not "the data island for predictions" but the same data foundation that reporting and operational steering also live on. Marketing automation, service tooling and CRM campaigns consume the scores via regular reverse ETL or directly through live APIs — depending on the use case.

The value is measurable wherever the previous mode was gut feel: reactivation campaigns are targeted at customers with high predicted residual value — not at "all inactive customers". Service staff see customer value on escalations and decide differently. And acquisition budgets get a target value: we know what a new customer is worth on average — and can say whether a new channel is economically viable at all.

From Score to Stack: What Marketing and Service Do With It

A CLV prediction that only lives in the data warehouse is not a use case — it is a table. The value emerges when the numbers arrive in the systems where decisions are made.

Spending allocation. With customer-individual CLV, the expected value of a new customer can be calculated — segmented by acquisition channel, campaign or product category. If the average CLV of a new customer from channel A sits at a certain value and the CAC there exceeds it, that is no longer a gut decision but a number. The same applies to retention: what may a reactivation campaign cost per reactivated customer? Answer, again: the expected CLV of the reactivated cohort, weighted by reactivation probability.

CRM triggering. BG/NBD yields a per-customer probability of still being active. As soon as that probability falls below a threshold — and predicted residual value is high at the same time — a precise reactivation signal emerges. Instead of a broad "no order in 90 days" trigger, the CRM gets a value-weighted early-warning trigger.

Service prioritisation. In service escalations, customer value is a relevant input — more contentious, but relevant. When a service team knows that an incoming case concerns a high-value existing customer whose active probability is declining, it gets handled differently from a first-time buyer with a small basket. This is not autopilot — it is information that service leads use when appropriate.

Personalised communication. Frequency and expected order value are strong inputs for mailing cadence, recommendation logic and assortment curation. A customer with high predicted frequency does not need weekly newsletter pushes — they buy anyway. A customer with high CLV and low frequency often responds to targeted occasions (assortment launches, limited editions), not to volume communication.

CLV Compared: Heuristic, RFM-Based, Probabilistic

If you need a quick comparison of where you stand today and where the next step could take you, these three maturity levels are the stations we see again and again in projects.

Maturity	Method	Effort	Insight	Use case
Heuristic	Average order value × order frequency × margin × assumed lifetime	Days	Backward-looking, no customer differentiation beyond segment	Rough economic modelling, early strategy phase
RFM-based	Recency, frequency, monetary quintiles, segment-level CLV estimate derived from them	Weeks	Describes the past well, robust as a future signal but coarse	Reactivation campaigns, base segmentation in CRM
Probabilistic	BG/NBD + Gamma-Gamma (or comparable models), per individual customer	Weeks to months to set up, then ongoing operation	Individual predictions with uncertainty; separates active from likely inactive customers	Spending allocation, CRM triggering, service prioritisation

The important reading: this is not a contest. RFM remains in place even in advanced setups as a descriptive layer — it is the simplest language in which marketing and service teams talk about customers. The probabilistic layer sits on top; it does not replace it.

CLV changes the decision pattern more than it changes reporting. As soon as marketing spending and service prioritisation hang on an individual value expectation, an entire class of gut decisions falls away — and the conversation between marketing, sales and finance becomes a different one. That is the real value behind the methodology.
— Philipp Krueger, Co-CEO, foobar Agency

Frequently Asked Questions

What is the difference between Customer Lifetime Value and Customer Equity?

CLV is a customer-individual value — the expected future value contribution from one specific customer. Customer Equity is the sum of CLVs across all customers of a company; the metric values the entire customer base as an asset. In practice, marketing operates with CLV; Customer Equity is a steering metric for executive leadership and for aggregate-level discussions on acquisition and retention investment.

How much historical data do I need for a probabilistic CLV prediction?

A rule of thumb from practice: at least two complete purchase cycles of your typical customer — for consumables that can be twelve months, for durables more like 24 to 36. What matters is not only length but cleanliness: anonymous orders, returns, voucher transactions and employee accounts have to be cleanly separated from regular purchases, otherwise they distort the model estimates.

Does this work in B2B as well?

In principle yes, but with caveats. BG/NBD and Gamma-Gamma are optimised for non-contractual customer bases with many small transactions — classic B2C eCommerce. In B2B you often see few large orders per customer, longer sales cycles and account structures with multiple buyers behind a single customer number. That makes plain BG/NBD setups unstable in many cases. How the logic carries over to B2B structures with account hierarchies and longer time horizons is shown in Data Foundation for B2B Industry.

CLV Use Case Workshop

In two hours, foobar Agency walks through with you which RFM and CLV maturity level fits your data, your commerce stack and your marketing processes — with a concrete maturity check, not with slides.

This post was first published on foobar.agency. https://foobar.agency/en/blog/rfm-clv-prediction-wertvollste-kunden-erkennen

B2B Search Platform Comparison: Algolia, Constructor, Bloomreach, FactFinder, Coveo, Elastic

Matthias Dietrich — Mon, 08 Jun 2026 00:00:00 GMT

In the first part of this series, we showed why B2B search plays by its own rules: SKU hits before marketing logic, assortments tied to contracts, contract prices in the result list, punchout in foreign UIs. Knowing these requirements, you face a platform market that looks alike at first glance — and turns out to be very different at the second. Algolia, Constructor, Bloomreach Discovery, FactFinder, Coveo and Elastic are the six vendors we most frequently encounter in B2B projects at foobar Agency. They don't differ on whether they can do search — they differ on which B2B use case is supported natively, which runs via configuration, and what stack fit emerges from the licensing model. This article maps the six against the seven criteria from the first part — and says when each platform makes sense and when it doesn't.

Algolia: fast site search, strong merchandising

Algolia is probably the most widely deployed search platform in the DACH mid-market. API-first, excellent developer experience, well-documented InstantSearch libraries, and result lists at a latency the frontend team rarely needs to worry about. What often gets underestimated in platform comparisons: Algolia significantly expanded its merchandising backend in 2024/2025. The Merchandising Studio with Visual Editor allows drag-and-drop control of result lists and category pages, Smart Groups bundle curation logic across Search, Categories and Collections, and AI re-ranking as well as Generative Shopping Guides are in production in 2025. For merchandiser teams that want to work without an engineering ticket, that's a real lever.

In B2B, Algolia addresses the core requirements via account-level personalisation, filtered indices by entitlement, and customer-specific pricing configurations — the documentation on B2B catalogue management describes these patterns explicitly. Entitlement logic, contract price indices and customer-specific assortments are fed in at the backend and maintained in the index. Algolia provides reliable mechanics for that; the concrete workflow for complex B2B scenarios moves into your architecture.

Licensing: Algolia charges per search request and per indexed record, with transparent list pricing from the Grow tier upward. In B2B setups with customer-specific indices, the record count grows multiplicatively — that belongs in every TCO calculation. Stack fit is high for composable setups with commercetools, Spryker or a custom storefront where search and merchandising logic are orchestrated in your own frontend. Anti-recommendation: if you expect an out-of-the-box B2B workflow for complex contract price indices and punchout connectors without building your own backend logic, the specialised B2B platforms are the faster path.

Constructor: B2B-specific, KPI-driven

Constructor positions itself explicitly as an enterprise eCommerce platform for search and product discovery — and has systematically built out B2B functions over the past two years. Account-segmented prices and availabilities, part number search, dynamic facets, and optional searching across out-of-stock articles are documented features of the B2B solution. Forrester listed Constructor as a Leader in the Wave Commerce Search and Product Discovery Solutions, Q3 2025; Gartner also as a Leader in the Magic Quadrant 2025. Both are marketing material — but two independent analyst houses placing Constructor as a serious B2B player.

The difference from Algolia is the approach: Constructor doesn't optimise on relevance scores but explicitly on conversion, revenue or margin targets. For a B2B shop with repeat-purchase behaviour and customer-specific assortments, that can be a meaningful lever — the question is always whether the KPI optimisation model is sufficiently trained on B2B-typical search patterns (SKU lookups, re-order, punchout). In foobar projects, we see the best Constructor results at distributors with large assortments and a clearly measurable order-conversion funnel.

Licensing: usage-based, tiered by search volume and feature set, individually negotiated at enterprise level. Stack fit: high for B2B distributors and industrial shops with large assortments, a repeat-purchase share and a composable storefront. Anti-recommendation: if your main need is a straightforward site search replacement for a manageable assortment, Constructor is over-dimensioned both in price and concept.

Bloomreach Discovery: strong in merchandising and SKU logic

Bloomreach Discovery historically comes from retail-driven merchandising — Bloomreach is a Leader in the Gartner Magic Quadrant 2025 and is also in the Leader group of the Forrester Wave Q3 2025. For B2B, Bloomreach has added specific features in recent releases: SKU Select for SKU-precise ranking, Enhanced Lookups for order and part numbers with special characters, NLP understanding of quantitative measures ("3/4 inch wire" as an example from the documentation). In 2025, Variant Slicing was added as a beta — finer-grained control of variants as standalone hits.

In B2B projects, Bloomreach is especially strong where merchandiser teams actively curate result lists — curated lists, boost rules, seasonality. For pure SKU lookups, it's over-dimensioned; for an assortment where technical search and merchandising control come together, it's a very serious candidate. Customer-specific assortments and contract prices are addressable via Bloomreach Profiles and index filters but, as everywhere, need clean data feeds from ERP, PIM and pricing engine.

Licensing: enterprise SaaS with annual contracts, no public price list. Stack fit: high for B2B retailers and hybrids with mixed assortments where merchandising is actively run. Anti-recommendation: if you're looking for a lean headless search API for a clearly defined technical use case, Bloomreach is too heavy for the feature set.

FactFinder: B2B from Pforzheim, DACH-market-specific

FactFinder is the DACH-native vendor in this comparison. Pforzheim-based OMIKRON Data Quality GmbH has run the platform in commerce projects for more than two decades; by their own numbers, over 2,000 shops are in production — references like OBI, STIHL, Intersport and Bauhaus show the DACH anchoring. The technical strength sits where other vendors with English-language defaults struggle: German compound words, norm designations, technical synonyms and domain-specific industry terms. Anyone curating product data in German industrial language can tell the difference between "elf-mm-schraube" and "M11 verzinkt" in result relevance.

B2B isn't an extension module for FactFinder — it's part of the product core. Account-specific assortments and visibility, customer-specific prices with contract reference, location-based availability and AI-driven re-order suggestions based on order history are documented features. Hybrid search combines exact, fuzzy and vector — SKU hit strength remains, semantic extension comes on top. EU hosting with data-processing agreement is standard, which delivers arguments other vendors only have to demonstrate via configuration in data-sensitive industrial setups.

Licensing: enterprise SaaS, individually negotiated by search volume and feature set, no public price list. Stack fit: high for DACH-region B2B distributors, industrial manufacturers with German-language assortments and retailers with mixed B2C/B2B business. Anti-recommendation: if your business is primarily English-language and international, FactFinder's DACH strengths matter less — the global platforms tend to have the edge there.

Coveo: enterprise search, B2B as a strength

Coveo comes from the enterprise search world — and it shows in the product. Coveo was named a Leader by Gartner in 2025 for the second consecutive year in the Magic Quadrant for Search and Product Discovery. The platform supports commerce search as well as knowledge and support search, which in B2B contexts with configurators, technical datasheets and service portals can be a real advantage — one search, one index, multiple touchpoints. Coveo added "Coveo Relevance Generative Answering" on a RAG basis in 2024/25; for B2B with product documentation and configuration advice, that's a substantial extension beyond classical result lists.

For customer-specific assortments, entitlements and contract-bound visibility, Coveo brings the engineering DNA you'd expect from an enterprise search platform: fine-grained security trimming models, source connectors, custom re-ranking pipelines. The flip side is complexity: Coveo implementations are more involved than Algolia or FactFinder setups, and the value contribution only materialises when you actually use the strengths.

Licensing: enterprise SaaS, individual contracts, pricing not public. Stack fit: high for B2B companies with a service and knowledge layer alongside the commerce shop, high assortment complexity, document-heavy advisory work. Anti-recommendation: if the use case is a classical B2B shop without a service portal and without knowledge search, you buy Coveo functionality that's expensive and underused.

Elastic: engine, not a product

Elastic is the special case in this group — and one that's often misunderstood. Elasticsearch is the engine on which a significant share of modern search runs (including in the backend of some vendors listed here). With "Elastic Enterprise Search", Elastic has bundled a product layer over the past few years; the vector search and semantic search functions introduced in 2024 bring a semantic search layer that's attractive for technical assortments.

From a B2B perspective: Elastic is maximum flexibility — and the highest custom-build effort. Customer-specific assortments, contract price indexing, punchout integration are all technically possible but they aren't the product. They're what you build on Elastic. For companies with a strong engineering team, very individual search requirements or an architecture where search is deeply woven into custom backend services, Elastic is a legitimate candidate — also because the stack can run on-premises or in your own cloud, which can be an argument for data-sensitive industrial setups.

Licensing: open-source core, commercial subscriptions (Standard/Gold/Platinum/Enterprise), Elastic Cloud by resources. Stack fit: high for companies with their own engineering team and requirements on data sovereignty or stack depth. Anti-recommendation: if you don't want to maintain engineering capacity for a search platform, Elastic is the wrong lever — then the specialised SaaS platforms are the faster path.

Comparison matrix: six platforms, seven criteria

The following matrix scores the six platforms along the criteria from Post 1. The scale is deliberately coarse — three levels are enough to cut a shortlist cleanly. Two of the criteria come up repeatedly in platform briefings — so here is what we mean by them:

Contract prices in the result list means: the individually agreed price for the authenticated buyer — depending on contract, account or customer group — is already shown in the search result list, not only when clicking through to the product detail page. In B2B this is not a comfort feature but the precondition for filters, sorting and comparisons in the result set to work meaningfully at all. Behind the scenes this is delivered either via precomputed contract prices in the search index or via a synchronous call to the pricing engine at query time — both variants have their place and are decided by data volume, refresh frequency and latency requirements.

Punchout compatibility means: the supplier platform's search API delivers clean results even when the buyer is not in the supplier shop but in their procurement system (SAP Ariba, Coupa, Microsoft Dynamics 365 Supply Chain). In the most common variant — cXML Level 2 — the supplier's search is rendered inside the procurement UI. For the search platform that means: stable API, correct contract prices even in a foreign context, correct customer-specific assortments. None of the platforms named here ships native punchout connectors — integration is a project-specific task each time and should be honestly budgeted in the platform decision.

On the rating scale: "Strong" means the criterion is met natively or via a documented standard workflow. "Via configuration" means the criterion can be met — via standard extensions, platform configuration or curated index structures, with a deliberate implementation step. "Via custom build" means the criterion is technically feasible but has to be planned as an engineering project in the stack. None of the three levels is negative — they are three legitimate implementation paths with different investment profiles.

Criterion	Algolia	Constructor	Bloomreach	FactFinder	Coveo	Elastic
SKU / part-number search	strong	strong	strong	strong	strong	via configuration
Customer-specific assortments	via configuration	strong	strong	strong	strong	via custom build
Contract prices in result list	via configuration	strong	via configuration	strong	strong	via custom build
Punchout compatibility	via custom build	via configuration	via configuration	via configuration	via configuration	via custom build
Semantic / NLP search	strong	strong	strong	strong	strong	via configuration
Merchandising / curation	strong	strong	strong	strong	strong	via custom build
License / TCO in B2B	medium	high	high	medium–high	high	variable

The ratings are to be read in foobar's implementation context: they reflect not what is theoretically technically possible, but what arrives in a project with reasonable effort and stable operation.

The platform decision in B2B projects rarely settles on a feature spec sheet. It settles on three questions: how deeply do contract prices and assortments live in your ERP, how much engineering do you want to keep for search itself, and where should search stand in five years? Answer those three before the RFP and you arrive at a shortlist of two platforms instead of six — and you save yourself half a year of comparison workshops.
— Matthias Dietrich, CEO foobar Agency

Frequently asked questions

Which search platform is the cheapest?

"Cheapest" is the wrong question in B2B — the search licence is rarely the dominant cost block. Algolia has a transparent list-price model, all others are negotiated in the enterprise space. More decisive for TCO are implementation effort, ERP integration, index maintenance and re-ranking logic. A platform that's cheap on licence and expensive on custom development costs more in the end than a specialised B2B solution.

Can we keep the search from our shop system?

For manageable assortments and simple customer-group structures, often yes — it depends on the shop system. commercetools, Spryker and OroCommerce have built-in search endpoints that cover many standard cases. As soon as customer-specific assortments in result lists, contract prices as sort criterion or punchout scenarios come into play, shop-system search usually hits limits. The more honest question is: which search use case is painful today, and where do you want to stand in 24 months?

What does a migration to a dedicated search platform cost?

Reliably only estimable in a discovery project. Drivers are: assortment size and number of language/country indices, complexity of the entitlement logic, ERP and PIM integration, pricing-engine integration, frontend adaptation. In foobar projects, we see B2B search migrations typically as three- to six-month implementations with a clear roll-out sequence — rarely as a big bang, almost always with a pilot assortment or a pilot market.

B2B Search Platform Selection

In a two-hour discovery workshop at foobar Agency, we cut the platform shortlist for your B2B stack — along your assortment structure, your contract logic and your ERP integration. Anchored in your processes, networked with your data, engineered for the next architecture steps. In the next post of the series, we show how customer-specific assortments are technically integrated into search — preview of Post 3: Customer-specific Search. If the data side concerns you as much as the search selection, take a look at the parallel series: Snowflake foundation for commerce data.

This post was first published on foobar.agency. https://foobar.agency/en/blog/b2b-suche-plattform-vergleich-algolia-constructor-bloomreach-factfinder-coveo-elastic

Snowflake in Commerce: From Data Silo to Shared Architecture

Dominik Thalmeier — Thu, 04 Jun 2026 00:00:00 GMT

Commerce data lives in silos. The shop knows the order, the ERP knows the delivery, the CRM knows the contact, the marketing stack knows the campaign, the service tool knows the case — and each of these worlds carries its own definition of what "customer" and "revenue" actually mean. For CDOs and CIOs this becomes visible the moment CLV reports, margin analyses and campaign ROI sit side by side and contradict each other. A data foundation on Snowflake with dbt modelling is the answer we have built most often in DACH commerce projects in recent years — because it resolves exactly this contradiction without forcing a redesign of the operating model. This article shows why commerce data is fragmented, what changes once a shared architecture is in place, and how Snowflake differentiates itself from BigQuery, Databricks and Redshift.

Why commerce data is fragmented

The data landscape in commerce has grown over years, not been designed. With retailers and industrial manufacturers, we typically see five to seven operational systems, each of which works well on its own but shares no common data model: shop platform (Shopware, commercetools, Spryker), ERP (SAP S/4HANA, Microsoft Dynamics, Infor), CRM (Salesforce, HubSpot, Dynamics 365), marketing stack (Klaviyo, Emarsys, Adobe Campaign), service tool (Zendesk, Salesforce Service Cloud), PIM, and in many cases a subscription or loyalty system.

Each of these systems writes its own truth. The shop closes an order with gross revenue; the ERP books it net, with discounts, cancellations and returns; the CRM only knows the contact event. The consequence is not just a reporting problem — it's a definition problem. Marketing optimises against gross revenue, controlling calculates net margin, sales measures pipeline. Three pillars, three truths.

On top of that comes the identity problem. In B2C, a customer is often known under five different identifiers in five systems — guest order in the shop, email hash in the marketing stack, customer number in the ERP, account in the CRM, ticket ID in service. In B2B it becomes more complex: buying centres, multi-branch structures and contract-based assortments mean that a "customer" can also be a hierarchy. Anyone calculating CLV without clean identity resolution is systematically wrong on the sum.

As long as these systems only exchange data among themselves — point-to-point integrations, nightly exports, BI tools with proprietary connectors — complexity grows quadratically. Each new source means n new connections. A shared data layer reduces this to 1:n.

Snowflake and dbt as a shared data layer

Snowflake is a cloud data platform with separated compute and storage: data sits once, workloads run in independent virtual warehouses. That is the technical precondition for marketing, controlling, data science and BI to work on the same dataset simultaneously without blocking each other. dbt (data build tool) adds a declarative modelling layer in SQL on top — version-controlled in Git, with tests, lineage and documentation.

In foobar projects we work with four layers that have become the de-facto standard in the dbt community:

- raw — the unchanged ingestion tables from source systems, loaded via connectors such as Fivetran, Airbyte or Snowpipe. - staging — typed, renamed, uniquely referenced versions of the source tables. One staging layer per source system. - intermediate — joins, identity resolution, business logic that is not yet report-ready but is reused as a building block. - marts — domain models: `marts.commerce`, `marts.marketing`, `marts.finance`. This is where the tables sit on which dashboards and AI models are built.

This layering is conceptually close to the "Bronze/Silver/Gold" logic from the Databricks lakehouse vocabulary; in the dbt world the terms raw/staging/intermediate/marts are more common. Equivalent in content, cleaner terminology for a Snowflake setup.

What changes concretely once the foundation is in place: CLV, revenue and margin have exactly one definition. The `dim_customer` table in `marts.commerce` is the single source of truth — marketing automation, service routing, forecasting and board reporting all draw from the same source. Metrics are defined once in dbt and consumed identically everywhere. Discussions about whose number is correct don't end because people start calculating the same way — they end because the model is authoritative.

Architecture sketch: sources, layers, applications

A commerce data foundation on Snowflake can be thought of in three columns — sources on the left, Snowflake layers in the middle, applications on the right. On the source side: shop, ERP, CRM, marketing stack, service and PIM. Via connectors their tables land in `raw` — a schema-stable mirror of the source, ideally with change data capture so that changes, not just end states, arrive.

In the middle, dbt models the staging layer (typing, renaming), the intermediate layer (joins, identity resolution, sessionizing) and the marts layer (dimensions and facts per domain). This is where the central tables emerge: `dim_customer`, `dim_product`, `fct_orders`, `fct_marketing_touchpoints`, `fct_service_cases`. dbt tests monitor uniqueness, completeness and value ranges; the generated documentation shows where each column originates.

On the application side, four typical consumer groups draw from the same data model: BI tools (Looker, Tableau, Power BI) for reporting; marketing automation for segments and campaigns; operations and service for real-time lookups; data science for models like CLV, churn and next-best-action. Snowflake Cortex extends this layer with native ML and LLM functions that operate directly on the modelled tables — without exporting data into a separate ML platform.

This architecture is not spectacular. It is anchored in business processes, networked between the commerce and intelligence layer, and forward-thought because new sources or applications attach to the foundation instead of producing another point-to-point connector.

Snowflake, BigQuery, Databricks, Redshift: three decision criteria

The question of which platform is the right one cannot be answered off the cuff. It depends on three criteria we work through consistently in architecture workshops.

First: multi-cloud. BigQuery is tightly bound to Google Cloud, Redshift to AWS, Azure Synapse to Microsoft. Snowflake runs natively on AWS, Azure and GCP — the same account can host workloads on different cloud providers. For DACH groups with hybrid cloud strategies (for example SAP world on Azure, analytics on AWS) this is a real difference. Databricks is multi-cloud as well, but functionally a lakehouse, not a classical warehouse — its strengths sit with streaming, Spark workloads and ML platforms.

Second: workload separation. Snowflake's separated virtual warehouses mean that a BI dashboard, a nightly dbt run and an ad-hoc data-science notebook scale independently of each other. With BigQuery, slots are shared; with Redshift, you scale clusters or use serverless. Anyone with many competing workloads — reporting, marketing automation, forecasting, ML training — gets the simplest isolation with Snowflake.

Third: data sharing. Snowflake shares data across accounts without copying it. In a commerce context that means supplier data, POS data from retail partners or market research feeds can be incorporated live. For retailers with marketplace strategies or industrial manufacturers with dealer networks, this is a function for which BigQuery (Analytics Hub) and Databricks (Delta Sharing) have counterparts, but where Snowflake is the most mature.

None of these arguments makes Snowflake the universally correct choice. But they are the three questions that most decisions can be tied to with confidence.

Five signs your commerce data needs a foundation

If you need a quick check in an architecture review — these five signs are the ones we most often see trigger a foundation project.

#	Sign	What it means
1	Marketing, sales and controlling each report a different revenue figure	Definitions are misaligned; each source calculates differently
2	A new campaign needs two weeks of data lead time	Identity resolution and segmentation happen manually, not in the model
3	CLV exists as a concept, but as a number only in PowerPoint	There is no productive table that multiple teams consume
4	Each new data source requires a new connector to each destination	Point-to-point integration instead of a central data layer
5	BI reports and marketing segments diverge	No shared dim_customer; each tool reads from its own source

Industry case: RFM-based CLV at a DACH multi-channel retailer

A multi-channel retailer from the DACH region with its own TV, online and app presence built a customer lifetime value prediction on Snowflake and dbt with foobar Agency. The starting position was typical: order data in the ERP, contact events in multiple marketing tools, master data in the CRM, customer service data in a third system. A consistent statement about customer value across reports was not achievable.

The foundation was built in three steps. First: identity resolution. Orders, contact points and service cases were merged into a unique `dim_customer` identity via deterministic keys (customer number, hashed email, phone number) and probabilistic fallbacks. Second: RFM calculation. On the fact table `fct_orders`, recency, frequency and monetary value per customer are calculated in dbt — deterministically, traceably, secured against definition drift by dbt tests. Third: probabilistic CLV prediction. Based on the RFM features, a model from the BG/NBD and Gamma-Gamma family estimates the expected number and expected value of future purchases per customer.

The result is not a dashboard, but a table: `marts.commerce.customer_clv` contains for each customer a recency value, an RFM segment, a historical value and a probabilistic prediction. Marketing uses it for segments and routing, service uses it for escalation routing, controlling uses it for cohort reporting. Same table, same definition — no more database tourism between teams. How the RFM-based CLV logic works in detail, and why it favours probabilistic models over pure ML black boxes, is covered in RFM and CLV: Who Your Most Valuable Customers Are.

A data architecture only becomes a foundation when three teams from three worlds pull the same number and no one has to ask whose definition applies. Snowflake and dbt are not magic — they force us to write definitions cleanly once and then make them productive. The effect shows up in every project first where CLV, margin and campaign ROI used to drift apart.
— Dominik Thalmeier, Team Lead Data Science foobar Agency

Frequently asked questions

Do I need Snowflake if I already have BigQuery?

Not necessarily. If your world sits entirely in Google Cloud and workload separation is not a problem, BigQuery is a valid choice. Snowflake becomes relevant when workloads are distributed across AWS, Azure and GCP, when competing workloads slow each other down, or when you want to share data cross-account. The modelling logic in dbt works on both platforms — a migration between the warehouses is feasible, but not a trivial weekend project.

How long does a Snowflake setup take in a commerce context?

A productive minimum setup with three to four connected sources, raw/staging/intermediate/marts layers and a first domain-specific marts layer (for example commerce) typically takes us twelve to sixteen weeks. The precondition is that source systems are clearly defined and a data owner is named per source. Identity resolution and AI use cases such as CLV prediction follow afterwards in iterative steps — they are not a prerequisite for step one.

What does Snowflake cost in a commerce context?

Snowflake is consumption-based: you pay compute credits per warehouse runtime used and storage per data volume. In a commerce context with a well-modelled dbt pipeline and cleanly configured virtual warehouses (auto-suspend, size tuning), running platform costs are usually well below the tool costs caused by redundant BI, CDP and analytics stacks. Reliable numbers only emerge after a workload assessment — flat monthly figures without a workload profile are rarely meaningful.

Data foundation workshop

In two hours at foobar Agency we clarify with you which sources your foundation has to carry, which metrics can be resolved first and whether Snowflake, BigQuery or Databricks fits your cloud landscape — hand on the architecture diagram, not on slides.

This post was first published on foobar.agency. https://foobar.agency/en/blog/snowflake-im-commerce-vom-datensilo-zur-gemeinsamen-architektur

Why B2B Search Plays by Its Own Rules

Matthias Dietrich — Mon, 01 Jun 2026 00:00:00 GMT

When a buyer types “M8x40 galvanised” and nothing comes back, you don’t lose a click — you lose an order.

B2B search is often treated like B2C search with different products. That tends to work for a while — until the first major customer demo, when their part numbers return no hits, their contract prices fail to appear in the result list, or their custom-approved assortment suddenly shows items they aren’t allowed to order.

In B2B implementations at foobar Agency we see this pattern recur year after year: search is planned last, often inherited from the shop system — and becomes the first point at which buyers leave the platform. This article lays out seven traits that separate B2B search from B2C, and what they mean for architecture, platform choice and ERP integration.

Professionals search differently

B2B buyers usually know what they want. In B2B implementations at foobar Agency we routinely see a significant share of search queries that aren’t generic product terms but rather SKUs, part numbers, norm designations or technical measurements. A search for “M8x40 galvanised” isn’t browsing behaviour — it’s direct access to a known item in the assortment.

This has consequences for ranking: in B2C, exact match is one component alongside personalisation, sales data and trends. In B2B, an unambiguous SKU or part number search must almost always surface the exact item at the very top — before synonyms, recommendations or personalisation models step in. Search platforms that optimise their ranking primarily on click-through behaviour run into a use case they rarely serve well: professionals click because they have to, not because the ranking convinced them.

Then there’s re-order behaviour. A large share of B2B orders are repeat purchases. B2B search is therefore often not a discovery tool but a fast access path to known items — and should behave accordingly. What your search logs reveal — which part numbers don’t hit, which synonyms are missing, which repeat searches fail — is one of the most precise data foundations a B2B shop has. Anyone who doesn’t analyse it leaves revenue potential buried in the index.

Assortment is personal

In B2C, personalisation means preferences, recommendations, curated picks. In B2B, it means something fundamentally different — it’s a matter of entitlement, not taste. Which items a buyer is allowed to see at all depends on the customer contract, account configuration, regional approvals and sometimes even the role of the employee within the customer organisation.

Platforms like commercetools, OroCommerce and Spryker model this logic through customer groups, business units or company hierarchies, and contract-bound price and catalogue lists. For search, that means the index must reflect the individual assortment of the authenticated buyer — not the shop’s total catalogue. An item a particular customer isn’t allowed to order has no business appearing in their result list. Not even as a greyed-out, “available on request” hit — that produces complaints, not orders.

Architecturally there are three common patterns: multi-tenant indices (one index per customer group), filtered indices (one shared index with visibility filtering at query time), and server-side re-ranking after the query. Which pattern holds depends on how large your assortment is, how many customer-specific assortments you serve and how often contracts change. The question is decided by scale and performance — and should be answered before the platform choice.

Price is a contract matter

In B2B, different customers see different prices for the same item — and they see them not first on the product detail page but in the result list. Sort functions, filters and comparisons all hinge on that price. Anyone showing list prices in the result list and only fetching the contract price on click is sorting their result list incorrectly across every search query.

There are two architectural options. First: contract prices are pulled at query time from the ERP, the pricing engine or a caching layer and injected into the result list — which means latency and load. Second: contract prices are precomputed and written into the search index, per customer or customer group — which means index size and update frequency. Both paths are valid. Which one holds depends on the number of customers, the volatility of prices and the requirement for real-time consistency.

What doesn’t hold is the third option: showing only list prices and asking the customer to “verify the final price in the cart”. That is the point in live demos where CIOs stop following along.

Context matters: Punchout, configurators, ERP

B2B search doesn’t end at the shop domain. Via cXML — introduced by Ariba in 1999 and SAP-owned since the 2012 acquisition — and OCI, a SAP standard that has established itself as the de-facto norm in e-procurement, buyers land in the supplier catalogue from their ERP procurement tool. SAP Ariba supports both protocols; Coupa and Microsoft Dynamics 365 Supply Chain rely primarily on cXML. With the Level 2 variant of cXML, search and result rendering run directly inside the Ariba UI — hits from the supplier catalogue are rendered in the procurement interface without the buyer leaving the Ariba session. A B2B search must be API-capable for this and produce usable results in foreign UI contexts — including the correct contract prices.

Configurator-driven products are the second special case. An assortment where variants only emerge through selection — lengths, materials, coatings, tolerances — can’t work with classic SKU indexing. Search has to either bypass the configurator (base SKU as the hit, configuration on the PDP) or include the most common configuration variants as virtual SKUs in the index.

Third: stock and lead time. The Sana Commerce B2B Buyer Report 2025 names lack of transparency on inventory and delivery times as buyers’ most important frustration — 40 percent of respondents rank it as their top issue. Search results without current stock data produce orders that collapse at the confirmation stage — and damage trust, which in B2B takes longer to rebuild than a click takes to lose.

Seven requirements B2C search doesn’t meet

If you need a quick check in a platform evaluation, these seven requirements regularly separate the search that holds in B2B from the search that merely runs.

Requirement	Rationale
SKU and part number search with exact-match priority	Professionals type article numbers — not descriptions.
Technical facets: norms, materials, dimensions, units of measure	B2B filters are technical specifications, not style options.
Customer-specific assortments (entitlement logic)	What a customer sees is a matter of contract, not preference.
Contract prices in the result list	Filters and sorting depend on the individual price.
Re-order cues and order history	Repeat purchases make up a large share of B2B volume.
Punchout compatibility (cXML Level 2, OCI)	Search must function within foreign procurement systems.
Multilingual technical terminology	DIN/ISO designations and industry jargon don’t translate like marketing copy.

B2B search is the underestimated lever. It sits at the point where contract prices, assortments and buyer behaviour converge — and it’s the first step at which many B2B platforms break their promise. Anyone who builds it well builds in the next three years of growth.
— Philipp Krueger, Co-CEO, foobar Agency

Frequently asked questions

Is the search from my shop system enough?

For small to mid-sized assortments and simple customer-group structures, often yes. As soon as you work with customer-specific assortments, contract prices in result lists or punchout integrations, shop-system search tends to hit limits — either on performance or on the differentiability of indexing.

What’s the difference between site search and enterprise search?

Site search is optimised for a single storefront context: one assortment, one tenant, one index. Enterprise search is built for multi-tenant, multi-permission and multi-source complexity — different assortments, different visibility rules, integration with several data sources. For most B2B setups, a site search platform with a B2B extension is the more pragmatic path than pure enterprise search.

Which search platforms are common in B2B?

In the DACH market we most commonly see Algolia, FactFinder, Constructor, Bloomreach Discovery, Coveo and Elastic — each with different strengths against B2B requirements. In the next post of the series, the B2B search platform comparison, we compare the six against the seven criteria from this article.

B2B Search Architecture Workshop

In two hours, foobar Agency works with you to determine which search architecture fits your assortment, your contracts and your ERP — hands on the platform options, not slides.

This post was first published on foobar.agency. https://foobar.agency/en/blog/warum-b2b-suche-eigene-spielregeln-hat

From Collaboration to Partnership: foobar Agency and Snowflake Seal Their Partnership

Matthias Dietrich — Wed, 27 May 2026 00:00:00 GMT

Years of collaboration have led to an official partnership: As of today, foobar Agency is a member of the Snowflake Partner Network. The Munich-based agency has been building Snowflake-based data architectures for commerce and industrial companies for years—this new status now formalizes what has long been a reality in their day-to-day operations.

foobar Agency has been using Snowflake as the central data platform in client projects for several years—from initial data modeling with dbt through deterministic calculations to probabilistic AI predictions such as customer lifetime value, churn indicators, and next-best-action recommendations. One reference project is the RFM-based CLV prediction for Home Shopping Europe (HSE), in which deterministic calculations and AI predictions were combined within a shared Snowflake architecture.

foobar Agency does not carry out data projects exclusively in conjunction with commerce architectures. Standalone Snowflake initiatives for B2B sales, service analytics, forecasting, and after-sales for industrial clients are also part of the portfolio—even in cases where the commerce stack remains unchanged or is not the focus of the project at all. The integration of commerce and data remains the agency’s specialty, but it is not a prerequisite: Snowflake projects are also set up as pure data mandates.

With the official partnership, foobar Agency gains direct access to Snowflake’s technical programs, certifications, and roadmap information. For clients, this means a faster path to new data capabilities as well as closer coordination on platform-related architectural decisions.

The partnership fits into the agency’s integrated offering as an enhancement of the data layer. In conjunction with commerce projects, Snowflake, together with commercetools, forms the architectural foundation—embedded in a composable architecture with complementary partner solutions for content, search, and discovery. In pure data projects, Snowflake stands alone at the center.

“For us, Snowflake is not a downstream reporting tool, but an integral part of the platform on which our clients run commerce and data together,” says Philipp Krueger, Co-CEO of foobar Agency. “The official partnership gives our projects a direct line to the Snowflake roadmap—this benefits clients who want to scale their data strategy above all.”

"Data-driven work pays off for companies in two ways—in terms of costs and revenue," says Dominik Thalmeier, Team Lead Data Science at foobar Agency. "Specifically, this means, for example: more accurate provisions, more precise forecasts, and more efficient marketing spending on the cost side—and CLV-based customer engagement and highly targeted personalization on the revenue side. With the official Snowflake partnership, we’re able to leverage these opportunities more quickly in client projects."

About foobar Agency

foobar Agency is an owner-managed digital agency based in Munich. Since its founding in 2015, it has been implementing complex B2C, B2B, and D2C commerce solutions as well as digital experiences for manufacturers, retailers, and brands in the DACH region—based on commercetools and Snowflake in a composable architecture.

This post was first published on foobar.agency. https://foobar.agency/en/blog/aus-praxis-wird-partnerschaft-foobar-agency-und-snowflake-besiegeln-zusammenarbeit

How Do I Choose the Right eCommerce Agency for B2B? 7 Questions You Should Ask – Before You Hire

Matthias Dietrich — Mon, 25 May 2026 00:00:00 GMT

A B2B commerce project is not a website redesign. It's a strategic investment in your sales infrastructure. Choosing the wrong agency doesn't just cost money—it costs years. Five years of a bad system means lost market share, sales frustration, and customer churn.

Finding the right agency is harder than it looks. The market is fragmented. There are web agencies posing as commerce experts. There are pure technology partners with no business understanding. And there are agency networks who prefer one vendor with no real alternatives to offer.

These 7 questions help you separate the wheat from the chaff.

Question 1: What B2B References Do You Have in My Industry or Similar Industries?

The first question is a screening question. B2B and B2C are fundamentally different. An agency that built 50 successful D2C stores won't understand your requirements.

What you want to hear:

Projects in manufacturing, wholesale, or distribution
Companies of a similar size to yours (a 500-person company has different problems than a 5,000-person enterprise)
Names you can verify (not "several DAX companies"—actual references)

Red flag: "We do everything—D2C, B2B, B2C, marketplaces for startups, small and medium-sized businesses, and large corporations." A company that does everything equally well does nothing right.

Question 2: How Do You Approach ERP Integrations – and Which Systems Do You Know?

This is the technical knockout question. A B2B eCommerce platform without strong ERP integration is an expensive toy.

What you want to hear:

Concrete integration experience with SAP, NetSuite, Microsoft Dynamics, Sage, or the systems standard in your industry
Clear understanding of how inventory, pricing, customer master data, and orders flow from ERP to shop
Experience with typical pitfalls: synchronization delays, pricing management at customer group level, customer-specific terms

Red flag: "Yes, ERP integration works. It's just an API connection." Anyone who talks like that has never integrated a large ERP. It's always more complex.

Question 3: Does the Agency Work With Systems It Knows From Real Projects – or Does It Recommend Technologies It Has Never Used in Production?

There is a significant difference between a demo environment and a production system with ERP integration, 50,000 SKUs, and five price lists. Demand project references for exactly the system setup that's relevant to you.

What you want to hear:

Concrete production projects with the recommended platforms – not training environments or certifications
A clear statement about which systems the agency knows deeply and why
Honesty when a system falls outside their core expertise – and a plan for that

Red flag: "We can handle all platforms." Breadth without depth is the most dangerous promise in B2B commerce. An agency that claims to do everything typically knows none of the systems well – and learns on your project, at your expense.

Question 4: What Does Your MVP Process Look Like – and How Quickly Can We Go Live?

MVP thinking is the core of modern B2B commerce projects. A good agency should have a clear framework for fast, iterative launches.

What you want to hear:

A structured process for MVP definition (scope, data cuts, Day 1 features)
Realistic timelines (a few months for a true MVP, not six months to a year for a "quick start")
A plan for Phase 2, Phase 3—not just the first launch

Red flag: "The MVP will take 12 months." That's not an MVP. That's a full system with a new name.

Question 5: How Do You Support Us After Go-Live – and What Does That Cost?

Launch is Day 1, not the end. You need an agency that doesn't leave you alone afterward.

What you want to hear:

A clear support model (ranging from bug fixes to strategic development to expanding the internal team)
Transparent pricing for post-launch services (module-based: bug fixes, feature development, performance optimization)
A perspective on long-term partnership, not just a project

Red flag: "After launch, you're on our support line—that costs extra." That's normal. Problematic is only if support pricing isn't clearly defined upfront.

Question 6: Can You Do Strategy AND Implementation – or Just One?

Some agencies are strategy-only (they advise, but don't implement). Others are implementation-only (they build but can't advise strategically).

What you want to hear:

An integrated team: business strategist, solution architect, tech lead in the same boat
Concrete cases where strategy determined project success
Clear understanding that technology is just the tool—strategy is what's decisive

Red flag: "We're the strategy partner—implementation is another team." That creates diffused responsibility. You want one team accountable for success.

Question 7: How Do You Integrate Data and AI into Commerce Projects?

This is the future-proofing question. B2B commerce 2026+ will be data-driven. AI personalization, customer churn predictions, dynamic price optimization—that will be standard.

What you want to hear:

Experience with data pipelines (ERP → data lake → commerce)
AI deployments in production systems (not just proof-of-concept)
Clear roadmap understanding: "This isn't relevant for Day 1, but important for Phase 2 and 3."

Red flag: "AI is too early for you." That might be true—but a future-proofed partner should at least know how to build it in later.

What Bad Agencies Often Say

"We do everything equally well."
"That's your requirements problem, not ours."
"This platform is best for everything."
"After launch, you're on your own."
"ERP integration is standard—it takes two weeks."

What a Good B2B Commerce Project Brief Looks Like

Before you request proposals, prepare a clear brief:

Business Goal (one page): Why now? What changes with the new shop?
System Landscape (one page): Which systems must be integrated? Which data flows where?
MVP Scope (one page): What must Day 1 do? What comes later?
Team and Roadmap (one page): Who decides? What deadlines are realistic?

A good brief is the best insurance against misunderstandings later.

Ready for the next step?

Finding the right agency is crucial to the success of your B2B commerce project. By asking the right questions and setting realistic expectations, you’ll make the right choice. We’d be happy to help you make your decision.

This post was first published on foobar.agency. https://foobar.agency/en/blog/wie-waehle-ich-die-richtige-ecommerce-agentur-fuer-b2b-7-fragen-die-sie-stellen-sollten-bevor-sie-beauftragen

First appearance in the iBusiness ranking: foobar Agency listed for the first time

Matthias Dietrich — Tue, 19 May 2026 00:00:00 GMT

foobar Agency has been included in iBusiness’s annual web agency ranking for the first time. The Munich-based agency ranks 82nd in the main ranking and is also listed in the e-commerce sub-ranking—at number 20 among the top 20. This marks the agency’s first inclusion in the industry directory since its founding in 2015.

The iBusiness Internet Agency Ranking has long been regarded as the standard overview of the digital agency landscape in the DACH region. It is compiled annually based on publicly available metrics, self-reported data, and editorial assessment. With this inclusion, foobar Agency officially enters this directory for the first time.

Both rankings mark the agency’s first entry into an established industry list. The eCommerce Top 20 reflects the agency’s primary area of specialization; in the main ranking, foobar Agency is listed among the top 100 DACH internet agencies. The goal is to systematically improve both rankings in future editions.

The listing comes at a time when the agency is visibly continuing its growth trajectory. The year 2026 has started off significantly stronger than the previous year; order development is on the growth path defined in the annual plan. The ownership structure, personnel decisions such as the recent appointment of Philipp Krueger as Co-CEO, and the expansion of technology partnerships support this course.

“This is our first time on the iBusiness list—it’s a milestone we consciously set for ourselves,” says Matthias Dietrich, founder and CEO of foobar Agency. “Our current ranking is a starting point, not an end result. We know where we stand, and we know where we want to go. With strong shareholders, a clear growth target, and partners who support our specialization, we look forward to the coming quarters with optimism.”

About foobar Agency

This post was first published on foobar.agency. https://foobar.agency/en/blog/premiere-im-ibusiness-ranking-foobar-agency-erstmals-gelistet

Why B2B eCommerce Projects Fail – and What the Successful Ones Do Differently

Matthias Dietrich — Mon, 18 May 2026 00:00:00 GMT

The numbers are striking—and sobering. According to commercetools data, 64 percent of B2B eCommerce projects in the DACH region fail or stall before reaching their goals. The culprit: not technology. The blame lies in unclear requirements, missing digital leadership, and a planning approach that systematically underestimates the complexity of ERP integration and stakeholder management. The good news: Projects that actually work do one thing differently from the start.

Four Mistakes That Lead to Failure

1. Scope Creep – The Requirements List Becomes Impossible

It starts innocently. The CFO has a question. The supply chain manager needs another feature. The marketing director wants an integration enhancement. Each request is individually rational. Together they create a project that can't be managed anymore.

At a large B2B company we advised, a commerce project started with 120 requirements. After three months: 280. After six months the project was stopped because complexity was unmanageable. The budget was halved, the scope had tripled, and nobody could say when it would be finished anymore.

The problem: Without clear prioritization and without someone authorized to say no, every feature becomes a "must-have." And a hundred must-haves is not executable.

2. Missing Digital Leadership – Decisions Take Months Instead of Days

Most B2B companies have a massive stakeholder problem. Marketing wants one thing, sales another, operations a third. And the decision doesn't fall with the project manager—it falls in a committee that meets once a month.

A relaunch project at a machinery manufacturer showed the classic pattern: An architect proposed a solution. It went for approval to the CIO. The CIO coordinated with the CFO. The CFO wanted further analysis. That analysis took eight weeks. The proposed solution was obsolete by then. Another topic demanded attention. The project moved further back.

Successful projects have one clear owner—not (only) a governance structure. One person with genuine decision-making authority. That person can say no to a feature in three hours; not three months.

3. ERP Integration Is Systematically Underestimated

The biggest challenge in B2B eCommerce isn't the frontend. It's not the design. It's ERP integration—and it's underestimated in almost every project.

A distributor we worked with said: "Our SAP is 25 years old. Nobody documents which data flows where. And ERP integration has to be perfect because operations falls apart otherwise." The planned integration was mentioned in two lines in the requirements list. Only during analysis did it become clear: The project needed two additional months just for integration engineering.

According to the commercetools whitepaper, ERP/CRM integration is the number-one hurdle in B2B eCommerce implementations. And it's budgeted optimistically in nearly every project.

4. Big-Bang Thinking – The Attempt to Change Everything at Once

The classic mistake: "We'll switch everything over at once. New technology, new processes, new data structure, new team—all in parallel." That's not ambitious. That's reckless.

A major retailer tried exactly that: new eCommerce system, new fulfillment structure, newly organized IT team, new performance metrics. The launch was a disaster. Because processes didn't work, because the team wasn't trained, because nobody knew who was responsible for problems.

Successful projects change one thing at a time. They launch early with reduced scope, measure, learn, and then build further.

What Successful Projects Do Differently From Day One

Discovery Before Delivery – 4 to 8 Weeks of Intensive Analysis

The most successful B2B eCommerce projects don't start with development. They start with discovery. Four to eight weeks answering these questions:

What are the business-critical use cases for phase one?
What does the system landscape look like? (ERP, CRM, PIM, warehouse—who's connected to whom?)
Who are the internal stakeholders and what do they really need?
How realistic is the planned ERP integration? (Not: What does the CFO hope? But: What does the ERP admin say?)

This intensive discovery phase costs time and budget. It saves millions by avoiding surprises.

MVP Discipline – The Hardest Question: What Does NOT Go in V1?

Successful projects follow a radical discipline: They don't define what goes in. They define what stays out.

A chemical trader rebuilding its portal started with 200 requirements. After discovery: 45 requirements for V1. That was the hardest part—not the execution, but deciding which 155 features go into phase two.

The result: The MVP launches faster, has fewer bugs, and delivers real feedback quickly.

Digital Owner With Real Authority – Decisions, Not Committees

Successful projects have one person who owns accountability. They can say "yes, that goes in" or "no, it doesn't"—and it's binding. This person isn't in a committee. They're in the project.

Iterative Releases – Launch Early, Learn Early

Instead of 18 months in development then bang at launch: MVP live after 3–4 months. Measure. Phase 2 after another 2–3 months. Phase 3 later. This reduces risk and increases learning.

What This Means for Your Project Planning

1. Realistic Timeframe

Discovery: 4–8 weeks depending on system complexity
MVP: 3–6 months depending on ERP landscape and scope
Phase 2 & 3: Iteratively, based on real feedback

Anyone planning less than 4 weeks of discovery is planning for more problems.

2. Budget as Investment, Not One-Time Spend

V1: Base investment
V2 + V3: Iteration budget
Whoever funds only V1 funds half a transformation.

3. Internal Resources That Are Actually Needed

One product owner (internal, not external)
IT interface to the ERP team
Subject matter representatives for requirements
One decision-maker for escalations

That's not a big team. But it's a focused team.

Choosing the Right Agency

A good B2B eCommerce agency:

Knows the reality of ERP integrations (SAP, Dynamics, NetSuite—not just theory, but real complexity)
Can have clear scope conversations and say no when needed
Has seen failing projects and uses that knowledge to save future ones
Doesn't promise 90 days for everything—but 4 weeks discovery, then an honest timeline

Checklist: Is Your Organization Ready?

Before you start, check these points:

Do you have clear business goals for phase one? (Not: "Make everything new," but: "Cut order time by 40 percent.")
Is there a recognized business owner? (CEO, sales leader, or CDO—with decision-making authority.)
Are your system landscapes documented? (ERP, CRM, warehouse, accounting—a rough overview.)
Can you launch phase one in 4–6 months—and actually go live? (Or will you get impatient later?)
Can you assign 3–5 people internally? (Projects without internal engagement fail.)

If you answer yes to four of these: You're ready.

Ready for the next step?

Are you planning a B2B commerce project and want to set the right course from the start? Send us a brief project overview—we’ll get back to you within 24 hours to schedule a free initial consultation.

This post was first published on foobar.agency. https://foobar.agency/en/blog/warum-b2b-commerce-projekte-scheitern-und-was-die-erfolgreichen-wirklich-anders-machen

From SEO to AEO: Why B2B Companies Must Rethink Their Visibility Strategy Now

Matthias Dietrich — Mon, 11 May 2026 00:00:00 GMT

When your B2B buyer initiates an order through ChatGPT or Microsoft Copilot, a good Google ranking doesn't help much – unless your product data is AI-readable. The shift from SEO to AEO (Answer Engine Optimization) is the next major visibility revolution in B2B. And you shouldn't miss this transformation.

The New Reality: 89% Use GenAI as Their Information Source

The numbers are striking: 89 percent of B2B buyers use GenAI as their primary information source during the purchasing process – whether ChatGPT, Microsoft Copilot, Perplexity, or Google AI Overviews. Here's what that means in practice: A purchasing manager at a German machinery manufacturer doesn't search Google for “24V gear motors” and click your website. Instead, he types into Copilot “Which gear motors for high-precision applications?” and immediately gets a structured answer with product names, specifications, and – ideally – prices directly in the AI.

This is Zero-Click Commerce: The answer exists without your website receiving a single click.

What Zero-Click Commerce Means for Your Visibility

This has immediate consequences for traffic and visibility:

Declining website visits: If the AI already contains the answer, the buyer never clicks through to your site – even if your content is there.
Shifted conversion funnel: Traffic no longer originates at the top of the funnel (Awareness) but directly at Evaluation and Purchase. Whoever doesn't appear in the AI is practically invisible.
New competition: Your competitors aren't the top-10 Google rankings anymore, but the quality of their product data in AI systems.

This is a fundamental paradigm shift. Those who ignore it will be overtaken by competitors who act.

The Shift: From Search Engines to AI Assistants

For five years, Google was the gatekeeper of B2B visibility. A good page-one ranking meant traction. Today, that reality is fragmented:

ChatGPT is used for exploratory research
Microsoft Copilot dominates enterprise environments (Office 365 integration)
Perplexity has become the standard source for specification comparisons
Google AI Overviews compete with organic rankings in the same Google window

Each platform requires its own strategy. They all share one common requirement: structured, machine-readable product data.

How Product Data Quality Directly Impacts AI Discoverability

The “4 Cs” are the new SEO foundation:

1. Correct (Accurate)

Data must be factually accurate. A motor rated at 1.5 kW is not 2.2 kW. AI models penalize inaccurate data twice: first through poor recommendations, then through declining training quality over time.

2. Complete (Comprehensive)

AI needs full context. A product without technical specifications, lead time, availability, and use cases is practically invisible to an AI. Google can rank a page with “50% info”; GPT-4 will ignore it.

3. Consistent (Uniform)

If your ERP lists Product X as “Gear Motor,” your shop calls it “Drive Aggregate,” and your documentation says “Motor Gearbox,” this massively confuses the AI. It cannot infer consistency.

4. Clear (Understandable)

Technical specifications must be not only correct but clearly written. An AI can understand “high-precision ball screws ISO tolerance class P2 with PT0.5 mm pitch for machine tools” – but only if the data is structured and in natural language.

When your product data meets these four standards, AI systems automatically generate better and more frequent recommendations for your products.

Practical Steps for AEO

Structured Data and Schema.org

Google, ChatGPT, and other AI systems can read Schema.org markup. <schema:Product>, <schema:TechnicalSpecification>, <schema:PriceSpecification> – these tags are the new language of visibility. Those who consistently use them are preferentially indexed.

Semantic Authority Through Deep Content

AI favors depth over breadth. A 3,000-word article on “Gear Motors for Automation: Selection, Calculation, Best Practices” is rated higher by AI systems than 20 shallow marketing pages.

FAQ Content for AI Training

Don't write for humans – write for the AI training of your competitor systems. FAQ content in question-answer format is ideal for AI training and is preferentially processed.

Own API Endpoints for AI Agents

Leading companies build API endpoints specifically optimized for AI agents. A Copilot plugin that accesses your product database in real time is the next level of control – you determine what data the AI receives.

Owned Experiences: What AI Channels Cannot Do

An important point: Not everything can be delegated to AI systems. Owned Experiences (proprietary portal, mobile app, EDI connections) deliver things AI cannot (yet):

Real-time availability queries against your inventory
Personalized order history and favorites
Account transparency (open invoices, contracts, service tickets)
White-label brand experience without competitor distraction

For B2B with established customers, your portal or EDI connection is ultimately more valuable than any Google ranking. Use AI channels for first discovery – but then bring the customer to your controlled experience.

Special Consideration for DACH B2B: Catalog Complexity

German and Austrian industrial companies often manage catalogs with 5,000, 50,000, or even 500,000 SKUs. This is both an advantage and a challenge:

Advantage: Whoever achieves consistency and completeness at this scale becomes the standard supplier in AI systems.
Challenge: Automating data cleansing at this volume is technically complex and expensive.

Those who start now will have a competitive advantage in 18 months that lasts for years.

Conclusion: AEO is Not Optional

SEO won't disappear. But AEO will dominate SEO in 2026 and beyond. Companies that now optimize their product data quality, implement structured markup, and build independent AI channels create sustainable visibility advantages.

The opportunity window is open – but it's narrowing. Start now.

Ready for the next step?

Your product data quality now determines your AI visibility. A structured audit shows where you stand and how to become competitive. We’ll help you achieve the 4 Cs and build your AEO strategy.

This post was first published on foobar.agency. https://foobar.agency/en/blog/von-seo-zu-aeo-warum-b2b-unternehmen-ihre-sichtbarkeitsstrategie-jetzt-neu-denken-muessen

AI in B2B Sales: How Assisted Selling Multiplies Your Sales Efficiency – Without Replacing Your Sales Reps

Matthias Dietrich — Mon, 04 May 2026 00:00:00 GMT

AI doesn't replace sales representatives – it makes them unstoppable. That's the core idea behind Assisted Selling, an approach that equips sales teams with intelligent, data-driven tools without displacing human expertise. When your field sales reps can access purchase history, margin recommendations, and cross-sell opportunities in real time, they close deals faster, advise more precisely, and significantly boost profitability.

What Assisted Selling Actually Means

Assisted Selling is not fully automated selling. It's the intelligent support of human sales through AI-driven recommendations and automations:

Pre-fill shopping carts from purchase history – The sales rep immediately sees what the customer regularly orders and can strategically build from there
Automatically prepare quotes – Based on customer profile, volume, and contract, the system generates quote suggestions in seconds instead of hours
Recommend bundles and cross-sells – AI identifies complementary products the customer likely needs long before they ask
Real-time margin optimization – Sales reps see which products offer the highest profitability and can data-drive conversations accordingly

Here's the difference: A field sales rep who immediately sees on his tablet that Customer X typically orders every 6 weeks, that margins on Product Y are declining, and that Bundle Z perfectly fits his use case, will close more deals – and advise more thoughtfully.

Market Data Speaks Clearly

75 percent of sales professionals globally already use AI-powered sales tools – and that figure continues to grow. Companies that consistently implement Assisted Selling report sales productivity increases of 20–40 percent. This isn't gimmickry; it's tangible business impact.

The ROI is particularly strong in B2B environments with complex sales cycles and key account management. This isn't about high-volume transactions but about strategic partnerships with major players. Every day you advise faster, every margin optimization you intelligently steer, adds up to six-figure revenue gains per year.

Assisted Selling vs. Full Automation – The Critical Distinction

Not everything AI does in sales is Assisted Selling:

Fully automated reorder/replenishment: When a distributor receives 50 standard stock replenishment requests daily, an automated system can process these completely without human intervention. That's efficient, but it's not Assisted Selling.
AI-assisted human-to-human sales: When a field rep closes a complex deal in a four-eyes conversation armed with data-driven recommendations, that's Assisted Selling. The human remains central; AI supports.

For industrial B2B with account management models, the second approach is the right one – and simultaneously the more complex to implement.

Real-World Example: Adelco and Hybrid Sales

Chilean distributor Adelco demonstrates how it works: They digitally connected their field sales force, gave reps access to AI recommendations, and integrated it with their eCommerce platform based on commercetools. The result: +400 percent eCommerce revenue growth in two years. The field force didn't become obsolete – it became hybrid, simultaneously nurturing personal relationships and closing data-driven sales.

The model works equally well for German industrial companies: An account manager who advises a customer's automation project with intelligent component bundles and margin optimization closes faster and builds deeper trust relationships.

Platform Prerequisites for Assisted Selling

Assisted Selling doesn't work in isolation. Four things must be in place:

Clean data foundation – Complete purchase history, current pricing, available inventory, customer segmentations. Without this foundation, no reliable AI recommendations.
API access for sales apps – The field rep needs a tool (tablet, mobile CRM) that accesses real-time data. This requires APIs between eCommerce platform, ERP, and sales systems.
Role and permission framework – Which information can each sales rep see? How much margin flexibility does he have? When does an approval process kick in? The governance model must be clear beforehand.
AI models tailored to your business – Standard recommendations often don't work. For industrial complex customers, you need adapted algorithms that understand industry dynamics, seasonality, and project cycles.

Roadmap: 3 Steps to AI-Driven Sales

Step 1 (Months 1–3): Audit your data foundation. Where are the gaps? Is purchase history complete? Are prices current? For companies, this often means cleaning 10–20 years of legacy ERP data.

Step 2 (Months 4–7): Pilot with one sales region or key account team. Train AI models, design sales user experience, establish approval workflows. This quickly shows what works.

Step 3 (Months 8–12): Full rollout and continuous optimization. Refine AI models based on actual sales data. Train reps on their new tools. Measure and communicate success.

Conclusion: The Future of B2B Sales is Hybrid

Companies that consistently implement Assisted Selling create a structural competitive advantage. Their sales teams work faster, advise smarter, and sell more profitably. This is not the future – it's already present for pioneers like Adelco.

For German industrial companies with complex sales cycles and high-value customer relationships, the potential is particularly significant. The question isn't whether you should implement Assisted Selling – it's when.

Ready for the next step?

The future of B2B sales is hybrid—and your advantage lies in how quickly you can implement it. We’ll guide you every step of the way, from data analysis to rollout strategy, and help you seamlessly integrate AI and human expertise. Get started this quarter.

This post was first published on foobar.agency. https://foobar.agency/en/blog/ki-im-b2b-vertrieb-wie-assisted-selling-ihre-sales-effizienz-vervielfacht-ohne-ihre-kundenbetreuer-zu-ersetzen

B2C Experience in B2B Shop: What Your Buyers Really Expect—and How to Deliver It Technically

Matthias Dietrich — Mon, 27 Apr 2026 00:00:00 GMT

Ten years ago, B2B procurement was a painful process: email the sales rep, wait three days for a quote, negotiate price. If you were lucky, a portal existed with a password, but it was rarely fast or intuitive.

Today, 71% of B2B buyers are Millennials or Generation Z. These people know no purchasing experience beyond Amazon, Zalando, and Apple—and they expect that exact standard from their suppliers' B2B shops. The problem: Many companies still operate online catalogs from the 2010s. The result is lost deals, lower average order values, and slower-than-necessary supplier switching.

The good news: It's not too late. With the right technical solutions and UX focus, you can build a B2B shop that's genuinely modern.

The Generational Shift in B2B Procurement

The demographic shift is fundamental. 71% of B2B buyers today are Millennials or Gen Z. They grew up digital. They scroll on mobile devices, they expect instant search results, and they leave a website after two seconds of poor loading.

Simultaneously, market studies show: 75% would switch to a supplier with better online experience. This isn't about price—it's about user experience. Supplier switching has become lower-friction. Years ago, the supplier was fixed because a sales rep had the relationship. Today, the supplier is whoever has the better shop.

This hits technical decision-makers especially hard. A CTO or technical buyer at a mid-market company will apply the same standards they use for personal shopping. If your B2B portal isn't performant, clear, and helpful, you lose trust—not just in the shop, but in your company.

The 5 Most Important UX Requirements in B2B Today

What makes a modern B2B shop? Not many features, but thoughtful, focused solutions:

1. Smart Search with AI Support

A B2B customer inputs a problem—not a product code. "Gasket for 3/4-inch water pump" is the natural search query, not "SKU-48392." A modern shop understands natural language. Artificial intelligence helps find the right products even without exact terms. Synonyms, typos, related products—the shop should think intelligently. This reduces frustration and measurably increases conversion rates.

2. Transparent, Customer-Specific Pricing

B2B pricing logic is complex: discounts based on customer segment, volume, annual contract, or season. Modern buyers expect these prices displayed live in the shop—not via quote. A logged-in customer sees their personal price instantly. A new visitor sees a standard list price. This creates transparency, reduces quote spam, and accelerates purchase decisions.

3. Self-Service Quoting

Not every inquiry needs a sales call. An intelligent configurator in the shop lets customers assemble complex offers themselves and get instant price calculations. Standard components: auto-quote. Gets complex: escalate to a specialist. This reduces sales overhead and shortens sales cycles.

4. Personalized Product Recommendations

An Amazon shopper experiences "customers who bought X also looked at Y." In B2B shops, this often vanishes entirely. Using historical purchase and browsing data, you can show high-value recommendations: "Based on your recent purchases, you might also like Z." This increases average order value and customer satisfaction.

5. Mobile-First Design

Over half of B2B inquiries start on a smartphone—a quick search, a comparison, a verification. If your shop loads slowly on mobile, has tiny text, or confusing navigation, you lose. Mobile-first doesn't mean "responsive"; it means: mobile shop is the foundation, desktop is an extension. Fast load times, large tap targets, slide-in search filters—that's table stakes.

How AI Personalizes the B2B Experience

Modern AI technology enables three practical applications that significantly improve experience:

Dynamic Pricing: Price logic isn't manually maintained; it emerges from real-time data (inventory, demand, margin). A customer with a long-term contract sees different prices than an occasional buyer—automatically and fairly.

Intelligent Product Search: Vector databases understand semantics. "Pump for hot water" finds not just products with those keywords, but related solutions. This reduces "item not found" frustration by up to 40%.

Automated Quote Generation: A customer browses a set of components; the shop recognizes the pattern and automatically creates a bundle offer with volume discount. Or a system alerts when a customer regularly buys a product: "Want an annual contract? We'll save you 12%."

Checklist: Is Your B2B Shop Really Buyer-Centric?

Take 30 minutes and audit your current shop against these 7 points:

Search Performance: Can I find products naturally-spoken, even with typos or synonyms?
Price Transparency: As a logged-in customer, do I see my current prices instantly?
Mobile Experience: Can I navigate and purchase quickly on a smartphone?
Checkout Speed: Do I need more than 3 clicks to order?
Self-Service Options: Can I configure quotes without contacting support?
Personal Recommendations: Do I see products based on my purchase history?
Load Speed: Do pages load under 2 seconds?

If you check fewer than 5 of 7, you're leaving opportunities on the table.

Common Mistakes in B2B Shop Projects

Many companies fail not on technology, but on mindset:

Too Much IT Thinking, Too Little User Thinking

The CTO says: "We need a system that covers all scenarios." True—but also a brake. A too-complex system never launches. Better: start with 80% functionality, gather real user feedback, iterate. User testing with real buyers at the start would've prevented 80% of problems.

Pricing Systems That Aren't Live

The classic mistake: prices live in a legacy system; the shop shows old data. Customers see yesterday's prices or none. That destroys trust. Modern architecture means: real-time integration between ERP/PIM and shop.

Missing Self-Service Functions

A customer must email for every small question. That's 2010. Even with technically complex products, you can embed FAQs, product videos, dimension calculators, or configurators in the shop. This makes the shop a tool, not just a catalog.

The Concrete Path: For Companies Whose Shop Is 5+ Years Old

If your B2B shop is older than five years (and you're a manufacturer or distributor of industrial or technical components), it almost certainly has weaknesses:

Run an Audit: Have an external expert conduct real-user testing. Not with employees, but with actual customers.
Set Priorities: Don't fix everything at once. Search improvement + mobile optimization + price transparency are the top 3 for most B2B shops.
Choose a Modern Platform: Composable platforms (commercetools) offer the flexibility for B2B complexity AND modern UX.
Phased Rollout: Short development cycles, 1 month beta with selected customers, then go-live. No big-bang migrations.

The investment pays off: faster checkout, higher AOV, fewer support requests, and—the biggest gain—direct competitive defense against suppliers with modern shops.

Ready for the next step?

Your B2B store is your digital storefront. We’ll conduct a thorough store analysis—covering UX, performance, and conversion behavior—and show you the top 3 levers for quick improvements. Free, no-obligation, and actionable.

This post was first published on foobar.agency. https://foobar.agency/en/blog/b2c-erlebnis-im-b2b-shop-was-ihre-einkaeufer-heute-wirklich-erwarten-und-wie-sie-das-technisch-umsetzen

D2C for Manufacturers and Wholesalers: Why 79% of B2B Companies Are Now Selling Directly to End Customers

Matthias Dietrich — Tue, 21 Apr 2026 00:00:00 GMT

Five years ago, direct-to-consumer was a strategy reserved for consumer goods manufacturers and digital brands. Today, 79% of B2B companies—manufacturers, wholesalers, suppliers—sell directly to their end customers. The remaining 20% are actively planning it. D2C is no longer an alternative; it's a necessity for anyone who wants to control margins, customer data, and market feedback.

Why the Trend Is Now Unstoppable in B2B

The numbers are clear: 30% of B2B companies with a D2C channel regularly achieve peak sales comparable to Black Friday events. These aren't rare exceptions—this is the new normal. Industrial component manufacturers, office supply companies, and tool makers are discovering that a direct customer channel isn't just profitable; it's essential to their business model.

The reason is straightforward: When you sell through a distributor, you lose three critical assets. First, first-party data. The distributor knows the end customer, not you. Your insights are limited to volumes and product mix—not buying behavior, preferences, or trends. Second, margin. A distribution channel with three or four layers (manufacturer → wholesaler → retailer → end customer) dramatically compresses your profit potential. Third, direct market feedback. You learn about problems, wishes, and opportunities late or not at all.

D2C changes this fundamentally. You control the customer relationship, build a data asset, and can optimize price, messaging, and product mix in real time.

The 3 Biggest Challenges—and How to Solve Them

Despite the opportunities, launching D2C in B2B is complex. Three hurdles stand in the way of most companies.

1. Fulfillment Complexity

B2B products are often bulky, heavy, and logistically demanding. Hardware manufacturers suddenly need to ship packages insured, handle returns, and manage international customs processes. At the same time, B2B customers expect critical components to be available tomorrow. The solution: partnerships with 3PL providers who understand B2B logistics, and clear fulfillment segmentation (express for small parts, standard for regular orders).

2. Pricing Conflicts with Existing Distribution

If you price directly cheaper than your wholesaler, you destroy that relationship. If you price the same, you lose the advantage. The solution lies in differentiated pricing logic: customer-specific prices for direct B2B customers, volume discounts for large orders, and premium services (fast returns, technical support) that justify higher pricing. Many successful manufacturers also offer separate product lines—limited editions or service bundles—unavailable through traditional channels.

3. Channel Conflicts with Your Distributors

Your wholesalers feel threatened—rightfully so. Your strategy must be clear: D2C isn't about cannibalizing distribution; it's about complementing and strengthening it. Transparent communication with key accounts is essential. Some manufacturers even offer white-label shop solutions to wholesalers so they can become D2C-capable themselves.

Real-World Examples from Industry

Viewrail (shelving components) launched a D2C shop for specialists and brokers. Within two years, the channel generated 15% of total revenue—with significantly higher margins than traditional B2B distribution. The trick: a scalable platform based on commercetools enabling customer-specific configurations (custom shelving with instant price calculations and one-click checkout). Peak sales during campaigns (like January for office relocations) genuinely resemble Black Friday dynamics.

NXP Office Supplies New Zealand integrated an intelligent self-service configurator into their commercetools based B2B shop. Customer requests that once required a twelve-person team are now 92% solved by the system. Customer service load dropped dramatically, conversion increased, and average order value grew due to improved product discovery.

The Technical Architecture for D2C Alongside B2B

Many manufacturers fear D2C means building a completely separate system. It doesn't have to. A modern multi-storefront platform like commercetools enables managing multiple channels from one inventory and data foundation:

Separate storefronts for B2B bulk customers, D2C end customers, and marketplaces (Amazon, eBay)
Distinct pricing logic and discount rules per channel
Unified inventory management and fulfillment integration
Centralized customer data and analytics

This reduces complexity significantly. You're not building two systems; you're building one flexible system with multiple faces.

Why Hardware Manufacturers Must Act Now

For companies and typical industrial component manufacturers, this is especially critical: the next 24 months will decide. Your wholesalers are digitizing themselves, marketplaces grow more aggressive, and your end customers already expect a shop experience. Starting D2C today means having a stable channel, real data, and direct customer relationships by 2028. Waiting means playing catch-up.

This isn't about whether you need D2C. It's about when you start—and how much margin you lose in the meantime.

Ready for the next step?

Your D2C strategy depends on the right platform and the right partners. We help manufacturers create a multi-channel architecture that bridges the gap between B2B complexity and D2C directness. Let us assess your potential.

This post was first published on foobar.agency. https://foobar.agency/en/blog/d2c-fuer-hersteller-und-grosshaendler-warum-79-der-b2b-unternehmen-jetzt-direkt-an-endkunden-verkaufen

Strategy and Technology on Equal Footing: Philipp Krueger Becomes Co-CEO of foobar Agency

Matthias Dietrich — Fri, 17 Apr 2026 00:00:00 GMT

foobar Agency is restructuring its leadership: Philipp Krueger is taking on the role of Co-CEO effective immediately. Together with founder and CEO Matthias Dietrich, he will co-lead the Munich-based agency going forward. Krueger brings extensive experience in strategic consulting for retailers and industrial companies.

Krueger joined foobar Agency in 2025 and has since further developed the interface between strategic consulting and delivery. His appointment as Co-CEO formalizes this role. The aim is to manage strategy and technology in a more closely integrated manner—an approach the agency has pursued for years as a differentiator from pure consulting or pure implementation providers.

In client-facing operations, both managing directors operate at the C-level: Matthias Dietrich focuses on technology and architecture, while Philipp Krueger focuses on business and domain expertise. Their perspectives overlap; they regularly manage larger projects together. Dietrich also leads sales and marketing, while Krueger oversees strategic client consulting and delivery. They share responsibility for strategic direction, portfolio development, and the AI roadmap. This division is intended to define areas of focus, not a rigid separation. The operational structure and ownership structure remain unchanged.

“With Philipp Krueger as Co-CEO, we combine technological depth with strategic consulting on an equal footing,” says Matthias Dietrich. “This is the prerequisite for establishing AI among our clients not as a showcase, but as part of the business architecture. The impact Philipp has had on clients since joining foobar has exceeded our expectations—the decision was a logical consequence.”

“foobar Agency has the rare advantage of truly mastering commerce and data—the foundation upon which AI first takes effect in business processes,” says Philipp Krueger. “This is precisely where value creation will occur in the coming years. I look forward to further expanding this path together with the team.”

About foobar Agency

This post was first published on foobar.agency. https://foobar.agency/en/blog/strategie-und-technologie-auf-augenhoehe-philipp-krueger-wird-co-ceo-der-foobar-agency

Unified Commerce in B2B: How Manufacturers Finally Overcome Data, Channel, and System Silos

Matthias Dietrich — Mon, 13 Apr 2026 00:00:00 GMT

Only 7% of B2B manufacturers deliver a seamless digital experience across all channels today. The reason is not lack of will – it is architectural. Product data, prices, inventory, and customer data are scattered across ERP, PIM, CRM, and various portals. The result: A sales rep sees available stock in the customer browser that the ERP marked as sold out days ago. A distributor gets personalized pricing in the portal but no recommendations. A CEO sees sales figures but doesn't know which customers are leaving. Unified Commerce is not an IT project – it is a growth strategy.

The Data Silos Problem: Why Fragmentation Is Expensive

Our audit of 94 B2B distributors shows: 57% capture customer data regularly – but only 17% use it for personalization. This sounds like wasted potential, but it is logical. When a customer order is processed in the ERP, customer data lives in the CRM, and product preferences sit in the PIM, then a true 360° customer view is impossible. Each system has its truth. That is the poison.

Concretely, this means:

Inventory Errors: A B2B customer sees 50 units available in the shop. The ERP says: 0 available (because quality inspection takes 2 days, which the shop doesn't show). Disappointment.
Price Logic: The customer got a volume discount in Q3. The shop doesn't know this. The customer sees full prices. He goes to a competitor.
Recommendations: The customer has 10 transactions. The shop could say: "These 3 products are bought together by similar customers." The shop says nothing. Upsell potential is gone.

The problem is not technical – it is organizational. Unified Commerce means: one data foundation, one truth, all channels synchronized.

What Unified Commerce Really Is: The Five Core Capabilities

Beware of consulting buzzword bingo. Unified Commerce is not the same as "omnichannel" or "seamless experience." Here are the five non-negotiable core capabilities:

1. API-First Architecture: All systems (ERP, PIM, CRM, personalization, fulfillment) speak through standard REST/GraphQL APIs. This enables true data synchronization – not just batch syncs at 2 AM, but real event streaming. When inventory changes, the shop, mobile app, and B2B portal know immediately.

2. Real-Time Data Layer: A single source of truth (often: a data lake or event streaming system like Apache Kafka). All systems write their data here. The shop doesn't query the ERP directly; it queries the real-time data layer. This is the decisive architectural difference.

3. Scalability Without ERP Dependency: The shop must handle millions of product queries without overloading the ERP. This only works with caching (Redis), CDN for product images, and API gateways. The shop doesn't have to wait for SAP performance windows.

4. Headless Frontend Flexibility: The B2B manufacturer needs not one but multiple frontends: e-shop, mobile app, partner portal, configurator, DMS integration for CAD data. A single monolithic system cannot do this. Headless means: one backend, N frontends.

5. Composable Services (Microservices): Price calculation, availability, recommendations, search – these are separate services. They can be built, tested, and deployed independently. If the search service slows down, it doesn't affect the entire shop.

The BSH Case Study: Global Scale with Local Flexibility Across 11 Brands

Bosch Siemens Hausgeräte (BSH) is a classic DACH manufacturer with 4.3 billion EUR in revenue. Their dilemma: 11 global brands (Bosch, Siemens, Thermador, Gaggenau, Neff, etc.), each with its own go-to-market, but one shared supply chain.

Old Architecture: 11 separate eCommerce systems, 11 different ERP interfaces, inventory data silos, no cross-brand recommendations. A Bosch customer didn't know that a Siemens product was a better fit – because the systems didn't talk.

BSH's Unified Commerce Relaunch (2022-2024):

One data lake (Snowflake) with all product data, inventory data, transaction data from all brands
One PIM (Product Information Management) as central authority for product data
One microservices backend with APIs for pricing, availability, personalization, fulfillment
11 independent frontends (React apps), all speaking to the same API layer

Results:

Inventory accuracy: from 87% to 99.2% (saves returns)
Time-to-market for new products: from 12 weeks to 3 weeks (one SKU goes into the data lake, all 11 shops show it immediately)
Cross-brand conversion: 12% additional upsell revenue through intelligent recommendations
Scalability: Black Friday traffic quintupled – no system crash because the architecture scales.

This is not SAP-bashing. SAP keeps running. But SAP is not the storefront engine.

Source: commercetools whitepaper “Pivotal Trends and Predictions in B2B Digital Commerce in 2026”

The Roadmap: Step-by-Step to Unified Commerce (No Big Bang)

Phase 1 (Months 1-3): MVP – Core Capabilities

Define: which data is mission-critical? (Product, inventory, price, customer profile)
Build an API layer for this data
Choose a data layer (cloud data warehouse: Snowflake, BigQuery)
Pilot shop with React/composable commerce (commercetools)

Phase 2 (Months 4-6): Extension – Additional Services

Personalization & recommendations (CDP, ML service)
Distributed search (Algolia, FactFinder)
Fulfillment integration

Phase 3 (Months 7-12): Scaling – All Channels

Mobile app
B2B partner portal
Integrations (ERP, PIM, CRM, DMS)

Phase 4 (Ongoing): AI & Optimization

Dynamic pricing logic
Demand forecasting
Churn prevention

Why This Is Critical for DACH Distributors

A distributor doesn't see in the B2B portal which products this major customer historically preferred. A small electrical contractor has to search for SKUs manually – the shop has no configuration for their specialized customer needs. A branch manager needs 2 days to check inventory.

With Unified Commerce:

Personalized Catalogs: A customer sees only the 200 products relevant to their trade (not 50,000 total SKUs)
1-Click Reorder: Based on transaction history
Real-Time Inventory Transparency: Across all branches and warehouses
Mobile-First: The contractor orders from the construction site tablet

That is growth.

Ready for the next step?

Unified commerce only works if you don’t treat it as an IT project. It requires clear data ownership, a lean architecture, and realistic timelines. Let’s hold a customized architecture workshop—we’ll show you which phase is the right starting point for you and how to intelligently decouple your systems.

This post was first published on foobar.agency. https://foobar.agency/en/blog/unified-commerce-im-b2b-wie-hersteller-daten-kanal-und-systemsilos-endlich-ueberwinden

Legacy B2B Systems: ERP Integration & Modern Architectures

Matthias Dietrich — Mon, 06 Apr 2026 00:00:00 GMT

The Enterprise Resource Planning System (ERP) is the nervous system of every industrial company. It orchestrates production, logistics, finances, and customer relationships. Yet in the digital age, this very centrality becomes a bottleneck. Our analysis of 280 B2B manufacturers in the DACH region shows: 64% of decision-makers cite their legacy commerce system as their biggest obstacle to digital growth. That's not surprising – it's systemic.

The ERP Dilemma: Why Centrality Becomes a Brake

A modern B2B shop must display hundreds of product variants in real-time, calculate personalized prices, communicate with supply chain systems, and deliver AI-powered recommendations. The ERP was never built for this. Its architecture is sequential, not parallel. Its database is optimized for transactional consistency, not real-time queries across millions of SKUs. And its user interfaces come from an era when eCommerce was still a niche project.

The core problem: Every innovation idea must go through the ERP integration chain. Want new filter options in your shop? That requires custom fields in the ERP. Looking to test AI price optimization? You have to write new APIs. Need a mobile-first checkout? The ERP forces you into the same data structures as your 2015 desktop portal.

McKinsey data shows that #1 hurdle in B2B eCommerce implementations is the integration of ERP and CRM systems. 73% of replatforming projects exceed their budget by at least 35% because ERP decoupling is underestimated.

Monolith vs. API-First: The Architecture Decision

The market divides into two camps:

Camp 1: The Monolith Approach (SAP Commerce Cloud, Oracle Commerce). Everything lives in the same system. Advantage: no integration complexity. Disadvantage: You're a thousand times dependent on update cycles. Want a new checkout flow? SAP defines it. Want to plug in an AI partner? Check whether your SAP version supports it.

Camp 2: API-First / Composable Commerce (custom-built on Commercetools, Shopify Plus). The ERP stays what it is – a data store and transaction system. Above it sits a state-of-the-art, independent commerce layer with APIs. The shop doesn't speak to the ERP directly; it speaks to an abstracting service layer.

For large B2B manufacturers: API-First is not optional – it's strategically necessary. The reason is simple: You can't bake every new technology (AI recommendations, AR visualization, blockchain supply chain, voice commerce) into your ERP. You need an architecture that scales independently of the ERP.

4 Concrete Steps to Intelligent ERP Decoupling

Step 1: Data Model Audit. What must come from the ERP, and when? Product data and inventory management: real-time. Customer data: batch synchronization every 4 hours is sufficient. Transactions: real-time. Make this distinction explicit. This saves 40% of integration complexity.

Step 2: Abstraction through an API layer. Don't build direct shop-to-ERP connections. Use iPaaS platforms (MuleSoft, Talend) or service mesh patterns. This makes you independent of ERP updates and allows parallel technology evolution.

Step 3: Start MVP with Composable Commerce. You don't need a "Unified Commerce" solution with 47 integrations right away. Start with 3: ERP product data, ERP inventory management, ERP order management. Everything else (personalization, recommendations, audience segmentation) you can plug in later.

Step 4: Define Measurability. How do you measure success? Time-to-launch for new features (not months, but weeks). Feature independence from ERP release cycles. AI readiness. Define these metrics before the architecture decision.

Why This Is Critical for DACH Manufacturers

Sales traditionally run through distributors and directly. The ERP is the heart. But your competitors are already offering personalized configurators, supply chain transparency, and AI-powered product recommendations. Those who don't intelligently decouple their ERP today will miss out on the next 3 years of digital innovation.

The solution isn't to replace SAP. It's to recontextualize SAP: as a data store, not as a digital storefront.

Ready for the next step?

Your ERP is not your competitive advantage – your ability to innovate quickly is. If your architecture is ERP-dependent today, you can't be agile tomorrow. Let's build a roadmap together that recontextualizes your ERP and doubles your commerce velocity.

This post was first published on foobar.agency. https://foobar.agency/en/blog/legacy-b2b-systems-erp-integration-modern-architecture