RFC: performance-sales specialism — is conversion-driven selling distinct from sales-social?

[bokelley]

Spawned from #3345 reframe.

Open question

Is conversion-driven selling a distinct go-to-market role from sales-social (and sales-catalog-driven), or is it the same role with a conversion-tracking capability bolted on?

A performance-sales agent ships:

• sync_event_sources — register conversion pixels / CAPI endpoints
• log_event — receive conversion events (downstream measurement loop)
• Plus the standard create_media_buy / sync_creatives / etc. surface

Two framings:

Framing A — performance-sales is a real role. The agent's whole proposition is conversion-driven optimization. Conversion tracking is required, not optional. Real-world parallels: Meta CAPI-integrated buying surfaces, LinkedIn Conversions API, retail-media's branded-conversion flows. File as a new specialism with log_event + sync_event_sources required in its storyboard.

Framing B — conversion tracking is a capability of existing sales specialisms. Add a capability boolean (e.g., accepts_conversion_events: true) to sales-social and similar. Agents that support it claim the capability; storyboards gate the conversion-tracking steps on the boolean.

What decides this

The question is whether there are agents in the field whose entire role is conversion-driven, vs. agents whose primary role is sales-social with conversion tracking as an add-on. If the former is real and common, framing A is right. If conversion-tracking is universally an add-on to a parent sales role, framing B is right.

Asks of the WG / implementers

• Are there agents you'd build/operate that would claim only a performance-sales specialism, with no overlap with sales-social / sales-catalog-driven / creative-ad-server?
• If conversion-tracking is always an add-on, does accepts_conversion_events: true as a capability boolean cover what your platform needs?

Out of scope

• Renaming sales-social. It's the parent role today; this RFC is about whether conversion-driven is a sibling.
• The event-tracking vs conversion-tracking naming question — only relevant if Framing A wins.

Refs

• Add specialism IDs for event-tracking, catalog, financials #3345 — reframe that closed the parent proposal
• Original triage of Add specialism IDs for event-tracking, catalog, financials #3345 raised the buyer-side-vs-sell-side framing concern that motivated this split-out

[bokelley]

Triage

Classification: RFC / proposal
Bucket(s): spec / protocol
Status: ready-for-human
Milestone: 3.1.0

What the experts said:

• ad-tech-protocol-expert: sales-social storyboard already lists sync_event_sources as a required_tool and runs full event_setup/event_logging phases — Framing A creates a storyboard collision; the established precedent for this situation is the sales-proposal-mode → media_buy.supports_proposals capability-gate deprecation.
• adtech-product-expert: No real platform (Meta, TikTok, LinkedIn, Google PMax) claims only a performance-sales identity — conversion tracking is a measurement commitment on top of a primary sales role; media_buy.conversion_tracking in get_adcp_capabilities already provides richer signal than a boolean (supported_event_types, attribution_windows, multi_source_event_dedup).

My take: The RFC is largely answered by the existing codebase — sales-social already requires the conversion-tracking tools and the capability signal is live. The remaining open question is whether to ship a one-line description update to close the documentation gap, or simply close the RFC as resolved-by-existing-infrastructure.

@bokelley, your call: close as resolved (no code change needed), or ship a patch PR updating sales-social's description to match sales-catalog-driven's?

Option A — new performance-sales specialism (experts advise against):

// enums/specialism.json
+ "performance-sales",   // requires new storyboard; overlaps sales-social event_setup/event_logging
  "sales-social",        // storyboard already requires sync_event_sources + log_event

Creates a redundant storyboard; platforms claiming both run duplicate required-tool checks with no new coverage.

Option B — description patch (experts recommend):

// enums/specialism.json — enumDescriptions
- "sales-social": "Social media advertising platform with self-service flows",
+ "sales-social": "Social media advertising platform with self-service flows and conversion tracking",

media_buy.conversion_tracking in get_adcp_capabilities is already the canonical capability signal — no new enum value, no new storyboard, zero adoption friction for existing sales-social implementations.

---

Triaged by Claude Code. Session: https://claude.ai/code/cse_01LkczqXDPrCEZ82LvgxSFNv

---

Generated by Claude Code