Problem

Your system of record holds the truth. Appointments, callbacks, the schedule everything downstream depends on. But your team doesn't live inside the system of record during the working day. They live in their calendar. Whatever the system of record knows that the calendar doesn't is invisible to the people doing the work. They either keep two windows open and remember to cross-check, or they let things slip. When something slips, the relationship's trust degrades, the renewal probability falls, the case dies quietly. The naive fix is each person hand-copying entries onto their own calendar. That produces duplicates, drift, and forgotten records. The slightly less naive fix is to abandon the system of record's scheduling layer and let the calendar carry the truth, which works until compliance, audit, or recordkeeping needs those records and the disconnect costs you under review. Originally deployed against a dialer-centric insurance CRM. The same gap appears anywhere a calendar and a system of record live in separate places.

Architectural Solution

A continuous one-way sync that keeps the system of record authoritative and projects its truth onto the team's calendar within minutes. Built on the LionsHead Integration Library with a strict three-layer separation: handler interfaces speak workforce vocabulary only (employee_id, scheduled_at, is_complete, contact_phone), platform interpreters plus declarative configs handle each platform's wire conventions, and per-client config files supply the tenant pointers (calendar id, custom field projections, dedupe windows). The destination handler runs a two-layer dedupe pass on every record. An exact-marker lookup catches every event the bot has written before. A fuzzy adoption pass searches a configurable window around the scheduled time for events the user typed in by hand. When one matches, the bot patches it in place rather than creating a duplicate. State transitions are visual: a completed entry's event prefixes with [Done] and its colour mutes to graphite rather than disappearing. Three log streams keep operational, audit, and pipeline-trace concerns isolated. Operational logging answers 'is it running.' Audit logging is append-only with fsync per write and answers 'what did the bot do to this account.' The pipeline trace is JSON-Lines-per-day with pre-computed dimensional fields so BI tools ingest it without intermediate data engineering. A starter dashboard ships with the project and renders trailing-thirty-day totals in the terminal. A SQL file drops the same metrics into Tableau, Power BI, Looker Studio, Metabase, or Excel via Power Query.

Tangible Result

The team opens their calendar; the day is laid out. Each event title carries the client name and disposition, each location carries the dialable phone number, each description carries the notes left in the system of record the last time anyone touched the lead. Completed entries visually cross out in place rather than vanishing. Adopted manual entries stop generating duplicates after the first cycle. The compliance officer can reconstruct any individual event's lifecycle from the audit log. The principal can show a prospect or a renewal client a live dashboard of throughput against the trace stream, no manual data reconstruction required. The integration is not just a sync. It produces its own evidence of value as it operates, in a format the client's BI tools consume directly.

Problem

Existing clients calling about something important should never wait while you triage cold inbound. But most practices' voicemail surface doesn't know the difference. Every voicemail lands in the same generic inbox, indistinguishable, and sits there unread for hours or days until somebody manually triages. The worst case is the one that compounds: a missed call from someone who's already paying you, calling about something that needs an answer today, rolling into a generic no-context summary the next morning. The relationship erodes. The renewal slips. Sometimes the case goes with it. Customer-facing teams need live visibility into every voicemail AND a way to instantly know which callers are known to the practice versus cold. Originally deployed at an insurance agency on Asterisk PBX, Gmail, and Slack. The pattern applies anywhere a practice has to distinguish 'someone we know' from 'someone we don't' the moment a call lands.

Architectural Solution

A polling pipeline that reaps PBX-generated voicemail emails from Gmail (OAuth-scoped read-only), extracts the caller's phone number, cross-references the book of record to find the matching lead, then queries status to determine priority. Known-client callers trigger live Slack alerts with the actual voicemail audio auto-uploaded as a threaded reply that plays inline in the channel. No inbox-diving, no link-clicking, no app-switching required. Unknown callers are silenced during business hours and rolled into a single morning digest the next day. When a caller leaves multiple voicemails between cycles, the pipeline groups them by normalized phone and posts one consolidated alert with every audio threaded chronologically underneath, rather than N separate alerts the team has to mentally reassemble.

