RevOps Functions: Turn Your ICP Score + Enrichment Waterfall Into a Callable Tool (MCP Playbook)

RevOps functions are the new GTM primitive. Not dashboards. Not “workflows.” Functions.

Because reps do not want your beautiful RevOps logic. They want an answer. Fast. In the tool they live in. With receipts.

Clay’s MCP framing put language around what’s happening: Ops-built logic becomes callable. By reps. By agents. By anything that can pass inputs and read outputs. (clay.com)

TL;DR

• The trend: RevOps logic is shifting from one-off automations into reusable functions callable via agents and chat tools (MCP is the connector layer).
• A RevOps “function” has inputs, deterministic steps, outputs, and logs. If it can’t be traced, it’s not a function. It’s a vibe.
• Build these 5 first: ICP fit score, enrichment waterfall, persona detection, routing and owner assignment, personalization brief generator.
• Guardrails matter more than prompts: rate limits, vendor fallbacks, caching, PII boundaries, audit trails.
• Why this matters: it makes GTM repeatable and agent-ready. That’s where CRMs are heading. And yes, your current CRM stack is not ready.

---

Trend analysis: RevOps functions are replacing RevOps “projects”

RevOps used to ship “projects”:

• A lead scoring model in a spreadsheet
• A Zapier chain nobody can explain
• A routing rule that breaks every quarter
• An enrichment hackathon that works until the vendor rate-limits you

Now the market is demanding callable operations. Same logic. Packaged. Reused. Observable.

Why this is happening now

Three forces collided:

1. RevOps adoption pressure Gartner has been pushing the RevOps model hard, including the widely cited prediction that by 2026, 75% of the highest-growth companies will adopt RevOps. (gartner.com)
   More RevOps means more logic. More logic means more ways for it to rot.

2. Sales and marketing can’t even agree what “qualified” means Gartner found 49% of CSOs report sales and marketing definitions of a qualified lead differ greatly. That’s not a strategy problem. That’s an execution problem. (gartner.com)
   Functions fix execution. They force you to define inputs and outputs.

3. MCP standardized tool calling Model Context Protocol (MCP) is an open standard for connecting models to tools and data sources. Think: “USB-C for tools,” but for agentic systems. (docs.anthropic.com)
   Clay’s angle: Ops builds workflows once. Reps consume them in chat. (clay.com)
   Even Oracle and IBM are publishing explainers because the pattern is becoming unavoidable. (oracle.com)

The key shift

RevOps stops being “the team that maintains the CRM.”

RevOps becomes a product team that ships:

• a stable interface (function signature)
• predictable behavior (deterministic steps)
• measurable performance (logs + error rates)

---

Define “RevOps functions” (so you can actually build them)

A RevOps function is a reusable unit of go-to-market logic that any system can call.

A RevOps function has:

1. Inputs Clear schema. Required vs optional. Validation rules.

2. Deterministic steps Not “LLM magic.” A sequence you can explain:

• query
• enrich
• score
• route
• write brief
• return output

1. Outputs Structured. Typed. Versioned.

2. Logs Every call produces:

• which vendors were called
• what was returned
• what was cached
• who triggered it
• what policy was applied
• what failed and why

If you can’t audit it, you can’t scale it.

RevOps function vs workflow vs prompt

• Workflow: a chain of actions. Often brittle. Often hidden.
• Prompt: text. No guarantees.
• Function: an interface with a contract. You can test it. You can version it. You can call it anywhere.

This is why MCP matters. MCP is a standard interface for discovery and invocation of tools. (docs.anthropic.com)

---

Clay’s MCP framing, translated into operator terms

Clay said the quiet part out loud: RevOps builds GTM alpha in Clay. MCP makes it consumable in the chat interfaces reps live in. (clay.com)

Translation:

• Your “ICP score + enrichment waterfall” stops living in Clay.
• It becomes a callable tool: company_domain -> enriched_profile + score + next action.

That’s the playbook. The rest is implementation quality.

---

RevOps functions that matter: build these 5 first

These are the five functions that turn “data + rules” into “pipeline.”

1) ICP fit score function (the one score everyone fights about)

What it does

