If you run the proposals function at an SAP partner, a Global SI, or any systems integrator that both resells software and delivers services, you know the real question every RFP forces you to answer fast: "which of the things we sell actually map to what this RFP wants?"
That question is deceptively hard. Your catalog might include 40+ SAP SKUs across S/4HANA, Ariba, SuccessFactors, Concur, Business Network, BTP, and SAC. You have proprietary IP — migration accelerators, industry templates, data quality tools. You have productized services — managed operations, implementation packs, support tiers. And you have a rate card with a dozen billable roles.
An RFP lands. The deadline is Tuesday. You have to triage: "Is this a pure software deal? Consulting? Hybrid? Which modules? Which accelerators? What roles do we staff?" Today that happens in a slack huddle with two solution architects and a deal captain. Sometimes the right bundle gets chosen. Sometimes it gets missed. Sometimes a profitable accelerator never makes it onto the pitch because no one remembered it exists.
MyBids.AI now closes that gap with a first-class Product Catalog and an RFP-to-catalog matcher built into the 9-agent pipeline. This post explains how it works, why we built it specifically for SAP partners and multi-offering SIs, and how you can have it running today.
The core problem: multiple offering types, one RFP
A generic proposal tool treats "what you sell" as a single bucket — usually service lines. That works fine for a boutique consultancy with three offerings. It falls apart for a systems integrator.
SAP partners, cloud resellers, and multi-product SIs typically sell four distinct classes of things, each with different licensing, delivery, and pricing mechanics:
- Resale products — third-party software with vendor-defined SKUs, pricing models, and licensing tiers (SAP Ariba, S/4HANA, SuccessFactors, BTP).
- Own IP — proprietary platforms, accelerators, industry templates, or tools you built that differentiate you from every other SAP partner pitching the same modules.
- Productized services — managed services, implementation packs, transition playbooks. Not a SKU, not a body shop — a named offering with a defined scope.
- Billable roles — the rate card. Sr. SAP Architect, Integration Lead, Functional Consultant. Each with onsite / nearshore / offshore tiers.
An RFP rarely maps to one class. A real procurement opportunity might need S/4HANA (resale) + your finance migration accelerator (own IP) + 12-month managed support (service) + 4 named architects for the first 90 days (roles). The win comes from proposing that bundle confidently — with evidence — within 48 hours of the RFP landing.
We kept hearing the same story from SAP partners: "Our best bundles come from our most experienced solution architects. When they're on the deal, we win. When they're not, we ship the obvious bundle and leave margin on the table." That institutional knowledge is exactly what the catalog matcher encodes.
What the Product Catalog does
The catalog lives under Settings → Product Catalog. Every tenant can declare the four item kinds above in a single place, with structured metadata that actually gets used by the matcher:
- Vendor, name, SKU, version — for precise identification. "SAP Ariba Sourcing, Cloud edition, ARIBA_SRC".
- Summary — a one-or-two-sentence pitch the matcher reads when scoring fit.
- Capabilities — explicit feature list ("RFQ management, reverse auctions, supplier scorecards").
- Category / subcategory — "Procurement / Strategic Sourcing" so a procurement RFP can find it fast.
- Target industries and personas — public sector, manufacturing, CFO office.
- Pricing model — per-user subscription, perpetual license, consumption-based, T&M, fixed-bid. The matcher uses this to flag "budget-model mismatch" gaps.
- Prerequisites and companions — "Requires SAP BTP"; "usually paired with our Data Quality Accelerator." The matcher uses these to build coherent bundles.
- Certifications and geographies — SOC2, FedRAMP, EU data residency. Critical for government and regulated RFPs.
The catalog is scoped per tenant and respects row-level security — no other organization can see what you sell.
How the RFP-to-catalog matcher works
After an RFP is parsed and the qualification agent decides you should bid, a new CATALOG_MATCHER step runs automatically. It sits between capability matching (should we bid?) and strategy (how do we win?), answering the middle question: "what do we propose?"
- Engagement-type routing. The intake agent already classifies each RFP as
product,consulting, orsingle_resource. The matcher uses this to shortlist which catalog kinds can anchor the bundle. AproductRFP gets a resale SKU or own-IP platform as its primary. AconsultingRFP gets a service or accelerator. Asingle_resourceRFP gets a billable role. - Requirement indexing. Every extracted RFP requirement (mandatory, functional, certification, security, geographic) is assigned a synthetic ID the matcher can cite precisely —
M1,M2,R1,C1,S1,G1. This gives us evidence-level traceability later. - LLM scoring. Each catalog item is scored 0–100 against the full requirement set in a single, structured call. The prompt bans hallucinated items — if the model invents a SKU that isn't in the catalog, it's dropped on parse.
- Deterministic bundle assembly. Scored items are partitioned into Primary (score ≥ 75, engagement-eligible), Complementary (score ≥ 60, up to 4 items), Optional (score ≥ 50, up to 3 upsell candidates), and Rejected (below the floor — kept for audit).
- Coverage analysis. The matcher aggregates matched requirement IDs across the bundle and reports uncovered gaps — the exact requirements no item in your selected bundle addresses. These feed directly into the strategy and gap-analysis agents so your proposal either addresses them or flags them as clarifying questions.
The whole step is non-blocking: an empty catalog, a parse error, or an LLM hiccup never fails the pipeline. The rest of your 9-agent proposal continues to generate normally.
What you see on every RFP
On the RFP detail page, next to the Requirements Checklist button, you'll now see a Solution Bundle button. It opens a three-column view:
| Column | What it contains | Typical size |
|---|---|---|
| Primary | The single offering that anchors the proposal. Usually a resale product or own IP. | 1 item |
| Complementary | Items that reinforce the primary and extend requirement coverage. | 2–4 items |
| Optional | Upsell candidates worth mentioning as add-ons. | 0–3 items |
| Coverage gaps | RFP requirements not satisfied by any item in the selected bundle. | 0–N |
| Rejected | Audit trail — every catalog item the matcher considered and why it was dropped. | Hidden by default |
Each match card shows the score, the matched requirement IDs with short evidence phrases, and the matcher's one-line reasoning. You can re-run the match any time — for example after adding a new catalog item mid-proposal — with a single click.
Why this matters specifically for SAP partners
Generic proposal software treats catalog matching as a stretch feature. For SAP partners, it's the whole game. A few concrete wins:
- Stop missing IP on competitive deals. If you've built a procurement accelerator that saves 40% migration time, it should appear on every procurement RFP. The matcher guarantees it — your solution architects can't "forget" what's in the catalog.
- Right-size the bundle, every time. The Primary / Complementary / Optional split forces the tight pitch. No more 12-item "kitchen sink" bundles that dilute margin and confuse procurement teams.
- Evidence-grade traceability. When a customer asks "how does Ariba Sourcing satisfy requirement M7?", the matched requirement evidence is already on the card. Your strategy and content agents pull from it directly.
- Coverage gaps become clarifying questions. The gaps column is your free input to gap analysis. Any requirement the bundle doesn't cover becomes a candidate question for the customer — or a flag that you need a partner / subcontractor for this piece.
- Bundle changes propagate. Promote an item from Optional to Primary and the strategy agent picks up the shift on the next run. You're not maintaining the bundle in a separate tool and copy-pasting into the proposal.
What ships today, and what's next
Available now (Phase 1):
- Manual catalog management under Settings — add, edit, archive, reactivate items across all four kinds.
- LLM-based RFP-to-catalog matcher running on every RFP post-qualification.
- Three-column bundle view per RFP with coverage gaps and a rejected audit trail.
- User overrides — promote, demote, or reject items; overrides survive pipeline re-runs.
- Plan limits: 25 catalog items on Starter, 500 on Business.
Coming in Phase 2 (next release):
- Taxonomy agent — auto-populate the catalog from your existing knowledge base uploads. Upload a PRODUCT_DATASHEET, LICENSING_PRICING, or CAPABILITY_STATEMENT and the extractor proposes catalog entries for review.
- Hybrid catalog retrieval — semantic + keyword search over the catalog, so matching scales to hundreds of SKUs without blowing the LLM context.
- Evidence chips on KB document pages — see which catalog items each doc supports.
Coming in Phase 3:
- SAP seed import — a curated seed of ~300 SKUs across BTP, S/4HANA, Ariba, SuccessFactors, Concur, Fieldglass, Business Network, DataSphere, SAC, Signavio, and LeanIX. One-click import on Business tier.
- Bundle-aware strategy and content prompts — win themes and solution narratives that cite specific bundle items by name.
- Drag-to-reassign match review UI, confirmed-bundle propagation to strategy.
How to try it
The Product Catalog is live on all plans today. Here's the fastest path to a matched bundle:
- Go to Settings → Product Catalog.
- Add 5–10 of your most commonly proposed items. Start with your differentiated Own IP — that's where the matcher pays for itself fastest.
- Upload a recent RFP (one you've already won or lost works great — you'll know if the bundle looks right).
- Wait for the pipeline to finish qualification. Click the Solution Bundle button on the RFP page.
- Compare the proposed Primary / Complementary / Optional split against what your team would have pitched. Tune the catalog based on the gaps.
The catalog gets better the more representative your entries are. If an item is vague ("SAP services"), the matcher will score it conservatively across everything. If an item is specific ("SAP Ariba Sourcing — RFQ events, reverse auctions, supplier scorecards, public-sector ready"), it'll be picked confidently when it fits and dropped cleanly when it doesn't.
Start matching your catalog today
If you're an SAP partner, a global SI, or any integrator juggling resale SKUs, proprietary IP, and productized services on every RFP — the Product Catalog is the feature we built for you.
Sign up free and populate your catalog this afternoon. 2 RFPs/month on Starter, 10 on Business, with the full matcher and bundle view on every tier.
Already a customer? Head to Settings → Product Catalog right now and add your first 10 items. Run your next RFP through the pipeline and tell us how the bundle compares to what your team would have proposed. Email us — we read every reply.
Prefer to see it in a walkthrough? Book a demo and we'll load a sample SAP catalog and run one of your recent RFPs against it on the call.