Keep your CRM current: a nightly activity logger built with Claude

Keep your CRM current: a nightly activity logger built with Claude

Every CRM decays the same way. The interactions happen: a funder replies, a partner calls, a prospect meeting, but nobody types them into the record. Six months later you cannot reconstruct who spoke to whom, and the person who knew has left. The information is not missing, though: it already sits in your mail, your calendar, your meeting transcripts and your chat. An AI assistant with connectors to those sources can do the copying for you, every night. And it can do so better than manual or automated forwarding because it can summarize and has more context.

The pattern

One assistant, one scheduled owner, one comment per interaction. The logger reads the last 24 hours across your sources, posts exactly one comment per interaction on the matching organisation record, creates contacts it finds at organisations you already track, and fills in details it can verify.
Decision test: the logger records what happened, humans decide what it means. It never creates a new organisation, never sets a stage, never guesses a field. Anything needing judgement goes into the run report instead.

What to do

    Start from a working CRM. The logger needs organisations and contacts linked in both directions, as described in  Your CRM in Asana  . Without those links it cannot match a person to a record.
    Connect the sources on the account that will run it — mail, calendar, meeting transcripts, chat, and the CRM itself. A logger only sees what the person running it can see. Check your  AI policy  first: these connectors read real personal data.
    Write it down as a skill, not a prompt. A skill is a reusable instruction file that teaches the assistant a repeatable job. Hard-code the concrete IDs — project IDs, custom field IDs, exact tool names — rather than descriptions like "the customers project". Ambiguity here is where these break.
    Run it supervised once. Watch a full run, then tune two things: how names and email domains match to records, and what gets skipped — out-of-office replies, newsletters, bots, internal-only threads.
    Schedule it with exactly one owner. Ask your assistant: "Run the CRM activity logger every morning at 7." Everyone else runs it on demand. Two schedules means duplicate comments.
    Read the run report weekly. That is where new organisations, ambiguous matches and failures surface.

The setup prompt

Paste this into a fresh chat with your CRM and sources connected:
Help me build a CRM activity logger as a reusable skill.

Ask me about, then discover and confirm with real IDs:
1. Where my CRM lives — organisations location(s), contacts location, which connector
2. Field mapping — fetch one sample record from each and confirm every field ID
3. Which sources to monitor — mail, calendar, meeting transcripts, chat — and test
one call per source
4. Cadence and lookback window
5. Skip rules and my internal domains

Then write the skill so a run does this, in order:
- Load all CRM records, build a lookup of contact emails, org names and org email
domains
- Find interactions in the window using one broad search per source
- Post exactly one comment per interaction on the matching organisation record:
emoji + type + date + topic, a 2-3 sentence summary, next step if clear.
Check existing comments first and skip anything already logged.
- Create contacts for new people at known organisations; enrich missing fields
only when verifiable
- Keep contact-organisation links in sync — when writing a multi-value field,
always pass the full array or you delete the existing links
- Report: what was logged per source, what was created, what was skipped or
ambiguous

Never create a new organisation record — flag it for me instead.

What to watch

  • Duplicates. One scheduled run, one owner. On-demand runs by others are fine.
  • Authorship. Comments post as whoever ran it, not as a system account. Say so in the comment if that matters to your team.
  • Gaps. A fixed 24-hour lookback loses a day whenever a run fails. Storing a "last successful run" timestamp and looking back from there is more robust.
  • Link fields. Multi-value reference fields overwrite. Always write the full array.
  • Trust. Spot-check comments against the source for the first fortnight. A logger nobody verifies is worse than no logger.

Your variation

Record which sources you monitor, the cadence and lookback, who owns the scheduled run, your internal domains to ignore, and where the checkpoint lives.