Takes a company (domain or CRM account ID). Returns:

• fit score (0-100)
• reason codes (top 5 drivers)
• disqualifiers (hard fails)
• confidence level (how complete the data was)

Inputs

• domain (required) or account_id
• icp_version (required)
• market (optional)
• product_line (optional)

Deterministic steps

1. Normalize domain (strip redirects, subsidiaries if you can)
2. Pull firmographics (employee count, revenue band, HQ region, industry)
3. Pull technographics if relevant (CRM, data warehouse, cloud stack)
4. Apply scoring model (rules or model, but output must be stable)
5. Produce reason codes and confidence

Output schema (example)

{
  "fit_score": 82,
  "fit_tier": "A",
  "reason_codes": [
    "Headcount 200-1000",
    "Uses Salesforce",
    "US-based HQ",
    "Hiring SDRs",
    "Industry = Logistics SaaS"
  ],
  "disqualifiers": [],
  "confidence": 0.76,
  "icp_version": "2026-04-15"
}

Operator notes

• Reason codes stop internal fights. Sales hates black boxes.
• Confidence prevents “garbage in, false precision out.”

If you want this score to drive outbound prioritization, pair it with intent. Dual scoring wins. Chronic bakes this into AI lead scoring so prioritization stays tied to pipeline, not opinions.

---

2) Enrichment waterfall function (because data decays while you sleep)

Your database is rotting. Constantly. Some sources cite about ~22% annual B2B data decay (~2.1% monthly) for contact records. Treat the exact number as directionally useful. Treat the problem as guaranteed. (cleanlist.ai)

What it does

Given a company or contact, run a prioritized set of vendors until required fields meet minimum completeness and confidence.

Inputs

• domain or company_name
• required_fields (e.g., ["industry","employee_count","hq_country"])
• contact_role (optional)
• freshness_sla_days (e.g., 30)
• max_cost_usd (optional)
• max_latency_ms (optional)

Deterministic steps

1. Check cache (freshness SLA)
2. Vendor A for cheap coverage
3. If missing fields, vendor B for depth
4. If phone required, vendor C specialized for phones
5. Validate and dedupe fields
6. Return final object plus provenance

Output should include provenance

Example:

{
  "company": { "employee_count": 430, "industry": "FinTech", "hq_country": "US" },
  "provenance": {
    "employee_count": { "source": "VendorB", "timestamp": "2026-04-28" },
    "industry": { "source": "VendorA", "timestamp": "2026-04-28" }
  },
  "completeness": 0.92,
  "cache_hit": false
}

Why it matters

A waterfall prevents two classic failures:

• overpaying for enrichment you didn’t need
• under-enriching and handing reps junk

This is exactly what Chronic productizes with lead enrichment. The key is not enrichment. It’s repeatable enrichment with logs.

---

3) Persona detection function (stop guessing who the buyer is)

What it does

Takes a contact profile and company context. Returns:

• persona label (finite set)
• seniority band
• department
• “likely cares about” topics
• exclusions (not a target)

Inputs

• contact_title (required)
• contact_department (optional)
• company_industry (optional)
• product_use_case (required)

Deterministic steps

1. Normalize title (strip fluff like “rockstar”)
2. Map to persona taxonomy (your taxonomy, not LinkedIn’s)
3. Apply company context overrides (same title means different things in different industries)
4. Return persona + confidence

Output example

{
  "persona": "RevOps Leader",
  "seniority": "Director+",
  "department": "Revenue Operations",
  "topics": ["pipeline hygiene", "routing", "data quality", "forecast accuracy"],
  "confidence": 0.81
}

Trend tie-in

Agents need clean labels. Persona detection turns messy human titles into something systems can route and message on.

---

4) Routing and owner assignment function (your SLA lives here)

Routing is where pipeline goes to die:

• wrong owner
• no owner
• “round robin” that ignores territory, segment, and capacity
• silent failures

What it does

Assigns an owner based on rules. Returns:

• owner user ID
• routing reason
• SLA timestamp
• fallback owner if errors occur

Inputs

• account_id or domain
• segment (SMB, MM, ENT)
• geo
• product_line
• source (inbound, outbound, partner)
• current_owner (optional)

