Track the channels a person runs by hand, not only the ones a robot can

Most multichannel CRMs mean email plus one thing they automated. The problem is that the channels that work best for a small team are often the ones a person has to execute: a LinkedIn connection request, a call to a warm referral, a conversation at an event. Those channels usually vanish from reporting because nothing captures them. Here they get the same treatment as email.

The LinkedIn queue holds work items with the message drafted and ready to paste. A person sends it on LinkedIn, and the ledger records what happened: connection sent, connection accepted, conversation started, and whatever statuses you configure after that. Because the ledger is URL-first, the same profile stays one row across a re-queue, and per-profile attribution survives someone re-adding a prospect. linkedin_queue_add, linkedin_queue_add_contacts, linkedin_queue_list and linkedin_queue_update do the same job from an agent, which means a cadence's LinkedIn step can fill the queue while a human still does the sending.

Inbound is the other half. Web forms post into the CRM and become leads with their source, campaign and page attached. Calendly bookings arrive on a webhook and become meetings plus an inbound record, reconciled on a schedule so a booking made while a webhook was down still lands. inbound_log records anything else that came in, from a referral to a phone enquiry to an event conversation, with the same shape, and booking_list and booking_reconcile work the booking side.

Calls today are outbound through Vapi: call_start places one, call_status reads it back, and call_log writes the outcome and disposition against the record. That is the whole of the phone story that ships. Inbound numbers, routing rules, voicemail transcription, two-way SMS, a softphone with power dialling, and the AI receptionist are all on the roadmap with the local-services pack, and this page will not describe them as working until the changelog says they are.