Use Cases Outside Retail

[ericbernhard]

Does anyone see use cases for UCP outside of retail currently?

[baha-ai]

Absolutely! I think the service and subscription economy is actually one of the strongest use cases for UCP.

We are currently building Totl Digital, a subscription management platform, and we see UCP as the missing link for "Agentic" service discovery. Instead of building custom APIs for every single SaaS or streaming provider, UCP would allow our agent to dynamically discover alternative plans or bundles for our users (e.g., finding a cheaper 'Family Plan' or a better 'Yearly Rate').

We've even started implementing a mock client against the Alpha SDK to test this flow. Excited to see more service-based providers join the registry!

[appdrops]

Hey @baha-ai (and @ericbernhard),

Founder of ucpchecker.com here.

We are seeing the exact same trend. While our current verified list (63 merchants) is 100% retail/Shopify, the protocol's negotiation and fulfillment capabilities map perfectly to service provisioning.

We are aiming to track this sector.

@baha-ai - If you have a mock client or any alpha endpoints you're testing against, I'd love to list them (or run them through the Checker) to help validate the 'Service Discovery' flow you mentioned. Happy to chat offline if you want to share data.

[dhananjay2021]

Interesting thread! I've been personally exploring UCP for fixed-price services.

I work in the home services space (think plumbers, cleaners, movers, etc.), and I've been curious whether UCP could apply beyond traditional retail.

While not traditional retail, fixed-price services share some interesting parallels:

• Discrete, purchasable offerings – A "2-hour deep clean" or "TV mounting" is essentially a SKU with a defined price
• Cart-like checkout flows – Users can bundle services or add-ons before booking
• Inventory concepts – Pro availability slots are analogous to stock levels

The main adaptation needed is around scheduling and fulfillment semantics (when/where the service happens vs. shipping a physical product), but the core commerce primitives—catalog, pricing, checkout, payment—map surprisingly well.

Curious if others are looking at UCP for services, appointments, or other non-tangible goods. Would love to compare notes on where the protocol fits naturally vs. where it needs extension.

[Nolpak14]

Great examples from @baha-ai and @dhananjay2021. I'd add a couple of angles:

The checkout state machine generalizes well beyond retail:

incomplete → requires_escalation → ready_for_complete → completed

This maps to subscription sign-ups, service bookings, digital downloads, API credit purchases — anything where you need to collect info, get buyer input, and finalize a transaction.

Specific non-retail use cases I see potential in:

• SaaS subscriptions (echoing @baha-ai) — an agent could discover pricing tiers via /.well-known/ucp, compare plans across providers, and initiate a subscription checkout. The dev.ucp.shopping.order capability already handles post-purchase lifecycle and webhooks, which maps naturally to subscription management.

• Event tickets / reservations (@dhananjay2021's scheduling point) — availability slots as inventory, time/date as fulfillment metadata. The UCP roadmap explicitly lists "new verticals beyond Shopping (e.g., Travel, Services)" as a priority, so this is on their radar.

• Digital goods & API access — this is being explored on the ACP side too (Universal Product Types proposal) with concepts like digital delivery, async generation, and budget allowances. Would be interesting to see UCP tackle the same space via extensions.

The main gap is fulfillment semantics — UCP's fulfillment extension currently assumes physical shipping. For services, you'd need scheduling/appointment primitives. For digital, you'd need download/access-key delivery. Both feel like natural extension candidates.

[zologic]

Jumping in from the WooCommerce side — we've been thinking about this exact question while building [UCPReady](#297).

Two things from our implementation experience:

B2C with wallet payments — our current live deployment ([houseofparfum.nl](https://houseofparfum.nl)) uses store credit as a payment instrument surfaced via UCP. The agent discovers the wallet balance, selects it, and calls complete_checkout server-side. No card network, no redirect. In Europe this sidesteps SCA entirely because it's a merchant-internal debit, not a payment network transaction. That model applies cleanly to any service with pre-paid credit — subscriptions, digital goods, bookings.

B2B procurement — we're building ucpready-procurement as a separate extension using a com.ucpready.procurement capability namespace. New MCP tools: create_rfq, submit_po, get_quote. WooCommerce product meta extended with uom, moq, lead_time, commodity_code. The framing is UCP as an AI-native cXML replacement for SMB suppliers who can't afford EDI. The spec's negotiation and fulfillment primitives map directly to RFQ → quote → PO flows.

---

The protocol's core primitives are more general than the retail framing suggests:

• Catalog = any discrete purchasable offering
• Fulfillment = any delivery of value (physical, digital, service, appointment)
• Identity Linking = consent-scoped agent authorization applicable far beyond shopping

The main gap worth flagging to the TC: scheduling semantics. There's no native concept of a time-slot or availability window in the current fulfillment spec, which matters for services, appointments, and capacity-constrained bookings. The fulfillment methods structure could be extended with a schedule block without breaking existing retail implementations.

---

Full implementation details and live endpoint in our Show and Tell post: #297