# Give every rep a Clay prospecting desk without a Clay seat

> Each rep opens one screen, works only their own territory from your enriched Clay lists, and claims records straight into Salesforce.

- Workflow type: app
- Services: Clay, Salesforce
- Categories: Sales
- Published: 2026-08-16

## What it does

- Gives each rep a ranked daily worklist of only the accounts and contacts in their own territory, pulled from the enriched lists your ops team already builds in Clay.
- Puts the details that decide a call right on the card: job title, company name and size, and any hiring or funding signals you track, with a button to request deeper research on a single account when a rep wants it.
- Checks every record against Salesforce before a rep works it, so nobody spends time on someone who is already in the system.
- Claiming a record writes it into Salesforce with the research summary attached, removes it from every other rep's list immediately, and ticks down a personal counter of how many accounts each rep has left to work this week.

## What you'll need

- A Clay account containing your enriched account and contact tables
- An owner or rep field on each Clay row so the app knows whose territory a record belongs to
- A Salesforce login with permission to create leads and add notes
- A saved Clay research routine, if you want the deeper research button on each card
- Each rep signed in with their own login, since the whole point is that everyone sees a different list

## Prompt

Build an internal prospecting desk that each of my sales reps opens daily to work their own territory. The source of truth for the list is Clay, but the reps do not have Clay seats and should never need to open Clay or fight a spreadsheet UI. Ops builds and enriches the account and contact tables centrally in Clay, and this app is the per-rep, filtered, claimable view on top of them.

The main view is a ranked worklist. Load rows with the Clay Query Tables operation against our enriched account table and contact table, and filter to the signed-in rep by matching the owner field stored on each row against the rep's identity. This filter is not cosmetic and must not be flattened into one shared table: a rep may only ever see their own territory. Query Tables is cursor paginated, so page through it and keep the worklist responsive rather than loading everything at once.

Each row renders as a card carrying the enrichment fields a rep actually decides on: contact name and job title, company name and size, and any hiring or funding signals we store on the row. Rank the list so the strongest signals sort to the top, and let the rep sort and filter by signal type, company size, and whether the record has been checked against the CRM yet.

Before a rep works a record, check it against Salesforce. Use Get Many Leads with a SOQL query matching on the record's email address, falling back to the company domain, and mark the card clearly when a matching lead already exists so reps never touch someone already in the system. Show who owns the existing lead when Salesforce returns one. Run this check as the worklist loads and cache the result per row, so the rep is not waiting on the CRM on every scroll.

Each card has a button to request deeper research on that one account. It fires our Claygent routine for just that row using Run a Routine with a single inline item, which sits well inside the 100 item inline limit. Run a Routine is asynchronous and returns a routine_run_id, so do not block the UI waiting on it. Put the card into a pending state, store the routine_run_id against the row, and poll Get Routine Run Results until the status reaches a terminal value of complete, failed, or validation_failed. On completion, stream the research summary back onto that card in place. On failure, show it on the card and let the rep retry.

The Claim button is how a rep takes a record. Claiming writes it into Salesforce with Create or Update Lead (Upsert), so an existing lead is updated rather than duplicated, then attaches the Clay research summary using Add Note to Lead. Claims must be exclusive: store the claim in the app's own storage keyed by the Clay row id along with the claiming rep and a timestamp, and enforce uniqueness on that row id so the first claim wins. The moment a row is claimed it disappears from every other rep's worklist, and a second rep attempting the same row gets a clear message that it is already claimed and by whom. Claimed rows stay visible to the rep who claimed them.

Show each rep a simple counter of how many accounts they still have left to work this week, measured as their remaining territory rows against a weekly target and counting down as they claim. It is per rep, it resets weekly, and it sits at the top of the worklist.

Clay table ids and the routine id are not discoverable through the Clay API, so give an admin a settings view to paste them in, along with the name of the owner field used for territory matching and the weekly target. If the team runs HubSpot instead of Salesforce, the same flow works with Search Contacts for the duplicate check, Batch Upsert Contacts for the claim, and Create Note for the research summary.

## How to customize

- Change how the worklist is ranked, so the signals your team cares about most sort to the top
- Set the weekly target each rep counts down against, or vary it by role or seniority
- Choose which enrichment fields appear on the card, and which are tucked behind a details view
- Swap Salesforce for HubSpot if that is the CRM your team runs, keeping the same duplicate check and claim behavior

## FAQ

### Do my reps each need their own Clay seat?

No, and that is the main reason to build this. Your ops team builds and enriches the lists centrally in Clay, and this app is the view your reps work out of. They get a personal, filtered list without logging into Clay or being given a seat.

### What stops two reps from calling the same person?

Claims are exclusive. The first rep to claim a record gets it, and it disappears from every other rep's list right away. If a second rep tries to claim the same record, they are told it has already been claimed and by whom.

### Will this create duplicate leads in our CRM?

No. Every record is checked against Salesforce before a rep works it, and the card is flagged when a matching lead already exists. When a rep claims a record it updates the existing lead rather than creating a second copy.

### We use HubSpot instead of Salesforce. Can this still work?

Yes. The same flow works on HubSpot, looking up existing contacts for the duplicate check, creating or updating the contact when a rep claims it, and attaching the research summary as a note.

### How long does the deeper research take to come back?

It runs in the background, so nothing freezes while a rep waits. The card shows a pending state as soon as the request is made and fills in with the research summary once it finishes, which means reps can keep working the rest of their list.

Use this prompt in General Input: https://www.generalinput.com/prompts/give-every-rep-a-clay-prospecting-desk-without-a-clay-seat