Skip to main content

​
What you get

The day after an event, Claude walks the attendees with you, people you are most likely to know first. It records who met each person and what was said, and turns the follow-ups you accept into tasks with owners. Every follow-up draft states its basis, so nobody gets thanked for coming when all heyBTW knows is that they RSVP’d.

​
Before you start

  • The event is in heyBTW with its registrations, and check-ins where you have them. See Record who registered and who came.
  • Best in the first two days after the event. The debrief prompt runs only in the wind_down window (the 14 days after the event).
  • For owners and open deals: your CRM connector in your client, or a CRM connected in heyBTW. See Connect.

​
The evidence rules

These come from the heybtw://guides/event-follow-up resource, which Claude reads. A follow-up claims only what heyBTW’s evidence supports for that person. Never thank someone for attending on an RSVP alone. Check-in can be missing, partial or bulk, so it is supporting evidence, never proof when you know better. heyBTW states a basis, never a confidence score. For a past event outside wind_down, there is no attendance-based follow-up at all.

​
Steps

1

Start the debrief

Say: “Debrief last night’s dinner.”Claude runs the debrief prompt. Without an event name it calls list_events with status: "past", proposes the most recent collab and confirms it with you. It calls get_event_details to read goal.clock.event_window as served. If more than two days have passed (event_context.days_since), it says so and goes on only if you want to.
2

Read the attendees and what is already committed

Claude calls get_event_details with include_contacts: true, include_registration_answers: true and contacts_limit: 100, paging with contacts_cursor. Each row carries attendance_status, checked_in, partner_source, the observations already recorded, and registration_answers. It calls get_due_tasks for follow-ups already committed, then tells you the counts by basis in plain words.
3

Tell Claude who met whom

Claude asks, person by person: who met them, and what was said. You can stop at any point.Say: “Marcus met Priya. She is evaluating in Q1 and wants a security review. Dana never came.”Claude calls record_observation once for the batch (at most 20 people), each item with person (their email), met_by (a teammate’s user_email or a partner’s partner_domain), and a note of at most 500 characters. It records attended_confirmed only when you say on your own that someone did or did not come. It never asks you to confirm attendance, and never infers who met someone from the roster.When Claude cites a registration answer, it quotes that person’s own registration_answers, word for word. It says so when answers are missing or truncated.
4

Capture on the day, if you can

Notes do not have to wait until morning. During or right after the event, say: “Log that Ana from Ferrocity met Luis at the bar; he asked about the procurement timeline.”Claude records it with record_observation on the collab, the same way. The debrief then reads it back and that person starts at a stronger basis.On the day, capture and don’t process: badge photos, contacts swapped in person, and one line per conversation (who from the team, who they met, what was said), all in one place the team shares. Before the doors open, read the roster with get_event_details include_contacts and contact_fields set to name, company and title, and decide who covers which guests.To mark who came when the platform does not check people in, send the host’s check-in or badge list to record_signups as CHECKED_IN. Rows can match people already on the event by linkedin_url or full name, so a list with no emails still lands; the preview names each match before you confirm. Someone who walked in without registering is recorded with their email as CHECKED_IN. Mark only the people a list, a check-in or your team says came.
5

Accept the follow-ups you want

For each person worth following up, Claude proposes an owner: the one your CRM shows for that person’s account, read through your own CRM connector. On each yes, it calls save_task with action: "create", owner_email, contact_email, proposed_by: "agent", a one-line reason, a due date (due_offset_days from the event day, or due_at), and observation_ref (the observation_id record_observation returned). One accepted follow-up is one call, never a bulk create.Then Claude drafts the message for that person’s basis, with one line stating the basis, for example “Personal note: Marcus met Priya (met_by)” or “Neutral: RSVP only, attendance unknown”. The draft goes to the owner through your own mail or chat connector. heyBTW is never the sender.
6

Save the follow-up lists

Say: “Save a list for each message type.”On your yes, Claude calls save_list once per type, named by basis, for example “Austin dinner, met or confirmed” and “Austin dinner, RSVP only”. It also says what the lists cannot see: a check-in nobody recorded, and cancellations a source does not keep.
7

Close out

Claude ends with the counts by basis, how many people it recorded, how many follow-ups you committed and skipped, and who is left unconfirmed or without registration answers. If you answered nothing, it still gives you that packet, and proposes one follow-up for the most senior checked-in attendee, saved only if you accept.

​
Pair it with your tools

​
What heyBTW will and won’t do

  • It records only what you say. An observation never changes attendance status or qualification.
  • Observations are append-only and visible only to your workspace.
  • It never sends a follow-up and never writes to your CRM. To put a note on the CRM contact, Claude uses your own CRM connector, joined on email.
  • What was said is never put on a task shared with partners.
  • Owners and open deals come from your CRM and are never copied into heyBTW.