Tangible Result

Thirty-five days of production data: 907 voicemails captured, 97.9% delivered with audio attached as a threaded Slack reply, median 2.7 seconds from PBX-drop to channel-playable (95th percentile under 5). 26.8% received an explicit team reaction inside Slack, a measurable floor on how often inbound got actively triaged. In the old workflow, that visibility was zero and surfacing time was measured in hours. The team now responds to active-client voicemails during the same call window the customer is still expecting an answer, not the next morning. The self-healing backfill pass recovers the 2.1% of upload failures automatically. The v3 rebuild moved the system from a 7,045-line single-file script to roughly 80 files across handler/interpreter/config layers, behind ~360 automated checks, with cutover from old to new completed in roughly five seconds via the one-click installer. Live in production today serving a CS team across multiple shifts. Full instrumented breakdown published in the Field Notes blog post.

Problem

The moment your practice scales past one practitioner, the inbound has to find the right one. Not just anyone, the right one. By specialty. By license. By state. By availability. By whatever constraints actually govern your routing. Without an enforcement layer, it lives in shoulder-taps and tribal knowledge. Some people claim work they aren't actually available for. Others are available but invisible. The rules get applied inconsistently. Stale requests clutter the working channel for weeks after the work has already closed. The team needs real-time visibility into who's free, automatic enforcement of the rules that actually govern routing, and a way to keep the working channel readable as volume scales. Originally deployed inside a customer-service floor at an insurance enrollment center on Slack. The same engine applies to any multi-practitioner practice distributing live inbound: medical groups routing patients to specialists, law firms distributing matters to associates, brokerages routing leads by license and state.

Architectural Solution

A real-time routing engine that runs inside the team's messenger channel. The bot watches for inbound requests, parses the relevant attributes from the message, then routes to a live-tracked pool of available practitioners. It pulls only those whose latest status is Ready, declared via Block Kit availability polls posted directly inside the channel. Rule-aware pool selection applies the firm's routing rule. Fallback to the secondary pool fires automatically when the primary has nobody ready. A nightly cleanup pass removes stale request messages and their entire reply thread, with full audit log, rate-limit-aware retry, and a dry-run mode for safe rollout. The architecture is the first production deployment of the LionsHead Integration Library: Source, Messenger, and Routing Rule are all pluggable via a HandlerFactory. The same engine ports to Teams, Discord, Webex, or any other surface by registering one new Messenger plugin. No rewrite of the routing core.

Tangible Result

Requests route to the first actually-available practitioner in seconds, not minutes-of-shouting. Misrouted requests drop to near-zero, because the system explains in plain English why a given routing isn't allowed. The channel stays clean: stale requests and their bot replies vanish on a daily cadence with a full audit trail. And because the architecture is a library rather than a one-off, the next routing engine inherits all of this for free.

Problem

On a fast floor, the scoreboard is always stale. A deal closes in the CRM at 10:41; the manager learns about it in a spreadsheet after lunch, coaches on it the next morning, and reconciles cost-per-sale at the end of the week. By then the moment — the recognition, the correction, the save — has passed. The friction isn't a missing tool. It's the gap between the tools: the dialer knows the calls, the CRM knows the sales, the finance side knows the lead spend, and no single instrument sees all three at once, in time to act. Worse, the question that actually matters — is this agent underperforming, or did they just draw an expensive lead? — gets answered by feel, because a blunt cost threshold can't tell a slow morning everyone shares from a genuine problem. Originally deployed against a paid-lead insurance sales practice. The same gap opens on any high-velocity floor where lead spend, live conversion, and recognition live in three separate places.

Architectural Solution

