B2B cross-sell, upsell & product configuration recommendations

B2B sellers hold thousands of SKUs, complex compatibility rules and few, large accounts, so consumer-style "customers also bought" lists rarely fit. Recommenders combine purchase and installed-base data with hard product rules, so reps and self-service portals get relevant add-ons, upgrades and valid configurations. Benefits are more complete quotes and less rework from invalid configurations.

Problem & value

• Today: reps rely on memory, static bundles and spreadsheets. Cross-sell depends on individual knowledge, so whitespace in accounts goes unseen. Complex products (machines, IT, industrial components) are quoted with invalid or incomplete configurations, which cause rework and returns.
• AI value: surface likely next purchases per account (accessories, spare parts, consumables, tier upgrades, complementary modules), explain why, and constrain suggestions to what is technically valid and orderable. Vendors report revenue and quote-speed gains, but figures are vendor-specific and should be validated by an A/B test on your own data.
• B2B specifics: few buyers per account, long cycles, buying committees, negotiated prices and contracts, so the unit of recommendation is the account and the opportunity, not the anonymous session.

Variants

• Rep-assist (guided selling): suggestions inside CRM or CPQ during quoting.
• Self-service B2B portal / webshop: reorder lists, accessory and spare-part suggestions per customer.
• Product configuration: constraint-based configurators extended with learned preferences (machines, vehicles, IT hardware, building systems).
• Installed-base driven: service and maintenance data triggers replacement, upgrade or consumable offers.
• SaaS expansion: usage telemetry drives seat, tier and add-on upsell (product-led growth).
• Distribution / wholesale: basket completion and substitute suggestions across large catalogues.

How it works

1. ERP orders + CRM + installed base + telemetry + catalogue/rules
2. feature & graph building (account x product, product compatibility graph)
3. candidate generation (collaborative filtering, item embeddings, "lookalike" accounts, rules)
4. ranking (gradient-boosted trees / two-tower / sequence model) + business filters
5. constraint check (configurator / CPQ rules: valid, orderable, in stock, contract-compatible)
6. explanation (LLM drafts reason + talking points from the data)
7. rep or portal UI
8. quote / order
9. feedback loop (accepted, rejected, won)

• Candidate models: implicit-feedback matrix factorisation, item2vec-style embeddings, and graph neural networks over account-product graphs; for sparse accounts, content-based embeddings of product descriptions help (cold start).
• Rules stay authoritative: compatibility, regulatory and pricing constraints are enforced by the configurator or a rule engine. Never let a model or LLM decide whether a configuration is valid.
• LLM role: summarise the account context, explain the suggestion, and draft quote text. Retrieval over catalogue and datasheets grounds the answer. The LLM does not rank on its own.
• Human-in-the-loop: the rep accepts, edits or dismisses each suggestion. Dismissal reasons are a valuable training signal. Discounts and contract terms stay with humans.

Data preparation

The core data are order and invoice history per account, installed base and contracts, the product catalogue with compatibility rules, and CRM quotes with win/loss. In an SMB these live in the ERP, the CRM and often in Excel price lists or PDFs. Typical gaps are inconsistent customer and product IDs between ERP and CRM, compatibility rules that exist only in sales staff's heads, missing installed-base records, and quotes saved as documents without structured lines.

Preparation steps: - Export ERP orders, invoices and contracts and link them to CRM accounts (PREP-005). - Unify article numbers and variants, and capture compatibility and bundle rules in a table or glossary (PREP-012, PREP-011). - Extract quote lines from PDFs and Word files into structured records (PREP-006, PREP-007). - Harvest labels from won deals and repeat orders (PREP-020). - Name a data owner for the product master (PREP-004).

Expect 40 to 50 percent of the effort in matching accounts and products and writing down rules. A short data-readiness check beforehand (GUIDE-003, PREP-001) avoids surprises.

Implementation paths

Which path for whom

• SMB (A): CRM and CPQ products with built-in next-best-product suggestions are available at SMB prices; this fits when the catalogue rules are simple.
• Enterprise (B): Complex compatibility rules, installed-base data and ERP integration need custom pipelines on cloud APIs and own data.
• Developer (B): Embedding recommendations and configuration checks into your own product is best done via cloud APIs and open libraries.

