GTM Playbooks
Get it built
ResearchIntermediateClay CLI build included

Send Reps a Researched Account Brief Before Every Meeting

The 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.

Implementation steps

  1. 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. 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. 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. 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. 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. 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

The structure to recreate in your own workspace. Field names and thresholds are starting points.

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

Build it in Clay

Clay CLI v1.3.1

Copy these commands into your own Clay CLI. They run in your Clay workspace under your login. Nothing runs on our side, and this site never sees your Clay data or login.

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.

Not tested by GTM Playbooks

This build was written from the Clay CLI v1.3.1 help output, not from a run. Anything marked “Verify in your workspace”, and every line tagged VERIFY in the script, uses a shape that help does not document. Workflow runs can spend your Clay credits.

Part 1: Before you start

  1. 1.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.

  2. 2.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

  3. 3.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 <workspaceId>

  4. 4.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 <packageId> <actionKey>

  5. 5.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.

  6. 6.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.

Part 2: Workflow spec

What the script builds: 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 in your workspace: 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
Intro call
scheduled_at
Meeting start time
2026-10-20 15:00 UTC
rep_email
Meeting owner email
rep@yourdomain.com
rep_first_name
Meeting owner first name
Sam
attendee_email
Primary external attendee email
jane@example.com
attendee_name
Primary external attendee name
Jane Doe
company_domain
Attendee company domain
example.com
other_attendees
Other external attendee emails, comma separated
lee@example.com
  1. 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.

    Reads
    attendee_emailcompany_domain
    Writes
    crm_historycontact_idcompany_iddeal_id

    Verify in your workspace: 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. 2

    Enrich the company and attendee

    action

    Adds headcount, industry, headquarters, funding where available, and the attendee title and seniority.

    Reads
    company_domainattendee_email
    Writes
    company_namecompany_summaryattendee_title

    Verify in your workspace: 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. 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.

    Reads
    company_domain
    Writes
    research

    Prompt

    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. 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.

    Reads
    rep_first_nameattendee_nameattendee_titlecompany_namescheduled_atmeeting_titlecrm_historycompany_summaryresearch
    Writes
    brief

    Prompt

    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. 5

    Send the brief in Slack

    action

    Sends the brief to the rep as a direct message, with the meeting time and other attendees.

    Reads
    rep_emailmeeting_titlescheduled_atother_attendeesbrief
    Writes
    Slack message

    Verify in your workspace: 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. 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.

    Reads
    contact_idcompany_iddeal_idbrief
    Writes
    CRM record

Part 3: Build script

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.

Save it as build-meeting-brief.sh, fill in the 12 action ids at the top, then run bash build-meeting-brief.sh.

build-meeting-brief.sh

#!/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 recordLOOKUP_ACTION_KEY=""ENRICH_PACKAGE_ID=""   # Enrich company (and person) by domain or emailENRICH_ACTION_KEY=""RESEARCH_PACKAGE_ID="" # Claygent or another AI web research actionRESEARCH_ACTION_KEY=""WRITER_PACKAGE_ID=""   # Use AI or another AI text actionWRITER_ACTION_KEY=""SLACK_PACKAGE_ID=""    # Slack: send messageSLACK_ACTION_KEY=""CRM_PACKAGE_ID=""      # HubSpot: create note, or Salesforce: update recordCRM_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; }donecommand -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-briefcd clay-meeting-brief echo "1/10 Create the workflow"clay workflows create --name "Pre-meeting account brief" > workflow.jsonWF_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.jsonTRG_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.jsonSTEP1_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.jsonSTEP2_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.jsonSTEP3_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.jsonSTEP4_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.jsonSTEP5_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.jsonclay workflows graph get "$WF_ID" --mode full > graph.json echo "9/10 Map step inputs"cat <<EOF Step inputs are specific to your workspace. Map them before validating:  Step 1 lookup:   attendee_email and company_domain  Step 2 enrich:   company_domain and attendee_email  Step 3 research: company_domain, and the research prompt with                   your buyer team and product category  Step 4 brief:    rep and attendee names, title, company, meeting                   time and title, CRM history, company, research  Step 5 Slack:    rep_email, meeting title and time, other attendees, brief  Step 6 CRM:      contact, company, and deal ids from step 1, briefMap them in the Clay UI${WF_URL:+ at $WF_URL}, or per node with:  clay workflows nodes get $WF_ID <nodeId>  clay workflows nodes update $WF_ID <nodeId> --input node.jsongraph.json in this folder shows the current nodes and edges. EOFread -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 <runId>"  fielse  echo "TEST_ROW is empty, skipping the test run."fi read -r -p "Publish the workflow now? [y/N] " answerif [[ "$answer" == [yY] ]]; then  clay workflows publish "$WF_ID" --name v1fi echo "Workflow $WF_ID, webhook trigger $TRG_ID. All responses are saved in $(pwd)."

Part 4: Sample meeting payload

Save this as clay-meeting-brief/sample-meeting.json. Use a real company domain you are allowed to research and your own email as rep_email, so the Slack message only reaches you.

sample-meeting.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"}

Part 5: 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" <runId>

See each step's output for that run

clay workflows runs steps "$WF_ID" <runId>

Verify in your workspace

The Clay CLI help does not document these details. Check each one before you rely on the build.

  • 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).

Keep going

Related playbooks

View all Research

Need help implementing a playbook?

Our team builds custom Clay workflows and AI automations for revenue teams.

Get it built for you