Connecting Reachium to a CRM, Slack and Booking
What it does: gets leads, replies and bookings out of Reachium and into the systems your team actually works in, so nothing dies in an inbox nobody opened.
Run it when: more leads are arriving than one person can hold in their head, or someone asks "is this in the CRM?"
Time: an hour to decide and wire the first event, longer for a full sync.
Depends on: a running campaign generating events worth syncing.
Before you start
A named owner for the integration, because it will need maintaining
Knowing whether your receiver is reachable over public HTTPS
A list of which events a human actually needs to see
The steps
1. Pick the pattern with two questions.
Does this need to keep running with nobody watching? If no, and it is occasional, an assistant session can pull the data and write it into your CRM directly, with no setup at all. If yes, does Reachium push the event, or does your system reach in and pull? Reachium pushes means webhooks. Your system reaches in means the REST API. Most full integrations use both.
2. For continuous sync, create a webhook endpoint.
An HTTPS receiver you own, which can be n8n, Zapier, Make or your own code. Pick the events you actually want, not all of them.
3. Store the signing secret the moment it appears.
It is shown exactly once at creation and there is no way to retrieve it afterwards. Rotating it shows a new one, also once, and instantly kills the old.
4. Verify the signature before you trust anything.
Every delivery is signed with a timestamp and an HMAC. Verify against the raw request body before parsing it, and reject anything more than five minutes old. Skipping this means anyone who learns your URL can write into your CRM.
5. Choose the events by who needs to act.
Replies and flagged replies are the ones a human should see in near real time. Connection accepts, enrolments and lead state changes are high volume and belong in a batch. Account status changed matters, because it is how you find out a sender disconnected before a week of sends is lost.
6. Know what each event actually carries.
Reply events carry the full lead profile. Several of the lighter events carry only an id and a name, deliberately. Join on the LinkedIn profile URL, never on Reachium's internal lead id, because the profile URL means the same thing in both systems. When an event does not carry it, look it up once and cache the mapping.
7. Set Slack thresholds so people keep reading it.
A real-time ping for replies that need a human. A daily digest for volume events. Nothing at all for test pings, which arrive with every field empty whenever somebody clicks the test button. A Slack channel that fires forty times an hour gets muted in a week, and then it is worse than no channel.
8. Log events as activity, not as fields.
Each event's detail object is shaped differently, so write it to the timeline on the record rather than letting it overwrite core fields. And never log the reply agent's draft text as something the lead said, because it is not.
9. Add a reconciliation pass if the sync has to be complete.
Failed deliveries retry on a backoff and then die, and an endpoint that keeps failing eventually disables itself. If your CRM must be complete rather than best-effort, run a scheduled pull that catches whatever the webhooks missed. This is not optional for anything anyone reports on.
10. Keep booking simple.
The booking link belongs in reply messages (SOP 16) and at the top and bottom of every document (SOP 21), pulled from the brand profile so there is one canonical link. When someone books, the lead gets marked booked by a human in the inbox, and that is what fires downstream. It is not automatic meeting detection, so do not build reporting that assumes it is.
Do this / Not this
Do this | Not this |
|---|---|
Choose the pattern from "does it run unattended" | Wire a webhook for a one-off export |
Store the secret at creation | Assume you can read it back |
Verify every signature before parsing | Trust anything that hits the URL |
Join on the LinkedIn profile URL | Join on the internal lead id |
Real-time for replies, digest for volume | Every event into one Slack channel |
Reconcile on a schedule | Assume every delivery arrived |
One canonical booking link | Three links of unknown vintage |
Done when
The pattern is chosen and can be explained in one sentence
The endpoint exists, the secret is stored, and signature verification is live
Only the events someone acts on are subscribed
Slack carries replies in real time and everything else as a digest
Records join on the profile URL, with a cached mapping
A reconciliation job exists if completeness matters
One booking link, in the brand profile, used everywhere
Next: SOP 17, Reading the Numbers and Diagnosing the Funnel, now that the data has somewhere to go · Back to the index