Path A — Buy (recommended for most SMBs)

• CRM / CPQ suites: Salesforce (Revenue Cloud, Einstein), Microsoft Dynamics 365 Sales, SAP Sales Cloud and SAP CPQ, HubSpot, Oracle CPQ. Most offer AI-assisted product suggestions or guided selling.
• Configurators / CPQ specialists (several EU): Tacton (Sweden), Configit (Denmark), camos/Siemens (Germany), Encoway (Germany), Cincom, Conga.
• B2B commerce personalisation: Algolia (EU-founded), Bloomreach, Coveo, Dynamic Yield, Adobe Commerce, SAP Commerce, Shopware B2B (Germany) with recommendation plug-ins.
• Choose A when: the CRM/ERP vendor already ships a recommender, catalogue under ~tens of thousands of SKUs and no unusual rules. Check EU data residency, DPA, and whether you can export recommendation logs.

Path B — Build on cloud APIs

• Managed recommenders: Amazon Personalize (Frankfurt/Ireland regions), Google Cloud Vertex AI Search for commerce / Recommendations AI, Azure AI Search with custom ranking. Tabular models via Vertex AI, Azure ML or SageMaker.
• LLM layer: a frontier or EU model (Mistral, Claude, Gemini, GPT in EU regions) for explanations, quote text and natural-language configuration requests ("a pump for 40 m³/h, ATEX") with structured outputs that call the configurator API as a tool.
• Integration: ERP/CRM export to a warehouse (Snowflake, BigQuery, Databricks), nightly batch scoring, results written back to CRM fields or an API for the portal.
• Choose B when: you have your own data science capacity and need account-specific logic or custom rules.

Path C — Self-host (open source)

• Libraries: implicit, LightFM, RecBole, TorchRec, Merlin/NVTabular, LightGBM / XGBoost for rankers, PyTorch Geometric or DGL for graph models.
• Retrieval: pgvector, Qdrant or OpenSearch for item embeddings; open embedding models such as BGE-M3 or multilingual-e5.
• Constraints: open-source solvers (Google OR-Tools CP-SAT, Choco) or a rule engine for configuration validity.
• LLM (optional): an open-weight model (Qwen, Llama, Mistral families) via vLLM for explanations.
• Hardware: the ranking models run on CPU (HW1) for typical B2B volumes. Add HW2 only for self-hosted LLM text.

Path D — Custom training

Worth it for large catalogues with rich interaction logs (distributors, large machinery makers) or when sequence models over order histories beat off-the-shelf results. Needs 12–24 months of order and quote data with accepted/rejected labels. Evaluate offline (recall@k, NDCG) and online (A/B or holdout accounts), since B2B data is sparse and offline gains often overstate real uplift.

State of the art (2026)

• Hybrid stacks dominate: GBDT/two-tower rankers for scoring, embeddings for cold start, rules for validity. LLMs add explanation, conversational configuration and quote drafting rather than raw ranking.
• Agentic quoting: agents read an RFQ, propose a configuration via the configurator tool and draft the quote for rep approval (see AGENT-027). Tool calls into deterministic CPQ keep outputs valid.
• Foundation-style sequence models for orders (transformer-based next-item prediction) are moving from research to production at large commerce vendors, but B2B datasets are often too small to benefit.
• Limits and failure modes: sparse and lumpy purchases (a machine is bought once in years); popularity bias towards bestsellers; recommending items the customer already owns through another channel; stale installed-base data; suggestions that conflict with contracts, export rules or price agreements; feedback loops from reps who only accept easy suggestions; offline metrics that do not translate into revenue.

Shared resources & combinations

• Same stack (recommender + tabular-ml): REC-001 (B2C product recommendations), REC-009 (loyalty offers), REC-003 (next-best-action) reuse feature stores, embeddings and the experiment framework.
• Upstream signals: PRED-005 (lead scoring), PRED-003 (churn: retention offers vs upsell timing), REC-004 (segmentation), AGENT-011 (CRM data hygiene improves account and installed-base data).
• Downstream: AGENT-027 (RFQ-to-quote) consumes configurations; pricing and discount optimisation use the same data.
• Knowledge graph of products and compatibility is shared with technical-support and catalogue-search use cases.

