--- name: pre-meeting-account-brief description: "When a meeting is booked, pull CRM history, enrich the account in Clay, research recent news with Claygent, and send the rep a short brief in Slack. Use when reps walk into first calls after a quick scan of LinkedIn and the CRM, or skip prep entirely when the calendar is full, so they miss recent company news, past conversations, and open deal context the team already has." --- # Send Reps a Researched Account Brief Before Every Meeting Reps walk into first calls after a quick scan of LinkedIn and the CRM, or skip prep entirely when the calendar is full, so they miss recent company news, past conversations, and open deal context the team already has. ## When to use this skill - The user wants to set up or run this workflow: "Send Reps a Researched Account Brief Before Every Meeting". - The user describes this problem: Reps walk into first calls after a quick scan of LinkedIn and the CRM, or skip prep entirely when the calendar is full, so they miss recent company news, past conversations, and open deal context the team already has. ## At a glance - Category: Research - Difficulty: Intermediate - Time saved: 3 hours per week. This figure is an estimate, not a measured result. ## Tools Options separated by "or" are alternatives; use whichever the user already has. - Calendly or Chili Piper - Zapier or Make - Clay - Claygent - HubSpot or Salesforce - Slack ## Steps 1. Pick the trigger and the meetings worth a brief: Calendly's invitee created webhook, a Zapier or Make scenario on new Google Calendar or Outlook events, or a CRM workflow for Chili Piper bookings that land in the CRM, filtered to external attendees and the meeting types you prep for, such as first calls and demos 2. Send one webhook per meeting to Clay with the meeting title and time, the rep, the primary external attendee, the company domain, and the other attendee emails 3. Look up the contact, company, owner, open deals with stage, last activity, and recent notes or closed-lost reasons in HubSpot or Salesforce, then enrich the company (headcount, industry, headquarters, funding where available) and the attendee (title, seniority) in Clay 4. Have Claygent or another AI web research step check the company website, newsroom, careers page, and news from the last 90 days for launches, funding, leadership changes, open roles on the team you sell to, and tools that matter to you, returning a source URL for each finding and "not found" instead of a guess 5. Write a brief under 150 words with an AI step: who they are, what changed recently with links, where you stand from the CRM history, and three questions worth asking, marking anything unsupported as unknown 6. Send the brief to the rep in Slack and save it to the CRM, as a HubSpot note associated with the contact, company, and deal or in the Salesforce event description, and re-send meetings booked weeks ahead the day before so the news is current ## Template outline Field names, thresholds, and message text are starting points to adapt. ~~~text Clay Workflow (webhook trigger, one run per booked meeting): 1. Trigger: Calendly invitee created, Zapier or Make on new calendar events, or a CRM workflow; external attendees and chosen meeting types only 2. Webhook payload: meeting_title, scheduled_at, rep_email, rep_first_name, attendee_email, attendee_name, company_domain, other_attendees 3. CRM lookup: contact, company, owner, open deals (stage, amount), last activity, recent notes 4. Enrich: company (headcount, industry, HQ, funding) and attendee (title, seniority) 5. Claygent research (last 90 days, sources required): - Recent changes: launches, funding, leadership, expansion - Hiring: open roles on {{your_buyer_team}} - Tech notes relevant to {{your_product_category}} 6. AI brief (under 150 words): - Who they are - What changed recently (with links) - Where we stand (open deal, last touch, or "new to us") - Three questions worth asking 7. Slack DM to rep: meeting, time, other attendees, brief 8. CRM: HubSpot note on contact, company, and deal, or Salesforce event description 9. Optional: relay re-sends meetings booked more than a week out the day before Output: every qualifying meeting arrives with a short, sourced brief in Slack and on the CRM record before the call ~~~ ## Optional: build it with the Clay CLI This builds the brief as a Clay workflow with a webhook trigger. Each booked meeting becomes one run: look up the contact, company, and open deals in the CRM, enrich the company, research recent changes with a Claygent or another AI web research action, write a short brief, send it to the rep in Slack, and save it to the CRM. The Clay CLI cannot create tables, so this build uses a workflow. It enriches the primary external attendee; other attendees are listed in the brief as sent. Written against Clay CLI v1.3.1. Run these commands only in the user's own Clay workspace, logged in with their own account, after they confirm. Items marked VERIFY are config shapes the CLI help does not document; check them in the workspace before relying on them. ### Prerequisites - Install the Clay CLI: Use version 1.3.1 or later, installed from Clay's own instructions. This page does not include an install command because the CLI reference it was written from does not list one. You also need jq, which the script uses to read the JSON the CLI prints. - Log in to your workspace: Browser login is the default. Use the device flow on a headless machine. A static key in the CLAY_API_KEY environment variable also works. Workflow commands need the terracotta:cli scope, so an auth error that names it means your login cannot manage workflows. - Log in with a browser: `clay login` - Log in on a headless machine: `clay login --device` - Confirm who you are logged in as: `clay whoami` - Pick the workspace to build in: The workflow is created in your active workspace. Switch first if you belong to more than one. - List workspaces: `clay workspaces list` - Show the active workspace: `clay workspaces current` - Switch workspace: `clay workspaces switch ` - Find your action keys: Action package ids and keys are specific to your workspace. Save the catalog, search it for your CRM lookup action, a company enrichment, a Claygent or AI web research action, an AI text action, Slack, and your CRM note or update action, then paste their ids into the top of the script. Skip "clay workflows actions test": it spends credits. - Save the action catalog: `clay workflows actions list > catalog.json` - Search the catalog: `grep -Eio '"[^"]*(hubspot|salesforce|lookup|enrich company|claygent|research|use ai|generate|slack|note)[^"]*"' catalog.json | sort -u` - See an action's inputs and outputs: `clay workflows actions schema ` - Decide what sends meetings to the webhook: Use Calendly's invitee created webhook, or a Zapier or Make scenario that fires on new Google Calendar or Outlook events, through a relay that keeps only external attendees and the meeting types you prep for and flattens the payload to the sample fields. Chili Piper bookings land in your CRM, so send those from a CRM workflow where your edition supports webhooks. - Pick where the brief lives in the CRM: In HubSpot, a note associated with the contact, company, and deal shows on all three timelines. In Salesforce, the event description or a related task works. Create any custom fields before mapping step 6. ### Workflow: Pre-meeting account brief Trigger (webhook): A booking tool, a Zapier or Make relay, or a CRM workflow POSTs one JSON object per booked meeting to the trigger's webhook URL. The fields arrive as run inputs as-is. VERIFY: Calendly's webhook payload is nested, and calendar events list every attendee. A relay that picks the primary external attendee and flattens the rest to the sample fields keeps this workflow's inputs simple. Inputs (webhook payload fields): - meeting_title: Event or meeting type name (example: Intro call) - scheduled_at: Meeting start time (example: 2026-10-20 15:00 UTC) - rep_email: Meeting owner email (example: rep@yourdomain.com) - rep_first_name: Meeting owner first name (example: Sam) - attendee_email: Primary external attendee email (example: jane@example.com) - attendee_name: Primary external attendee name (example: Jane Doe) - company_domain: Attendee company domain (example: example.com) - other_attendees: Other external attendee emails, comma separated (example: lee@example.com) 1. Look up CRM history (action): Finds the contact, company, owner, open deals with stage, last activity, and recent notes in HubSpot or Salesforce by email and domain. - Inputs: attendee_email, company_domain - Outputs: crm_history, contact_id, company_id, deal_id - VERIFY: Pulling deals and notes for a contact can take more than one lookup. In Salesforce, a SOQL lookup can return related records in one step; in HubSpot, look up the contact, then its associated deals. 2. Enrich the company and attendee (action): Adds headcount, industry, headquarters, funding where available, and the attendee title and seniority. - Inputs: company_domain, attendee_email - Outputs: company_name, company_summary, attendee_title - VERIFY: Company and person enrichment are usually separate actions. Insert a second step for the attendee, or use the job title from the CRM lookup. 3. Research recent changes (action): A Claygent or AI web research action checks the website, newsroom, careers page, and news from the last 90 days and returns sourced findings. - Inputs: company_domain - Outputs: research - Prompt: ~~~text Research {{company_domain}} for a sales call. Check the company website, its newsroom or blog, its careers page, and recent news from the last 90 days. Return JSON with: - recent_changes: up to 3 items (launches, funding, acquisitions, leadership changes, expansions), each with a one-line summary and a source URL - hiring: teams with open roles and any role that relates to {{your_buyer_team}}, with the careers page URL - tech_notes: tools named on the site or in job posts that matter for {{your_product_category}} Write "not found" for any field you cannot support with a source. Do not guess. ~~~ 4. Write the brief (action): An AI text action turns the CRM history, company data, and research into a brief under 150 words with three questions. - Inputs: rep_first_name, attendee_name, attendee_title, company_name, scheduled_at, meeting_title, crm_history, company_summary, research - Outputs: brief - Prompt: ~~~text Write a pre-meeting brief for {{rep_first_name}}, who meets {{attendee_name}} ({{attendee_title}}) from {{company_name}} at {{scheduled_at}} for "{{meeting_title}}". Use only these inputs: CRM history: {{crm_history}} Company: {{company_summary}} Research: {{research}} Format, under 150 words: 1. Who they are (company, size, attendee role) 2. What changed recently, with links 3. Where we stand (open deal, last touch, past notes; say "new to us" if empty) 4. Three questions worth asking Say "unknown" instead of guessing. No em dashes. ~~~ 5. Send the brief in Slack (action): Sends the brief to the rep as a direct message, with the meeting time and other attendees. - Inputs: rep_email, meeting_title, scheduled_at, other_attendees, brief - Outputs: Slack message - VERIFY: Direct messages need the Slack user, not the email. Check whether your Slack action looks users up by email or needs a separate lookup step. 6. Save the brief to the CRM (action): Creates a note or updates the meeting record so the brief stays with the account after the call. - Inputs: contact_id, company_id, deal_id, brief - Outputs: CRM record ### Script: build-meeting-brief.sh Creates the workflow, the webhook trigger, and six steps, then pauses so you can map step inputs. It validates the graph, offers one test run, and asks before publishing. ~~~bash #!/usr/bin/env bash # Builds the "Pre-meeting account brief" Clay workflow # in YOUR Clay workspace, using YOUR Clay CLI login. # Written against Clay CLI v1.3.1. Not run or tested by GTM Playbooks. # Lines tagged VERIFY use a shape the CLI help does not document. set -euo pipefail # Copy these from catalog.json (see "Find your action keys"). LOOKUP_PACKAGE_ID="" # HubSpot or Salesforce: lookup record LOOKUP_ACTION_KEY="" ENRICH_PACKAGE_ID="" # Enrich company (and person) by domain or email ENRICH_ACTION_KEY="" RESEARCH_PACKAGE_ID="" # Claygent or another AI web research action RESEARCH_ACTION_KEY="" WRITER_PACKAGE_ID="" # Use AI or another AI text action WRITER_ACTION_KEY="" SLACK_PACKAGE_ID="" # Slack: send message SLACK_ACTION_KEY="" CRM_PACKAGE_ID="" # HubSpot: create note, or Salesforce: update record CRM_ACTION_KEY="" # One input to test before real traffic. Use yourself or a teammate. TEST_ROW='{"meeting_title":"","scheduled_at":"","rep_email":"","rep_first_name":"","attendee_email":"","attendee_name":"","company_domain":"","other_attendees":""}' for v in LOOKUP_PACKAGE_ID LOOKUP_ACTION_KEY ENRICH_PACKAGE_ID ENRICH_ACTION_KEY RESEARCH_PACKAGE_ID RESEARCH_ACTION_KEY WRITER_PACKAGE_ID WRITER_ACTION_KEY SLACK_PACKAGE_ID SLACK_ACTION_KEY CRM_PACKAGE_ID CRM_ACTION_KEY; do [[ -n "${!v}" ]] || { echo "Set $v at the top of this script." >&2; exit 1; } done command -v clay > /dev/null || { echo "Clay CLI not found on PATH." >&2; exit 1; } command -v jq > /dev/null || { echo "jq is required to read CLI output." >&2; exit 1; } clay whoami > /dev/null || { echo "Not logged in. Run: clay login" >&2; exit 1; } # VERIFY: only "workflows create" documents an "id" field in its output. read_id() { local id id=$(jq -r '.id // empty' "$1") [[ -n "$id" ]] || { echo "No id found in $1. Open it and adjust read_id." >&2; exit 1; } echo "$id" } mkdir -p clay-meeting-brief cd clay-meeting-brief echo "1/10 Create the workflow" clay workflows create --name "Pre-meeting account brief" > workflow.json WF_ID=$(read_id workflow.json) WF_URL=$(jq -r '.url // empty' workflow.json) echo "2/10 Add the webhook trigger" clay workflows triggers create "$WF_ID" --input '{"triggerType":"webhook","inputSchema":{"type":"object"}}' > trigger.json TRG_ID=$(read_id trigger.json) echo "3/10 Step 1: look up crm history" # VERIFY: help shows nodeType and name only; actionPackageId and actionKey are a guess. STEP1=$(jq -nc --arg p "$LOOKUP_PACKAGE_ID" --arg k "$LOOKUP_ACTION_KEY" '{nodeType: "tool", name: "Look up CRM history", actionPackageId: $p, actionKey: $k}') clay workflows nodes create "$WF_ID" --input "$STEP1" > step1.json STEP1_ID=$(read_id step1.json) echo "4/10 Step 2: enrich the company and attendee" # VERIFY: action fields inside "step" are inferred from the documented utility example. STEP2=$(jq -nc --arg n "$STEP1_ID" --arg p "$ENRICH_PACKAGE_ID" --arg k "$ENRICH_ACTION_KEY" '{target: {type: "after-node", nodeId: $n}, step: {kind: "action", actionPackageId: $p, actionKey: $k}}') clay workflows nodes insert "$WF_ID" --input "$STEP2" > step2.json STEP2_ID=$(read_id step2.json) echo "5/10 Step 3: research recent changes" # VERIFY: same inferred insert shape as step 2. STEP3=$(jq -nc --arg n "$STEP2_ID" --arg p "$RESEARCH_PACKAGE_ID" --arg k "$RESEARCH_ACTION_KEY" '{target: {type: "after-node", nodeId: $n}, step: {kind: "action", actionPackageId: $p, actionKey: $k}}') clay workflows nodes insert "$WF_ID" --input "$STEP3" > step3.json STEP3_ID=$(read_id step3.json) echo "6/10 Step 4: write the brief" # VERIFY: same inferred insert shape as step 2. STEP4=$(jq -nc --arg n "$STEP3_ID" --arg p "$WRITER_PACKAGE_ID" --arg k "$WRITER_ACTION_KEY" '{target: {type: "after-node", nodeId: $n}, step: {kind: "action", actionPackageId: $p, actionKey: $k}}') clay workflows nodes insert "$WF_ID" --input "$STEP4" > step4.json STEP4_ID=$(read_id step4.json) echo "7/10 Step 5: send the brief in slack" # VERIFY: same inferred insert shape as step 2. STEP5=$(jq -nc --arg n "$STEP4_ID" --arg p "$SLACK_PACKAGE_ID" --arg k "$SLACK_ACTION_KEY" '{target: {type: "after-node", nodeId: $n}, step: {kind: "action", actionPackageId: $p, actionKey: $k}}') clay workflows nodes insert "$WF_ID" --input "$STEP5" > step5.json STEP5_ID=$(read_id step5.json) echo "8/10 Step 6: save the brief to the crm" # VERIFY: same inferred insert shape as step 2. STEP6=$(jq -nc --arg n "$STEP5_ID" --arg p "$CRM_PACKAGE_ID" --arg k "$CRM_ACTION_KEY" '{target: {type: "after-node", nodeId: $n}, step: {kind: "action", actionPackageId: $p, actionKey: $k}}') clay workflows nodes insert "$WF_ID" --input "$STEP6" > step6.json clay workflows graph get "$WF_ID" --mode full > graph.json echo "9/10 Map step inputs" cat < clay workflows nodes update $WF_ID --input node.json graph.json in this folder shows the current nodes and edges. EOF read -r -p "Press Enter when inputs are mapped. " echo "10/10 Validate, test once, publish" clay workflows graph validate "$WF_ID" clay workflows diagram "$WF_ID" if jq -e 'all(.[]; . != "")' <<< "$TEST_ROW" > /dev/null; then read -r -p "Run TEST_ROW once? It can spend Clay credits, post to Slack, and write a note to your CRM. [y/N] " answer if [[ "$answer" == [yY] ]]; then clay workflows runs test "$WF_ID" --inputs "$TEST_ROW" > test-run.json echo "Saved test-run.json. Check each step with: clay workflows runs steps $WF_ID " fi else echo "TEST_ROW is empty, skipping the test run." fi read -r -p "Publish the workflow now? [y/N] " answer if [[ "$answer" == [yY] ]]; then clay workflows publish "$WF_ID" --name v1 fi echo "Workflow $WF_ID, webhook trigger $TRG_ID. All responses are saved in $(pwd)." ~~~ ### Sample meeting payload: sample-meeting.json ~~~json { "meeting_title": "Intro call", "scheduled_at": "2026-10-20 15:00 UTC", "rep_email": "rep@yourdomain.com", "rep_first_name": "Sam", "attendee_email": "jane@example.com", "attendee_name": "Jane Doe", "company_domain": "example.com", "other_attendees": "lee@example.com" } ~~~ ### Send it a meeting After publishing, read the webhook URL and send the sample payload once. Each POST is one run. - Load the saved ids (run inside clay-meeting-brief/): `WF_ID=$(jq -r '.id' workflow.json); TRG_ID=$(jq -r '.id' trigger.json)` - Read the webhook URL (argument order inferred, see the verify notes): `WEBHOOK_URL=$(clay workflows triggers get "$WF_ID" "$TRG_ID" | jq -r '.webhookUrl')` - Send the sample payload (needs a published workflow, one run per request): `curl -sS -X POST "$WEBHOOK_URL" -H 'Content-Type: application/json' --data @sample-meeting.json` - List runs: `clay workflows runs list "$WF_ID"` - Inspect one run: `clay workflows runs get "$WF_ID" ` - See each step's output for that run: `clay workflows runs steps "$WF_ID" ` ### Verify in the workspace - The webhook trigger shape comes from the CLI help, but the help does not say how "triggers get" orders its arguments. If the run commands fail, copy the webhook URL from the Clay UI instead. - The help documents "nodes create" with nodeType and name only. If it rejects actionPackageId and actionKey, create the node with a name only and pick the action in the Clay UI. - The reference says action steps take actionPackageId and actionKey but shows only a utility example for "nodes insert", so the placement of those fields inside "step" is inferred. - Only "workflows create" documents an id field in its response. The script reads .id from trigger and node responses too and stops if it is missing. - Package ids and action keys differ by workspace and depend on which integrations you have connected. Copy them from your catalog; this page does not guess them. - Step input mapping is dynamic per workspace. The CLI path is "nodes get" then "nodes update", where incomingEdges is a full replacement. The argument order for "nodes get" is inferred from "nodes update". - The help does not say whether step 1 connects to the trigger automatically. "clay workflows graph validate" reports a disconnected graph. - Meetings booked weeks ahead get a brief that ages. Have the relay send the same meeting again the day before, and the workflow writes a fresh brief. - "runs test" without --live is assumed to run the draft. The reference lists --live without describing it. - Workflow runs can spend Clay credits and write to connected tools. Exit code 3 means re-run clay login, and exit code 4 means you are rate limited (wait for details.retryAfter). ## Guardrails - Work only in the user's own accounts and workspaces, with their credentials. - Confirm with the user before any step that writes to a CRM, sends email or messages, spends credits, or moves money. - Treat every hours, cost, and threshold figure as a starting assumption and replace it with the user's numbers. - Do not invent data, prices, or results. If a vendor price matters, check the vendor's current pricing page. ## Source https://gtmplaybooks.io/playbooks/pre-meeting-account-brief/