Enrichment actions in the rep's browser

Built from the system Elliot O'Connor, founder and CEO at Frontier, described on GTM Vault SMYS 8 (https://pro.gtmvault.co/episodes/smys-08). Published free by GTM Vault. Frontier is the operator's own product and appears here only as the example on the record. The operator gave no result numbers in the episode; see The result.

When to use this

Use this when a RevOps or GTM engineering team has built enrichment and research workflows in Clay, and the sales reps cannot reach them because they work in the browser on LinkedIn, company websites and Salesforce. It fits larger sales teams where RevOps owns Clay and reps run on a separate contact data tool such as ZoomInfo or Apollo. It covers both paths: building the pattern in house, or evaluating a vendor extension that does it.

The system on the record

Elliot describes the buyer as RevOps, usually someone who already owns Clay, at a company that often runs Clay alongside ZoomInfo or Apollo. The reps live in the ZoomInfo world while the RevOps team lives in the Clay world (SMYS 8, 6:30). His extension is built to connect whatever data vendors the team uses, and to extend what go-to-market engineers can do to account executives and SDRs (SMYS 8, 6:30 and 7:29). The system runs in layers:

1. The gap. Clay's data was accessible to RevOps and marketing ops, but not to the average sales rep, so the team built a more rep-friendly interface as a Chrome extension (SMYS 8, 2:58). Earlier rep extensions he names are ZoomInfo, Apollo and Cognism (SMYS 8, 1:56).
2. Core actions. The first version moved contacts from LinkedIn and company sites, enriched them with contact data, and pushed them into the CRM and the sales engagement platform. Each email and phone number request is served from Clay tables (SMYS 8, 2:58). It started as sending prospects to Salesforce, which he calls table stakes (SMYS 8, 4:01).
3. RevOps-built workflows. Teams with 50, 100 or 1,000 sellers connect to a Clay account, RevOps builds custom workflows in it, and those workflows are connected to the extension so the whole rep team can use them (SMYS 8, 4:01). The extension can connect to as many Clay tables as the team wants (SMYS 8, 5:40).
4. One-click actions instead of prompts. Each button click would otherwise be a prompt in ChatGPT. The design abstracts the prompt away because he considers prompting a waste of time and tokens for people in sales (SMYS 8, 14:34). The page context is pulled out and fed into MCPs or Clay tables (SMYS 8, 16:23).
5. Example: buyer committee. On a company website, one button returns the list of people to sell to at that account, tuned to the rep's target buyer, with a Clay table running behind it through a dedicated column in Clay (SMYS 8, 14:34). He describes the buyer committee as one of the most popular workflows (SMYS 8, 18:10).
6. Example: company analysis. Before a meeting, a button the RevOps team built runs Clay agents with pre-built prompts on the company (SMYS 8, 16:23) and returns a short dossier covering product, partnerships, go-to-market and hiring. In the demo it surfaced account executive hiring across New York City and Toronto and a Chicago office opened four weeks earlier (SMYS 8, 17:26).
7. AI mode. The extension pulls records from Salesforce through Salesforce MCP, queries Clay's MCP for who the team sells to, and pushes the rep into Sales Navigator with generated titles and searches (SMYS 8, 11:29). Reps can move between chat mode and browser mode (SMYS 8, 13:31). It can also connect to workflows that automate message generation (SMYS 8, 13:31).
8. Chat for intent, browser for state. His position is that chat is good for expressing intent but not for managing state (SMYS 8, 12:28), and that for managing large lists of people the browser interface is better for his customers (SMYS 8, 13:31). Most of a rep's day is in the browser because it is the gateway to the buyer (SMYS 8, 15:21).
9. Deployment. Self-serve users found they had to build a lot on the Clay side or with MCPs before they got value, so access is gated. A template library generates Clay tables directly in the customer's workspace through Clay's API, and each customer gets a forward-deployed go-to-market engineer to tune the templates (SMYS 8, 19:40).
10. Cost structure. Most actions run on Clay tables that consume the customer's Clay credits (SMYS 8, 15:21). Frontier charges per seat. Some MCP features are free to the customer and others will be charged through usage-based AI credits because they cost inference (SMYS 8, 20:43).

The result

Elliot gave no result numbers for this system in the episode. Asked how much time it saves, he said it depends on what the rep is doing and showed the company analysis workflow instead of a figure (SMYS 8, 16:23). The scale facts on the record are deployment facts, not outcomes:

