RevOps and CRM Skills for AI Agents

Purpose

Find and safely merge duplicate contacts and companies before they split your reporting.

Inputs

• A contact export from HubSpot, Pipedrive, or Salesforce with email, name, company, and owner
• Your rule for which record wins a merge

Steps

1. Group records by exact email match and flag every group with more than one record.
2. Do a second pass matching on normalized name plus company domain to catch typo and alias duplicates.
3. For each duplicate group, pick the surviving record using your win rule, defaulting to the one with the most activity and a filled owner.
4. List which fields differ across the group so no data is lost in the merge.
5. Flag any duplicates owned by different reps for a human to review before merging.
6. Produce a merge sheet with the keep record, the merge records, and the fields to carry over.

Output

A review ready spreadsheet of duplicate groups with a recommended keep record and merge action for each.

Purpose

Find inconsistent CRM property names and produce a standardized rename and merge plan.

Inputs

• Export of all custom and default property names with types and usage counts
• Your naming convention rules (case style, prefixes, allowed abbreviations)
• List of objects to scan (Contact, Company, Deal)

Steps

1. Pull the full property list per object with internal name, label, type, and record fill rate.
2. Group properties that appear to capture the same data using label similarity and type match.
3. Flag violations of the convention such as mixed case, unclear abbreviations, or duplicate concepts.
4. For each duplicate group, pick a canonical field based on highest fill rate and cleanest name.
5. Draft a rename map and a merge plan noting which fields to deprecate and their data destination.
6. Add a risk note for any field used in active workflows, reports, or integrations.

Output

A table of current fields, proposed canonical names, merge targets, and a flagged risk list for review before changes.

Purpose

Turn dormant closed-lost deals into a ranked reactivation queue when timing and account signals line up.

Inputs

• CRM export of closed-lost opportunities with loss reason and close date
• Original deal owner and last activity date
• Access to Clay for signal enrichment

Steps

1. Pull all closed-lost deals and drop any lost for permanent reasons like out of business or no budget authority ever.
2. Filter to deals closed between 6 and 18 months ago where the loss reason was timing, budget cycle, or lost to competitor.
3. Enrich each account for change signals such as new funding, leadership hires, or tool switches.
4. Score each deal on a 0 to 100 scale weighting recency, signal strength, and original deal size.
5. Draft a one line re-open reason for each account referencing the original loss reason and the fresh signal.
6. Group the queue by prior owner and flag any owner who has since left.
7. Sort descending by score and cap the list at 40 per owner.

Output

A ranked reactivation queue with account, owner, re-open reason, and score, ready for CRM upload.

Purpose

Surface deals that have exceeded healthy time-in-stage limits and turn them into a prioritized escalation queue.

Inputs

• CRM deal export with stage, stage entry date, amount, owner, close date
• Median time-in-stage benchmark per stage (or let the agent compute from the data)
• Escalation thresholds (for example 1.5x median, 2x median)

Steps

1. Parse the export and compute days-in-current-stage for every open deal.
2. If benchmarks are missing, calculate median time-in-stage per stage from closed-won history.
3. Flag each deal against the 1.5x and 2x threshold tiers.
4. Rank flagged deals by amount times tier severity so large stalled deals rise first.
5. Assign a suggested next action per tier (rep nudge, manager review, forecast removal).
6. Group the queue by owner so each rep sees their own aged deals.
7. Note any deals with a close date already in the past for immediate cleanup.

Output

A ranked escalation queue table by owner with days-in-stage, threshold tier, suggested action, and a short manager summary of total at-risk pipeline value.

Purpose

Find likely duplicate account records and produce a survivor selection with a reviewable merge plan before any destructive change.

Inputs

• CRM account export CSV with name, domain, owner, created date, open deals, activity count
• Field priority rules for which record wins each conflict

Steps

1. Normalize company names and domains by lowercasing, stripping suffixes, and resolving common aliases.
2. Cluster records that share a root domain or a high name similarity score into candidate groups.
3. For each group, pick a survivor using rules such as most open pipeline, then most activity, then oldest created date.
4. Compare non-survivor fields against the survivor and flag conflicts that need a human decision.
5. List related objects like contacts and deals that must reparent to the survivor.
6. Assign a confidence tier and mark low confidence groups for manual review instead of auto merge.
7. Write the plan to a table an admin can approve row by row.

Output

A merge plan CSV listing each group, chosen survivor, records to merge, field conflicts, reparent counts, and confidence tier.

Purpose

Measure how complete key CRM fields are per record and rank the worst offenders for cleanup.

Inputs