Deterministic steps

1. Resolve territory
2. Check named account rules
3. Check capacity and availability (PTO, meeting load)
4. Assign owner
5. Log decision

Output example

{
  "owner_id": "u_12891",
  "owner_name": "Jordan Lee",
  "reason": "ENT + US-West territory + under capacity",
  "sla_minutes": 15,
  "fallback_owner_id": "u_00001"
}

Where this connects to the CRM trend

CRMs are moving from “systems of record” to “systems of action.” Routing as a function is action. Chronic runs this inside an end-to-end sales pipeline, not as a fragile set of CRM workflow rules that break when someone renames a field.

---

5) Personalization brief generator function (the brief, not the email)

Stop making AI write emails from raw data. That’s how you get hallucinated compliments and fake case studies.

Instead: generate a personalization brief that a rep can scan or an agent can use to write outbound.

What it does

Given enriched account + persona, produce:

• 3 relevant angles
• proof points you can actually claim
• 1 opener line options (fact-based)
• disallowed topics (compliance / brand)
• required CTA style

Inputs

• account_profile (required)
• persona (required)
• use_case (required)
• proof_library (your approved claims)
• tone (optional)

Deterministic steps

1. Extract top signals (hiring, tech stack, funding, product motion)
2. Match signals to approved plays
3. Draft angles and opener options
4. Validate against disallowed list
5. Return structured brief

Output example

{
  "angles": [
    { "angle": "Data hygiene", "why_now": "contact churn + stale routing", "proof": "reduces manual research time" },
    { "angle": "Speed to lead", "why_now": "inbound SLA misses", "proof": "faster owner assignment + auto-enrichment" }
  ],
  "openers": [
    "Saw you're hiring for RevOps and SDR Ops. Usually means routing and data hygiene are under pressure.",
    "Noticed your team runs Salesforce and a heavy outbound motion. Most teams hit list decay within a quarter."
  ],
  "cta": "15-min fit check",
  "disallowed": ["claim exact ROI without customer data", "mention competitor by name"]
}

Then write the email with a controlled writer. Chronic ships an AI email writer for exactly this division of labor: brief first, copy second.

---

Guardrails: the stuff that keeps your “callable tool” from becoming a security incident

If you are building callable functions for reps and agents, you are building production software. Treat it like it.

Rate limits (and throttling by design)

Vendors rate-limit. Your CRM rate-limits. Your own API gateway should rate-limit too.

Rules:

• Per-user limits (rep can’t melt the system)
• Per-org limits
• Burst limits and cooldowns
• Queue with retries for non-urgent calls

Vendor fallbacks (waterfalls need escape hatches)

Every function that calls an external vendor needs:

• timeout per vendor
• fallback vendor
• degrade mode (return partial but truthful result)
• error taxonomy (so you can measure vendor failure rates)

Caching (because enrichment is expensive and slow)

Cache aggressively, but correctly:

• cache key design (domain + icp_version + required_fields)
• TTL by field volatility (employee count changes slower than hiring signals)
• negative caching (avoid re-querying known-bad domains for 24 hours)

PII boundaries (and what you should never send)

If you sell in the EU or touch EU residents, automated profiling can trigger GDPR considerations. Article 22 covers automated decision-making and profiling that produces legal or similarly significant effects. Most lead scoring does not hit that threshold. Still, set boundaries like an adult. (gdpr-info.eu)

Practical policies:

• Never send full email bodies to enrichment vendors
• Do not store raw scraped personal data unless you can justify purpose and retention
• Separate “company scoring” from “individual scoring” where possible
• Mask or hash identifiers in logs

Audit trails (the part nobody budgets for)

Every function call should log:

• who invoked it (user, agent, API key)
• what inputs were used (with PII redaction)
• what outputs were returned
• which vendors were called
• policy decisions (why a fallback triggered)
• write actions (if it updated CRM records)

MCP itself includes security primitives like capability declarations and auth patterns, but you still own operational security. (semantic.io)
Also, MCP has had security concerns raised publicly. Treat tool calling as an attack surface. (tomshardware.com)

---

How RevOps functions plug into MCP (without turning your stack into spaghetti)