1. Cursor uses the extension across its teams worldwide (SMYS 8, 19:40).
2. Zoom runs it with 800 plus reps and different tables for different use cases (SMYS 8, 20:43).

Run it on your company

1. Ask once, in one message, for: the number of reps and their roles (SDR, AE, account manager); the pages reps spend the day on (LinkedIn, company websites, Salesforce, Sales Navigator); the data tools in place (Clay, plus ZoomInfo or Apollo if used) and who owns each; the CRM and sales engagement platform; the monthly Clay credit budget; whether Salesforce MCP and Clay MCP are available; the five research or data tasks reps repeat most per account; and whether the goal is to build the pattern or evaluate a vendor.
2. Map the access gap. List every workflow RevOps runs in Clay today and mark which ones reps cannot reach from their own surface. Output: a table with columns Workflow, Where it runs today, Who can run it, Page where the rep needs it, Times per rep per week.
3. Specify the core actions. Cover the base pattern on the record: capture a contact from the page, enrich email and phone from Clay, send to the CRM, send to the sales engagement platform. Output: a table with columns Action, Page context captured, Clay table or MCP called, Destination, Clay credits per run.
4. Turn the top workflows into buttons. Start with the two on the record: a buyer committee button and a pre-meeting company analysis button. For each, fix the prompt in the Clay table or agent so the rep never writes it. Output: one spec per button with inputs taken from the page, a fenced prompt block, the Clay table or agent behind it, and the output format the rep sees.
5. Design the AI mode flow. Define the prospecting path: pull account records from Salesforce through Salesforce MCP, query Clay MCP for the target buyer profile, generate titles and a Sales Navigator search. Mark which steps are intent (chat) and which are list work (browser). Output: a numbered step list with the MCP call at each step and a two-column split of Chat tasks and Browser tasks.
6. Plan the deployment. Generate the workflows as templates in the Clay workspace, then assign a GTM engineer to tune each one per team. Output: a rollout table with columns Team, Workflows, Template source, Tuning owner, Tuning needed, Go-live date.
7. Build the cost model. Price seats, Clay credits per action and inference for AI features separately. Output: a monthly cost table by component, with Clay credits per rep per week at expected usage.
8. If evaluating a vendor, score it against the pattern: connects to any Clay table the team builds, connects to Salesforce MCP and Clay MCP, works on the pages reps use, lets RevOps own and change the workflows, and states its credit and inference costs. Output: a table with columns Criterion, Pass rule, Vendor result, Notes.
9. Set the scorecard. Because no outcome numbers are on the record, measure your own baseline first: minutes to prepare for a meeting, minutes to build a buyer committee per account, contacts pushed to the CRM from the browser, button runs per rep per week, and Clay credits consumed. Output: a table with columns Metric, Baseline, Week 4, Week 12, reviewed weekly by RevOps.

Tools on the record

1. Clay: data and workflows behind the extension's one-click actions.
2. Clay MCP: agent access to Clay tables.
3. Salesforce MCP: CRM over Model Context Protocol.

Any tool doing the same job works; the method is the point. Full stack by layer: https://pro.gtmvault.co/stack/operator/elliot-o-connor

Where it breaks

1. No Clay-side build. Self-serve users found they needed to build a lot in Clay or with MCPs before they got value (SMYS 8, 19:40). The extension is only as useful as the workflows behind its buttons.
2. Small teams. A company with one or two sales reps does not want this level of flexibility and is likely better served by simpler tools (SMYS 8, 5:40).
3. No RevOps owner. The motion starts with someone in RevOps who owns Clay (SMYS 8, 6:30), and the workflows reps click are the ones RevOps builds (SMYS 8, 16:23). Without that owner there is nothing to extend to reps.
4. Untuned templates. Generated templates usually need tuning and customization per customer, which is why each deployment gets a GTM engineer (SMYS 8, 19:40). Shipping templates untouched gives reps generic output.
5. Credit and inference cost. Most actions consume Clay credits (SMYS 8, 15:21), and some AI features carry usage-based charges because they cost inference (SMYS 8, 20:43). A team that rolls buttons out to every rep without a credit budget will see cost scale with clicks.
6. Forcing list work into chat. Elliot argues chat handles intent but not state (SMYS 8, 12:28). Moving reps who manage large lists of people into a chat window loses the context on the page (SMYS 8, 16:23).
7. Dependency on the base layer. The features are built on top of what Clay and Salesforce MCP offer (SMYS 8, 22:46). Changes to those platforms, their pricing or their access change what the buttons can do.