A headless, always-on metasystem that reads fact and signal across the systems the practice already runs and turns it into a single live voice the whole floor hears. On a twenty-second poll it recognizes every close the instant it's written and fans three concurrent voices out of one event: a card to the sales channel, a DM to the closer, a DM to the enroller who set it up. Every alert carries agency cost-per-sale live, plus a running High CPA Watch that names the agents running hot and, for each, exactly how many more closes bring them back under target. The instrument that sets Herald apart is a peer-conversion significance test run on each agent: given how many paid leads they worked, is their close count low enough that chance alone is unlikely, measured against how the rest of the floor is converting right now? The benchmark moves with the day, so no one is flagged for a slow morning everyone shares, and it's volume-aware, so one sale on three leads never reads the same as one on forty. It surfaces the agent who genuinely needs a hand — not the one who simply drew an expensive lead. A pace-and-projection line closes each card: today against the same minute yesterday, with a run-rate projection to end-of-day once the signal is strong enough to trust, colored green when they'll beat yesterday and red when they won't, recomputed on every sale so a mid-day slump pulls the number down honestly.

Tangible Result

It hands the week back. The manual round-trip — pulling the report, tallying the day, chasing who's over on cost, reconstructing yesterday to know if today is good — disappears. In its place: a floor that recognizes itself in real time, twenty seconds from close to alert; a cost signal that arrives while it can still change an outcome; and a performance flag precise enough to trust with a person's confidence. Recognition reaches three voices at once — channel, closer, enroller — and one statistical flag replaces gut-feel coaching. Beyond the wins, the full arc of the book arrives as its own threaded, deduplicated alerts: rejected and trashed policies, weekly performance roll-ups, deals waiting to be dropped. The manager stops assembling the picture and starts acting on it.

Problem

The moment your practice scales past you doing every conversation yourself, the question shifts. It's no longer 'am I good enough on this call.' It's 'is everyone in my practice good enough on every call.' That's a different problem. In regulated spaces (medical patient outreach, financial advisory recommendations, legal intake, insurance enrollment) it's the problem that closes your firm if you get it wrong. Every recorded conversation has to demonstrably clear a quality rubric: needs analysis, consent capture, scorecard threshold, disclosure handling. The AI-scoring vendors that produce those scores each expose the data differently. The compliance templates that have to be populated all want the same data shaped slightly differently. Building a one-off integration per vendor-and-template pair is how compliance ops drowns. Worse: when a scoring system updates a call's score days after the call closed, because a reviewer overrode a measure or because the rubric itself changed, there's no clean way to know which historical exports need to be re-issued. Originally deployed against a Medicare Advantage scorecard. The framework applies to any regulated, phone-based context.

Architectural Solution

A four-category handler framework (Source, Destination, Messenger, and a category-specific AIScoringHandler interface) wired together by a YAML config file. One deployment equals one YAML. The Source category abstracts every AI-scoring vendor behind a single fetch_calls(start, end, **filters) interface that yields canonical Call+Score payloads; concrete handlers translate each vendor's wire format. The Destination category abstracts the output template (XLSX agency workbook, BI warehouse, CSV export); concrete handlers preserve template styling, sheet names, and cell formatting per row. A classified transport layer wraps every external call: TransientError, RateLimitError, AuthError, ClientError, ValidationError, each with its own retry policy, Retry-After header honored, exponential backoff with jitter on transient failures. A SQLite-backed state ledger sits at the seam between source and destination. It stores each call's content hash and implements an upsert contract (insert, unchanged, updated) so late-arriving score revisions automatically trigger a re-export. Auth is itself pluggable (API key, basic, OAuth) so the same handler ports across an entire vendor category without an auth rewrite.

Tangible Result

A scoring and compliance pipeline that runs unattended overnight and lands a fully-formatted carrier-template export in the right folder by morning. Late score revisions from the AI vendor flow through the ledger and re-export on the next cycle with zero human intervention. Onboarding a new AI scoring vendor or a new compliance template is one handler module and one config block. Not a rewrite. The framework itself is the deliverable. Every subsequent compliance-automation engagement inherits the transport, the ledger, the auth modules, and the abstract category interfaces for free.