Effort, cost & KPIs

• Path A: weeks to a few months, mainly data clean-up and CPQ/catalogue modelling. Licences are per user or module.
• Path B: 2–4 months for a first batch-scoring pipeline with CRM write-back; cloud cost is modest, staff time dominates.
• Path C/D: 4–9 months with a data scientist and engineer; ongoing MLOps and monitoring.
• KPIs: suggestion acceptance rate, attach rate / items per order, share of quotes with valid configuration at first pass, quote cycle time, revenue per account vs control group, win rate, return/rework rate, rep adoption.
• Cost drivers: catalogue and master-data quality, ERP/CRM integration, rule modelling effort.

People & change

Start with the sales director as process owner and management for goals. Sales reps are the real users: involve a few experienced reps early, since they know the compatibility rules and will judge whether suggestions are credible. IT and the data owners of ERP and CRM provide the exports; the DPO is needed where contact persons are personal data (AVV, legal basis).

Works council: depends. Rep-facing tools that log clicks, acceptance rates or follow-up per rep can be suited to monitor performance, so §87(1) no. 6 BetrVG likely applies; also inform under §90(1) no. 3. Clarify early that suggestion acceptance is not a performance metric, ideally in a short works agreement.

AI literacy: support reps with a short session on how suggestions are generated and where they are wrong (AI Act Art. 4 supports, no guaranteed level). Run a pilot with one team and compare with a control team. Typical concerns are being replaced or measured, and bad suggestions; address them by presenting the tool as a prompt for talking points, showing the reasons per suggestion, and letting reps dismiss it with one click. The rep always decides.

See GUIDE-004, GUIDE-008 and GUIDE-009.

Risks, regulation & compliance

• EU AI Act: typically minimal risk (no Annex III category). Becomes relevant only if recommendations drive access to essential services for individuals, or use manipulative techniques (Art. 5(1)(a)); AI literacy (Art. 4) applies. Chatbot-style configurators must disclose AI interaction (Art. 50).
• GDPR: mostly company data, but contact persons, usage telemetry and sole traders are personal data. Legal basis (legitimate interest) with documented balancing, objection to direct marketing (Art. 21), and profiling transparency (Art. 13/14). Fully automated decisions with legal effect (Art. 22) are not the norm here.
• Competition and contracts: do not use data from one customer to disadvantage another; respect contractual price agreements and, for platforms, the Data Act and competition law on use of customer data.
• Product safety and liability: invalid configurations (safety, ATEX, CE) must be blocked by rules, not by the model.
• Mitigations: rule-based validity gate, human approval of quotes, logging of suggestions, holdout groups, periodic review of bias towards high-margin items.

Getting started

1. Audit data: 2+ years of orders, a clean product master and an installed-base list per account.
2. Define the unit (account, opportunity or quote line) and a baseline, e.g. the current attach rate.
3. Start with a simple "frequently bought together + whitespace vs similar accounts" list and rules in the CRM.
4. Pilot with a few reps, log accept/reject reasons, and run a holdout comparison.
5. Add a ranker and LLM explanations only after the baseline shows signal; connect the configurator for validity.

Sources

1. Salesforce — Revenue Cloud (CPQ and billing) documentation — https://www.salesforce.com/products/revenue-cloud/
2. Tacton — CPQ and product configuration — https://www.tacton.com/
3. Amazon Personalize developer guide — https://docs.aws.amazon.com/personalize/latest/dg/what-is-personalize.html
4. Google Cloud — Vertex AI Search for commerce — https://cloud.google.com/solutions/retail-product-discovery
5. RecBole recommender library — https://github.com/RUCAIBox/RecBole
6. OR-Tools CP-SAT solver — https://developers.google.com/optimization/cp
7. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
8. Regulation (EU) 2016/679 (GDPR) — https://eur-lex.europa.eu/eli/reg/2016/679/oj