You do not “adopt MCP.” You expose your RevOps functions behind a stable interface.

Minimal architecture

• Function registry (what functions exist, schemas, versions)
• Execution layer (runs steps, handles retries)
• Vendor adapters (enrichment, intent, CRM, email)
• Policy layer (PII, permissions)
• Logging + metrics

MCP sits at the edge as the standardized way for an agent or app to discover and invoke those tools. (docs.anthropic.com)

The operational win

Reps stop filing Slack tickets like:

• “Can you pull a list of X?”
• “Can you enrich these 200 accounts?”
• “Who owns this lead?”

They call a function. Or the agent calls it. Same result.

---

What this means for your CRM (and why “agent-ready” is now a requirement)

CRMs are heading toward a world where:

• the record is table stakes
• the action is the differentiator
• the system ships decisions, not fields

That lines up with Forrester’s drumbeat that GTM teams need to integrate genAI into GTM applications as buyers change how they discover info. (forrester.com)

So here’s the stance:

If your RevOps logic isn’t callable, it isn’t reusable.
If it isn’t reusable, agents can’t run it.
If agents can’t run it, you are buying more headcount to do what functions should do.

And yes, your stack probably looks like:

• Salesforce or HubSpot for records
• Apollo for data
• Clay for workflows
• Instantly for sending
• a spreadsheet for scoring
• a Slack channel for routing failures

That’s not a system. That’s a coping mechanism.

Chronic’s thesis is simple: pipeline on autopilot. End-to-end, till the meeting is booked. If you’re comparing, start here:

• Chronic vs Salesforce
• Chronic vs HubSpot
• Chronic vs Apollo

And if you want the broader stack view before you buy five tools again:

• CRM vs Sales Engagement vs “Agentic CRM”: A 2026 Buyer’s Map
• Embedded GenAI vs Standalone Tools: The 2026 Sales Stack Decision
• Context Engineering for Sales AI: The 21-Item CRM Checklist

---

FAQ

What are RevOps functions?

RevOps functions are reusable units of go-to-market logic with defined inputs, deterministic steps, structured outputs, and audit logs. They package things like scoring, enrichment, routing, and personalization into callable tools that reps and agents can use on demand.

How is a RevOps function different from a CRM workflow?

A CRM workflow is usually platform-specific and brittle. A RevOps function has a versioned interface, validation, observability, and portability. You can test it, log it, and call it from any interface, including chat and agents.

Why does MCP matter for RevOps functions?

MCP provides a standard way for AI applications to discover and invoke tools and data sources. That makes your RevOps functions easier to plug into agentic experiences without building one-off connectors for every model or app. (docs.anthropic.com)

What guardrails matter most when turning enrichment into a callable tool?

Five guardrails: rate limits, vendor fallbacks, caching, PII boundaries, and audit trails. Without them, callable enrichment becomes slow, expensive, risky, and impossible to debug.

Which function should I build first?

Start with the ICP fit score function if you have clear qualification criteria. If your data quality is a mess, start with the enrichment waterfall function. Scoring without reliable data is fake precision.

Does automated scoring violate GDPR?

Not automatically. GDPR Article 22 focuses on decisions based solely on automated processing that produce legal or similarly significant effects. Most B2B lead scoring does not. Still, set PII boundaries, transparency, retention rules, and an audit trail to reduce risk. (gdpr-info.eu)

---

Build your first 5 RevOps functions this quarter

Do it in this order. Ship fast. Version everything.

1. Enrichment waterfall (so data stops lying)
2. ICP fit score (so prioritization stops being political)
3. Routing + owner assignment (so SLA stops slipping)
4. Persona detection (so messaging stops being generic)
5. Personalization brief generator (so outbound stops hallucinating)

Then expose them as callable tools. MCP or not. The interface is the point.

If you want this whole system to run without duct tape, build it where the pipeline lives:

• Define your ICP once with an ICP builder
• Enrich continuously with a real lead enrichment waterfall
• Prioritize with AI lead scoring
• Generate briefs and copy with an AI email writer
• Track it all in a sales pipeline

That’s RevOps functions in production. Not a Notion doc. Not a Clay table. A callable system that books meetings.