Problem

The firm's CRM-integrated dialer had no native voicemail surface. Voicemails dropped into a generic Asterisk PBX inbox as email attachments, where they sat unread for hours — sometimes days. Worst case: a missed call from an active policy holder calling about coverage rolling into a no-policy day-old summary, costing the firm a renewal and a relationship. The customer service floor needed live-time visibility into every voicemail AND a way to instantly know which callers were existing clients vs. cold leads.

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 CRM to find the matching lead, then queries policy state to determine priority. Active-policy callers trigger live Slack alerts with the actual voicemail audio auto-uploaded as a threaded reply — the recording plays inline in the channel, no inbox-diving, no link-clicking, no app-switching required. No-policy callers are silenced during business hours and rolled into a single morning digest the next day; long-form messages in the digest still surface their audio as standalone posts so meaningful voicemails aren't lost, while hang-ups under 10 seconds (duration parsed directly from RIFF/WAVE headers, including PCM, μ-law, and A-law encodings) are auto-suppressed. A self-healing auto-backfill pass runs at the end of every cycle: it scans recent channel history, identifies any alert thread missing its audio attachment, and re-uploads the recording from Gmail — so a transient Slack upload failure never costs the team a voicemail. A separate CLI flag (`--backfill --backfill-days N`) lets ops manually catch up larger windows after extended outages. Two delivery modes selectable by config: webhook-only for simpler text-only deployments, or bot-token mode for full audio attachment + threaded replies. Every external system is wrapped in retry logic with exponential backoff, and the three cycle subsystems (live alerts, morning summary, auto-backfill) run in independent try blocks so one failing doesn't take down the others.

Tangible Result

Customer service team gets actionable voicemail visibility in near-real-time. Priority callers' audio recordings play directly inside Slack — agents listen to the voicemail in the same window where they're already working, then call back the same hour rather than the next morning. The morning digest replaces what used to be a manual inbox-triage ritual: one Slack thread, sorted, deduped, hang-ups silently suppressed, long-form messages surfaced individually with their audio. The self-healing pass means alert threads end up with their recording attached even when an upstream service hiccups, and the manual backfill mode lets ops recover from any extended outage in a single command. The CRM didn't gain a voicemail feature — but operationally, it's like it did.

Problem

The customer service floor's "who can take this transfer?" workflow lived in shoulder taps and Slack DMs. Some agents claimed requests they weren't actually available for; others were available but invisible. Routing rules — HEAP carriers go to one writing group, partner carriers go to another, fall back to the other group when the primary pool is empty — lived in tribal knowledge and got applied inconsistently. Stale request messages cluttered the channel for weeks after the deal had already closed. The team needed real-time visibility into who was free, automatic enforcement of the routing rules, and a way to keep the channel readable as volume scaled.

Architectural Solution

A real-time agent routing engine that runs inside the team's Slack channel. The bot watches for inbound enrollment requests, parses carrier and state from the message, then routes to a live-tracked pool of available agents — pulling only those whose latest status is Ready, declared via Block Kit availability polls posted directly inside the channel. Carrier-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, with concrete implementations selected by YAML config. The same engine that runs on Slack today ports to Teams, Discord, Webex, or any messenger by registering one new Messenger plugin — no rewrite of the routing core.

Tangible Result

Transfers route to the first actually-available agent in seconds, not minutes-of-shouting. Misrouted requests — where an agent grabs a deal that should have gone to a different writing group — 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 LionsHead builds (Teams, Discord, internal IVR, whichever messenger comes next) inherits all of this for free.

Problem

Regulated call centers — Medicare Advantage agencies, mortgage origination, financial advisory — are required to demonstrate that every recorded sales conversation cleared a compliance rubric: Power of Attorney handling, needs analysis, consent-to-enroll capture, scorecard threshold. The AI-scoring vendors that produce these scores (Balto, CallMiner, Observe.AI, Cresta, ASAPP, NICE Engage) each expose the data on a different API surface, in a different shape, with different auth schemes. The carrier templates that have to be populated from those scores (CMS-format scorecards, agency QA workbooks, training-and-coaching exports) all want the same columns shaped slightly differently. Building a one-off integration per vendor-and-template pair is how compliance ops drowns. Worse: when an AI scoring system updates a call's score days after the call closed — because a reviewer overrode a measure, or because the scorecard rubric itself changed — there's no clean way to know which historical exports need to be re-issued.

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 = 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 on a per-row basis. 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 without manual reconciliation. 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 + 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 LionsHead takes on inherits the transport, the ledger, the auth modules, and the abstract category interfaces for free.

Problem

Sales were closing in the CRM but the floor was learning about them in stand-ups the next morning. Recognition and competitive momentum lag — the cultural cost of latency. The team needed every closed sale to land in the right Slack channel within seconds, with full context, without flooding on backfill.

Architectural Solution

A CRM-egress polling loop with a deduplicated event store. The first run bootstraps — marks the day's existing sales as seen so the channel doesn't get hit with backfill — then each subsequent cycle diffs against a self-pruning seen-set on disk. New policies are formatted as Slack Block Kit payloads (agent / fronter / carrier / commission / vendor / running daily count) and posted in chronological order. The seen-set rotates against today's visible window, so the file never grows unbounded.

Tangible Result

The sales floor sees closes as they happen. Daily totals are visible in the same channel that announces individual sales — recognition and momentum compound in real time. Zero duplicates across restarts, zero backfill floods.

Problem

Pay statements arrived biweekly, but verifying them against the firm's book of record was a manual reconciliation nightmare. Three different identity surfaces had to be reconciled — enrollment IDs, member-ID + effective-date pairs, and agent-NPN + submit-date pairs — and no single one of them was reliably present on every row. Worse, status changes mid-cycle meant a policy paid as Active on the Advance statement could come back Trashed on the Recon, triggering an unexpected clawback the firm couldn't anticipate or audit cleanly.

Architectural Solution

A three-layer identity-matching engine that cascades through the available join keys in confidence order: enrollment ID first (deterministic when present), then member-ID + effective-date (probabilistic but high-confidence), then NPN + submit-date (last-resort, audit-flagged for review). Matched policies accumulate in a per-effective-date ledger via idempotent upsert so multiple statements per cycle merge cleanly without re-scanning history. A status-based rate matrix predicts Recon outcomes by category — Active full payment, Active remainder, Trashed flat-fee, Clawback, Zero — turning what was a reactive cleanup into a forward-looking projection. Audit metrics layered on top flag every datapoint that doesn't reconcile: Possible Audit, No Carrier Match, CRM Date Mismatch. The output is a "System Rigor Replay" report showing match-layer breakdown alongside projected-vs-realized payment.

Tangible Result

Pay-statement reconciliation moved from days of manual cross-referencing to minutes of automated review. Recon predictions land inside a single-digit-percent error band on closed periods. Audit-flagged policies surface BEFORE the statement closes, giving leadership the window to correct or contest. The clawback surprise that defined the old workflow is now a predicted line item, not an event.