A morning summary of how every lead is engaging, written into the CRM
Every weekday morning a Make scenario pulls the active leads and contacts from the CRM, gathers their recent activity and engagement signals from a sales-engagement tool, has Claude summarise each one into structured fields, writes the summary back to the record and posts the totals to Slack.
Where this applies
Sales teams that want a current, plain-language read of how each lead and contact is engaging, written where reps already look.
- weekday runs, no errors
- 45
- entries in the run log
- 13,312
- CRM record types covered
- 2
The problem
A rep opening a lead wants to know one thing first: is this person engaging? The answer is spread across emails opened, replies, calls and sequence steps in more than one tool, and reading it record by record is the work that gets skipped.
A dashboard of raw counts doesn't answer the question either. What helps is a short read-out on the record itself, current as of this morning and produced the same way for every lead, from a batch that survives the records with missing or odd data.
What we built
Two record types, one pass
The run queries the CRM twice, once for contacts and once for leads, and a router sends each set through its own iterator. Both paths do the same work against the CRM's two object types, so a contact who has already converted is read the same way as a new lead.
Gathering the signals
For each record, raw API calls fetch recent activity from the CRM and engagement and enrichment data from the sales-engagement tool. Each call has a Skip handler: a record whose call fails is left for the next run, and the rest of the batch carries on.
Claude writes, JSON sets the shape
The gathered activity is transformed into one JSON payload for Claude, and the answer is parsed into structured fields before it touches the record. The CRM receives fields rather than free text, and every update is logged in a data store.
Totals to Slack
A third route counts records with two aggregate queries and posts the totals to Slack, so the team sees each morning that the refresh ran and how much it covered.
Done before the day starts
The scenario runs at four and five in the morning, Eastern time, on weekdays, with further runs around midday, so the read-out is current when reps start work.
The outcome
The scenario ran 45 times between 18 September and 20 October 2026, with no errors.
Its data-store log held 13,312 entries on 21 October.
Where it stops
The summary is as current as the last run, not live. It summarises; it does not score or route leads, and nothing checks Claude's summary against the activity it was given. A record skipped because a call failed keeps its previous summary, and nothing flags it. A companion weekly cost summary is not described.
Built with
- Make.com
- Salesforce
- Apollo
- Anthropic Claude
- Slack
- Make data store
Patterns used
- Parallel object paths
- Skip per record
- LLM output parsed to fields
- Run log in a data store
Page copy drafted with AI assistance. Skofi is accountable for it. Editorial policy
Have something shaped like this?
If any part of the above resembles a problem you are living with, a short call is the fastest way to find out whether it is the same problem underneath.
What happens on the call
- 15 minutes, no deck
- We map the process on the call
- A written scope, or an honest no