• CRM export or API access (contacts, deals, accounts)
• List of required fields per object type with weights
• Minimum acceptable completeness threshold

Steps

1. Pull records for each object type and map them to the required-field list.
2. For every record, mark each required field as filled, empty, or placeholder (for example 'N/A', 'unknown', or a single character).
3. Apply field weights and compute a completeness score from 0 to 100 per record.
4. Roll scores up by owner, source, and creation month to expose where gaps cluster.
5. Flag records below the threshold and group them by the single missing field that would raise their score most.
6. Write a prioritized fix queue ordered by record value and ease of completion.

Output

A per-record score table, owner and source roll-up, and a ranked fix queue grouped by the highest-impact missing field.

Purpose

Check that inbound and outbound leads landed with the right owner and nothing fell through.

Inputs

• A lead export with source, created date, owner, territory or segment, and first response time
• Your routing rules, for example by region, company size, or source

Steps

1. Replay each lead against the routing rules and flag any whose actual owner does not match the rule.
2. Flag leads with no owner assigned or sitting in a default queue.
3. Measure first response time per lead and flag any over your service level, for example 24 hours.
4. Break misroutes down by rule so you can see which rule is leaking, for example a missing territory mapping.
5. Check for leads assigned to inactive or departed reps.
6. Summarize the miss rate and the slowest responding segments.

Output

A list of misrouted and unowned leads with the correct owner, plus a short summary of which routing rules need fixing.

Purpose

Check every CRM record against your written lifecycle stage rules and surface records that violate them.

Inputs

• CRM export of contacts and companies with lifecycle stage, stage entry date, and key activity fields
• Written definition of each stage and the criteria to enter or exit it
• Maximum days allowed in each stage

Steps

1. Load the stage definitions and turn each into a testable rule with entry criteria, exit criteria, and a day limit.
2. For every record, compare current stage against its actual field values to detect mismatches.
3. Flag records past the day limit for their stage with no forward movement.
4. Detect backward jumps and records that skipped a required stage.
5. Group violations by type and by owner.
6. Suggest the correct stage or next action for each flagged record.
7. Estimate pipeline value trapped in stuck stages.

Output

A table of violating records with violation type, correct stage, owner, and suggested action, plus a summary by owner and stage.

Purpose

Build an audit trail of every record owner change so reassignments are traceable and no accounts fall through the cracks.

Inputs

• CRM API access with property history enabled
• List of active and inactive user IDs
• Date range to scan

Steps

1. Pull owner change history for all open deals and target accounts in the range.
2. Flag records where the new owner is inactive, unassigned, or a queue rather than a person.
3. Detect churn patterns where a record changed owners three or more times in the window.
4. Cross reference each change against a known rep departure or territory update to label it expected or unexplained.
5. Group unexplained changes by prior owner and new owner to spot leakage between teams.
6. Rank accounts by pipeline value that landed with no active owner.

Output

A table of owner change events with flags, plus a shortlist of high value records needing immediate reassignment.

Purpose

Surface deals that have gone quiet and give each one a specific next action.

Inputs

• An open pipeline export with stage, amount, close date, owner, and last activity date
• Your definition of stalled, for example no activity in 14 days

Steps

1. Flag every deal past your stalled threshold and sort by amount so the biggest risks show first.
2. Flag deals whose close date has already passed but that are still marked open.
3. For each stalled deal, read the last logged activity and classify why it went quiet: no reply, waiting on us, waiting on them, or unknown.
4. Assign a next action per deal that matches the reason, such as a specific follow up, a stage correction, or a close lost.
5. Total the at risk amount so the owner sees the dollar stakes.
6. Group the output by owner so each rep gets their own list.

Output

A per rep action list of stalled deals with the reason, the next step, and the amount at stake.

Purpose

Surface imbalances in how accounts and leads are split across reps so managers can rebalance before a quarter starts.

Inputs

• CRM export of accounts with owner, region, employee count, and industry
• Current quota or target per rep
• Optional: open pipeline value per owner

Steps

1. Group all accounts by owner and count assigned accounts and leads per rep.
2. Weight each account by size using employee count buckets to estimate workload, not just raw count.
3. Compute per rep totals for weighted workload, open pipeline, and quota coverage.
4. Flag reps who sit more than 20 percent above or below the team median on any metric.
5. Check for stranded accounts with no owner or owners no longer active.
6. Suggest specific accounts to reassign from overloaded reps to underloaded reps, matching region where possible.

Output

A per rep balance table, a list of flagged imbalances, stranded account list, and a ranked set of reassignment moves with reasons.