> ## Documentation Index
> Fetch the complete documentation index at: https://heybtw.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# What each system knows

> Your event platform, your CRM and heyBTW each hold a different part of the story. How Claude joins them without copying one into another.

## What you get

A clear answer to "where does this fact come from?" for every question about your events. Your event platform knows who signed up. Your CRM knows owners, deals and activity. heyBTW knows the relationship across events: who came, who brought them, who on your team knows them, and what you learned. Claude joins the three on two keys and tells you which system each answer came from.

## Before you start

* Nothing to set up for this page. It explains what you set up in [Connect heyBTW next to your CRM and your event platform](https://heybtw.com/docs/playbooks/connect-crm-and-event-platform.md).

## Who holds what

| System | Holds | Reached by |
| - | - | - |
| Event platform (Luma, Splash, Zuddl, Partiful, a spreadsheet) | The event page, registrations, check-ins, registration answers | A sync connected in heyBTW, or an export you record |
| Your CRM | Account owners, deals and stages, amounts, logged activity, CRM tasks | Your own CRM connector in your client first; a CRM connected inside heyBTW for attribution |
| heyBTW | Collabs, sign-ups and attendance across every event, partner credit (`partner_source`), `known_by`, invite history, observations, tasks, lists, target spec, attribution it computes | The heyBTW connector |

## By question

| Question | Event platform | Your CRM | heyBTW |
| - | - | - | - |
| Who is the room for? | | Customers and open deals to include or leave out | The target spec, per workspace and per event |
| Who should we invite? | Followers | Contacts and accounts | Past attendance, who on the team knows them, invite history, city |
| Who did we invite, and how? | Its own invites only | Sequence steps, if logged | Every invite, from every channel, per person |
| Who said yes? | Its registrations | | Registrations from any source, with the platform's where it syncs |
| Who came? | Check-ins, when recorded | | Check-ins plus what the team says: who met whom, who really came |
| Which partner brought them? | | | Partner credit per person |
| Who followed up? | | Logged activity | Touch status per attendee, and committed follow-up tasks |
| Who owns the account, what deal is open? | | Owner, deal, stage, amount | References only, never copies |
| What did the event do for pipeline? | | Deals | Attribution per event, read from the CRM connected in heyBTW |

## Record what your tools did

heyBTW records; your own tools act. When Claude sends a message, creates a CRM task or holds a calendar slot through a tool you have connected, it records the result back in heyBTW so the next session sees it. Only what happened, never a draft.

| What happened | Recorded with |
| - | - |
| Invites you sent from your own tools | [activate\_list](https://heybtw.com/docs/tools/activate-list.md) `destination_type: "external"`, or [record\_observation](https://heybtw.com/docs/tools/record-observation.md) `invited` |
| A follow-up found in the CRM | record\_observation `followed_up` |
| A nudge sent to an owner, with the sent-message reference | record\_observation `nudged` |
| A follow-up you committed to | [save\_task](https://heybtw.com/docs/tools/save-task.md) |

People from other tools enter heyBTW one way, [import\_people](https://heybtw.com/docs/tools/import-people.md), and an import is never a sign-up. A guest list from an event goes to [record\_signups](https://heybtw.com/docs/tools/record-signups.md) instead.

## The join keys

Every CRM-dependent heyBTW result carries the keys Claude takes to your CRM:

* a person by `email`
* a company by `company_domain`

Results with a next step outside heyBTW name it in a `carry` block or a "Carry to:" line: the destination, `via: "your_tools"`, and the join keys. `crm_context` says which route to the CRM applies. This block is trimmed from a real response today:

```json theme={null}
{
  "connection_path": "dashboard",
  "provider": "attio",
  "status": "connected",
  "capability": "deal_read",
  "capability_served": true,
  "crm_joined": true,
  "crm_join_key": ["email", "company_domain"]
}
```

## Steps

**1. Ask a question that needs two systems**

Say: "Who from Harbor Ledger came to our events, and who owns that account?"

Claude calls [get\_relationship\_ledger](https://heybtw.com/docs/tools/get-relationship-ledger.md) with `domains: ["harborledger.com"]`, one row per person per event with `status`, `partner_source`, `known_by` and `via: "heybtw"`. Then it looks up the owner in your CRM connector, joined on `company_domain`, and says: "the owner, from your CRM, which heyBTW does not hold."

**2. Ask for a number heyBTW stands behind**

Say: "What pipeline did our events source this year?"

Claude uses the heyBTW tool, here [get\_event\_attribution](https://heybtw.com/docs/tools/get-event-attribution.md), and reads `crm_context` first. If no CRM is connected inside heyBTW and the tool returns a gap or a note, Claude says so. It never computes a number of its own and presents it under heyBTW's name.

**3. Ask for a quick CRM lookup**

Say: "Does Bluebell Insurance have an open deal?"

This is a lookup, not a heyBTW computation, so Claude uses your own CRM connector directly. It needs no setup inside heyBTW. If your client has no CRM connector, Claude tells you once which connector would complete it and carries on with what heyBTW holds.

**4. Check where a number came from**

Say: "Which of these numbers are not measured yet?"

Claude calls [get\_data\_health](https://heybtw.com/docs/tools/get-data-health.md). It names events with and without canonical attribution, unmatched partner sources, enrichment coverage, and `unmeasured_facts`, each with the resolver behind it in `fact_sources`.

## Reading answers that cross systems

* `via: "heybtw"` means heyBTW computed it. `via: "your_tools"` means your own connector does it.
* `status: "partial"` with a non-retryable gap is a disclosure, not a failure. Claude relays it and carries on.
* Null is unknown, never zero. A fact with no source is a gap.
* A person's location never comes from their company's address.

## Common combinations

| Combination | Good for |
| - | - |
| heyBTW + HubSpot, Salesforce or Attio | Who came, joined to owners, open deals and activity |
| heyBTW + Apollo, Clay or a Sales Navigator export | Finding new people for the room, checked against everyone you already know |
| heyBTW + Luma | Events, guest lists and check-ins that stay current, and invite sends |
| heyBTW + Gmail and Slack | Personal invites, follow-ups and owner nudges from your own accounts, recorded back in heyBTW |

## What heyBTW will and won't do

* heyBTW never copies CRM facts into heyBTW: no deal stage, owner or amount from your connector. It stores references and join keys; the CRM stays the source.
* heyBTW never writes to your CRM. A note on a CRM contact or a CRM task goes through your own connector.
* heyBTW cannot see your client's connectors, and nothing read through them reaches heyBTW.
* heyBTW never adds guests to your event platform, and a connected platform's records are never overwritten by an export.
* heyBTW serves facts with a basis. It never scores, tiers or ranks people.

## Related

* [Works with any CRM](https://heybtw.com/docs/playbooks/works-with-any-crm.md)
* [Connect heyBTW next to your CRM and your event platform](https://heybtw.com/docs/playbooks/connect-crm-and-event-platform.md)
* [Record who registered and who came](https://heybtw.com/docs/playbooks/record-who-came.md)
* [Responses](https://heybtw.com/docs/mcp/responses.md)
* [heyBTW MCP rules](https://heybtw.com/docs/mcp/rules.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.