Everything that’s included.

What it is

The canonical sales data model: one row per call that received a post-call form, linked to its booked call. A standardised Call Outcome taxonomy plus derived classifications (isWin, isLive, isKept) drive every dashboard close/show/cash calculation, so the whole team works off one agreed definition of a win.

What you get

• A standardised 10-value Call Outcome taxonomy with documented meanings + counts-as rules
• Objection + diagnostic capture (Top Objections; Discovery Gap) that turns lost calls into coaching data
• Call recording link, notes, closer/setter, call datetime — every call fully described
• Three close-rate definitions surfaced explicitly (Live / Kept / Booked) so numbers are never ambiguous
• On submit the form writes its main objection (and the full list) back into the CRM lead record, so the lead profile, the objection report and the form never disagree
• A 15-minute auto-link reconciler that attaches any post-call row created without its booking link (by a foreign automation, an import or a hand-typed row) to exactly one booking, so every lookup that hangs off the booking resolves and no call is counted as a walk-in that was booked

Runs on

What it is

The enforcement layer around a post-call form: a live queue of calls that have no submitted form, and a reminder loop that chases them down three channels. It exists because the failure mode of every post-call form is not a bad form, it is an empty one. Reps are pinged per call at most once per channel per day, the ping is aimed at the person who ran the call wherever attribution allows, and an unrecoverable backlog is counted but deliberately never chased.

What you get

• A queue page with open / submitted / backlog counters, each from its own query
• Reminder cron with per-call per-channel per-day deduplication
• Rep-targeted direct message, push and in-app bell, with a channel post as the fallback when attribution is missing
• An explicit reminder window, with everything older excluded from chasing by design

Runs on

What it is

A suite of standalone, white-labelled forms in the portal that write to your Airtable base through a secured server route. The post-call form booking dropdown is the live Calendly API (no sync lag), the closer auto-matches from the booking host email, and bookings that already have a post-call record are hidden. Includes Post-Call, Instalment, EOD-Closer and EOD-Setter forms. Every list is drawn in the page rather than handed to the browser, so an option can carry the detail that tells two similar rows apart — a call time, a customer email — and can be typed into and grouped.

What you get

• Four standalone forms (Post-Call, Instalment, EOD-Closer, EOD-Setter) + a settings dashboard
• Live-Calendly booking picker, closer auto-match, already-logged hiding, resilient instalment writes
• URL pre-fill support + an in-page dropdown + inline-validation layer
• A payment-matching panel that reconciles cash collected against the real processor records, with search and an optional AI suggestion
• A fully branded theme (your domain never shows our brand) + role-scoped logins (full vs sales-only)

Runs on

What it is

A portal ingest that picks up a finished sales-call recording (transcript + summary), reads it with an LLM, builds a pre-filled post-call-form link, and pings the closer to review and submit. Recordings arrive by scheduled poll (the primary path, and the one that must work) plus a webhook for latency where the recorder can register one. Nothing is auto-submitted — the closer is always the human in the loop.

What you get

• The versioned ingest route + LLM extraction module + a recording-provider config table + a settings UI
• A scheduled poller as the primary delivery path, with the webhook as an optional latency upgrade — both funnel through one shared, idempotent ingest
• Idempotency via a stamped recording id, plus a separate claim row that makes the NOTIFICATION idempotent too
• Evidence capture: field to verbatim quote, shown beside the value so a rep can sanity-check a figure without opening the recording
• A payload normaliser that accepts several provider webhook shapes rather than pinning one version
• A rep email-mapping setting, because the address someone records under is rarely the address they log in with

Runs on

What it is

Turns iClosed / Calendly bookings into clean CRM records, each linked to the matching event/funnel, and fires instant booked / rescheduled / cancelled / no-show notifications to the right Slack channel with the booker intake answers attached. The sync is idempotent (merge on email + invitee URI) and deliberately omits human-editable fields so re-runs never clobber edits.

What you get

• An idempotent Calendly/iClosed to CRM sync (merge keys, edit-safe)
• An instant booking notifier routed by event type, with intake Q&A inline
• A cancel path that marks the booking/PCF cancelled
• A no-show alert rail on its own subscription, added without disturbing the live one
• iClosed/Calendly events double as the funnel registry for funnel reporting

Runs on

What it is

Changing the rep on an already-booked call is normally impossible: the scheduling tool creates the video meeting under the original host, so transferring the booking moves the record while the meeting stays with the old rep and the prospect is left holding a link nobody can start. This is a manager-facing form that reassigns the call from the video side instead. It adds the new rep as an alternative host on the existing meeting, proves the join link did not move, and relinks the owner in the CRM so attribution follows. The booking itself is never touched, which is exactly why the prospect never notices.

What you get

• A manager-scoped reassignment form with a live picker of upcoming calls
• An allow-list of who may receive a call, checked against the video platform for a paid seat
• A post-write verification that proves the invitee link survived, and aborts the CRM update if it did not
• Plain-English refusals for every case that must not proceed
• CRM owner relink so per-rep reporting stays correct after a swap

Runs on

What it is

Makes "the post-call form is the source of truth for payment data" enforceable instead of aspirational. Every money field on a deal record carries where it came from — a submitted form, a manual override, or pre-existing legacy data — plus who set it and when. A coverage figure shows what share of closed revenue is actually form-backed, and a review queue lists every record whose numbers contradict its form. Existing history is grandfathered at cutover, so switching this on moves the reported revenue by exactly zero.

What you get

• Provenance columns on the deal record, with a constraint limiting them to the agreed vocabulary
• An idempotent cutover backfill that grandfathers existing history without moving a single figure
• Form-owns-the-number write logic, including a retraction rule scoped to the owning form
• Self-stamping manual overrides — open, but never silent
• A classification view and a review page: coverage percentage plus the disagreements, grouped by what needs acting on

Runs on

What it is

Two halves of the same capability. Tracking: a standalone dashboard that measures the gap between when a lead is created in the CRM and when they receive their first outbound text/dial, attributed to the right rep even when dialers share sending numbers. Routing: an automation that, the instant a registration creates a lead, pings the on-shift setter with the name + number and stamps the opt-in time so latency becomes a measured KPI.

What you get

• A speed-to-lead dashboard with per-dialer median, distribution chart and activity panel, plus a methodology section
• Seat-to-dialer mapping that resolves the right rep across shared lines
• An instant lead-routing + setter-notification automation (Slack/Discord/SMS)
• A daily-report line: median speed-to-lead + percent dialled within the target window
• An escalating chase thread per lead: role-wide @-mention on arrival, nudges at two configurable thresholds while untouched, and a closing card carrying the achieved speed plus that rep rolling weekly average
• A start-of-day queue report replacing out-of-hours pings, listing what is waiting and how long each has waited
• A second, independent first-response clock for populations whose deliverable is a logged conversation rather than a dial, kept structurally separate so nothing is counted twice
• A speed-to-lead block inside the sales overview: WhatsApp response time (median, p90, replied share, response rate to first outreach), dial speed from CRM lead creation to first dial, pickup rate, leads reached, and pickup by speed bucket; a channel whose sync cannot supply timestamps renders as a labelled sentence with the last successful sync, never as 0

Runs on

What it is

The integration layer that wraps Sendblue (iMessage/SMS) as the team outbound dial mechanism. Every outbound text to a lead is the canonical dial event that feeds speed-to-lead and the outbound funnel, with pagination, retry/backoff and per-user credential resolution handled for you.

What you get

• A resilient Sendblue wrapper (seats + messages, pagination, retry/backoff)
• Per-user credential fallback
• Seat-to-dialer mapping for attribution

Runs on

What it is

Measures DM setting through the official Meta webhooks rather than a browser script or self-reporting. Because Meta echoes back messages the business sends, it captures replies typed in the Instagram app on a phone — the exact gap that defeats every client-side approach. Produces time-to-first-response, reply coverage, a live unanswered queue, per-setter attribution with its method recorded, and DM-to-booking conversion.

What you get

• Meta app setup, webhook subscription and verification handshake, plus the three separate switches that all have to be on before events flow
• Signature-verified, idempotent n8n ingestion
• Lead identity resolution and deduplication on the stable platform id, with profile caching
• A DM Conversations table modelling the thread lifecycle, and per-message activity rows
• Four attribution options with their exact limits written down, and an attribution-method column on every thread
• Time-to-first-response as median and p90, percentage within SLA, and reply coverage
• Live unanswered queue, ageing digest, and a warning before the 24-hour reply window closes
• Booking-link-sent tracking and full DM to booked to held to closed conversion

Runs on

What it is

Teams that sell in one-to-one chat outgrow the messaging app itself: two setters cannot work one number, nobody can see who already replied, and the lead's history lives somewhere else entirely. This is the operating surface — a web console over the message log where several people work the same inbox, each conversation carries the lead's profile, stage, tags and call history beside it, and the queue tells the truth about what still needs an answer. It is the surface the messaging analytics service reports on, and it is deliberately separate: this is where the work happens, that is where it is counted.

What you get

• Multi-user inbox over the shared message log with per-conversation assignment
• Lead panel beside the thread: profile, stage, tags, call history and notes, width adjustable and collapsible
• Read-without-trace mode with a visible badge and a one-click return of everything to unread
• Growing composer with link preview, emoji, media upload and slash-inserted saved assets
• Tagging with inline creation, plus stage and owner assignment from the thread
• Light and dark themes driven by CSS custom properties in channel notation, so opacity modifiers keep working

Runs on

What it is

Sales teams that work in a one-to-one messaging channel have no analytics at all: the inbox shows conversations, not performance. This is the reporting layer on top of the message log — how many messages went out, how many of the people written to actually answered, how long they took, who on the team gets answered, and which shared links and assets are clicked when they are sent. It lives in the sales workspace rather than inside the messaging tool, so it reads beside the rest of the pipeline reporting.

What you get

• The aggregation function (totals, per-sender split, daily series, per-asset click-through) taking the window as its only input
• The reporting page in the sales workspace with the shared date-range control
• Per-sender table with a minimum base before any rate is printed
• Per-asset table separating click rate from click count
• Conversation counters — first-time inbounds, threads opened, threads active — plus outbound per active thread

Runs on

What it is

A dashboard that captures inbound + outbound sales activity with domestic and international reported separately across every KPI — leads, age buckets, bookings, shows, closes, cash, AOV, show%/close%, per-rep and objections. Dial-level and live opportunity-stage metrics fill in from a dedicated event store that captures every dial, disposition and pipeline move as it happens.

What you get

• Inbound + outbound funnel with the full KPI stack, domestic/international reported separately
• Per-rep view + objections breakdown
• Filters: scope / channel / rep / lead bucket / opportunity stage / date range
• An event store (leads, outbound_events, bookings, rep_lines) for dial-level + stage metrics

Runs on

What it is

An n8n automation that ingests payments from a client processors and writes them into one clean data model. A high-ticket or instalment payment creates a revenue row (and, if it is a 2nd/3rd/4th payment, an instalments row linked to the matching deal by email); a low-ticket/OTO purchase creates an OTO row + revenue row and upserts the buyer as a lead.

What you get

• The n8n ingestion automation across Fanbasis / Whop / Shopify / Stripe
• Revenue, instalments and OTO row creation with deal-matching by email + program
• A live payments panel (net 24h/7d/30d, count, recent payments) — already running for one client
• A ledger mirror table that keeps its own match state, so a re-sync never undoes manual reconciliation work
• One ledger across processors: a processor column plus source api|manual, so processors without an API (bank transfer, manual PayPal) still become rows — entered straight from the post-call form
• On-demand freshness for poll-fed processors: the form payment search re-polls a bounded window before matching, so a payment taken minutes ago is findable without a webhook
• An unmatched-payments queue with one-click assign, unlink and ignore
• Refund awareness: a fully refunded payment is never treated as cash received
• Per-processor failure isolation: one processor being down or its key being revoked never blocks the others or the reconciliation run — each failure is reported per processor instead of aborting the job
• Real-time payment notifications where the processor supports webhooks, posting only rows that are genuinely new, with what the matcher did to each (instalment ticked / person recognised / needs a human)
• Only settled money enters the ledger — unpaid or draft invoices are counted and reported, never mirrored as cash received

Runs on

What it is

A dedicated tracking layer for high-ticket payment plans, and its own collections screen. The post-call form records the plan structure (PIF or 2-5 instalments) and the per-instalment schedule; an Instalments table records what actually came in; a dedicated tab joins the two into one answer - how much cash is still to collect, and the calendar of when it is due. Payments are logged from that tab in one click, so the collected side is a job someone can do rather than a table nobody opens. Rows that are instalment payments are auto-flagged so they boost cash but never get miscounted as new sales.

What you get

• Payment-plan schedule fields (PIF or 2-5 instalments, expected amounts/dates)
• An Instalments table for actual collections, surfaced as expected-vs-collected
• A dedicated collections tab: cash still to collect, overdue, due in the next 30 days, and collected to date
• A month calendar of every due date, click-a-day to filter, and a cash-landing-by-month chart splitting owed from collected
• One-click payment logging with a live payment-method picker, fee-aware net amount, and undo
• An owed-but-unscheduled list - part-paid PIFs and deposits with no plan, money no per-instalment view can show
• A money-owed section on the sales dashboard itself: scheduled instalments and unscheduled balances in one list, soonest due first, so collections live where the reps already are
• Every owed row deep-links the payment form with the deal, the instalment and the amount still outstanding already filled in - a part-paid row offers the remainder, not the original amount
• Each rep defaults to their own collections with a one-click switch to the whole team, because collection is the closer job and commission pays on what they collect
• A write-off action for money that is never arriving (all contact lost), gated to managers - it stops the chase without writing a payment, so cash collected stays honest and the reminder stops too
• Automatic, zero-config flagging that handles British instalment and American installment spellings

Runs on

What it is

An integration + computation layer that pulls memberships and computes normalised MRR/ARR, active subs, at-risk MRR, churn and a plan breakdown, attributing products to the right offer by name. It surfaces on the overview dashboard with a 10-minute cache.

What you get

• An MRR computation route + an overview recurring-revenue section
• Product-to-offer routing by name
• A plan breakdown table

Runs on

What it is

On a refund-form submission or a processor refund webhook, the automation finds the original deal by lead email, stamps it Refunded with the date + reason, removes any marker row, and sets the CRM lead status to Refunded. Net-cash math then subtracts the refunded deal cash, filtered by refund date — leaving the original cash row intact and auditable.

What you get

• The refund automation (Zapier or n8n)
• A refund-registration form with a reason picklist

Runs on

What it is

The payout layer of the portal, shipped as part of the standard portal build. It turns recorded sales into what every party is owed — closer, setter, sales manager and the growth operator pool — and shows the working. Rates are effective-dated and forward-only, so changing one never restates a deal that already closed. Everything is paid on net cash rather than gross, so a processor fee rise cannot quietly overpay. Every payment is one dated row: upfront, deposit, each instalment at its own ordinal, and refunds as negatives. Managers see the whole book; a closer or setter opens the same page and sees their own money and nobody else, computed by narrowing the one shared ledger rather than by a second calculation that could disagree with it.

What you get

• An effective-dated, forward-only rate table with per-role and per-package scopes, editable in the product by the operator only
• A processor-fee registry — the fee on each payment method, set in the product on the payout page and on the operator config surface, both through one editor and one write path
• A per-rate BASIS the engine actually applies — net cash after processor fees as the default for every role, net cash after the period ad spend, or gross — changed forward-only exactly like the percentage
• An honest empty state: when nothing qualifies, the page names why from the counts it was built on, and reports the banked money no form accounts for rather than rendering a blank table
• Per-deal rate overrides that snapshot onto the deal and beat the table
• A payment ledger: one dated row per upfront, deposit, instalment (at its ordinal) and refund, each showing the rate applied and where that rate came from
• Per-closer and per-setter payout tables plus whole-window pots per role, for managers and above
• A self-scoped view for every rep: their payout, their deals, the rates their own seats are paid at, and a ledger of only their own payments
• An unmatched high-ticket report — money banked with no form behind it, named as unpaid rather than dropped
• A distinction between no rate set and a rate of zero, carried all the way to the screen, so nobody is silently paid nothing

Runs on

What it is

Takes any dashboard live Airtable records, buckets a chosen numeric metric over time, and projects it forward N periods under one of three growth models, with a confidence band and a historical-vs-projected chart.

What you get

• Three modes: trailing average (steady), linear growth, compounding growth
• Auto-computed growth rate from recent periods, or a manual override
• Summary cards (historical/projected totals, avg per period, implied growth) + a historical-vs-projected chart

Runs on

What it is

The flagship use of the portal: a sales-performance command center built on your post-call-form data. It surfaces volume, close-rate, show-rate, cash and revenue KPIs, source/funnel breakdowns, program & payment mix, a full call log and per-closer/per-setter leaderboards — all live. For multi-offer clients it runs head-to-head comparisons and rolls both offers into a combined topline.

What you get

• Topline KPIs: cash collected, revenue, AOV, deals closed, pipeline, true cash, close rate, show rate, $/live call, run-rate
• Source & funnel breakdown, programs & payments mix, full call log, dialer funnel
• A calendar of every booked call in two views off one dataset: a month grid for "how full is the period", and a week grid on an hour axis - days across, hours down, each appointment in its own slot, colour-coded by call type - for "what does the day look like". The hour window starts at working hours and grows to cover the earliest and latest real appointment, so nothing is silently outside the axis; overlapping calls sit side by side; a 5-day toggle states in words how many weekend entries it is hiding, and reschedule chains are counted once
• Own entries in the same two grids - a webinar, a launch, a team meeting - with a start AND an end time, so the week grid draws each block at the length it actually runs and overlaps are worked out from real time ranges rather than a fixed guess. They carry their own colour and category and are excluded from every call statistic, because they are not calls
• Repeating entries (daily, weekly, monthly, yearly, every n-th) with an optional series end. A series is ONE stored row expanded when read, never a table of materialised copies, so editing it can never leave two versions of the same calendar behind; each repeat is recomputed from local calendar day plus wall-clock time, so a 19:00 series stays at 19:00 across a daylight-saving change; a monthly series on the 31st skips months without a 31st instead of drifting to the 1st
• Click any own entry to see its detail and edit it - title, type, date, start, end, notes, recurrence - or delete it; drag it to reschedule, in the week grid onto another day and time on a quarter-hour raster with a ghost showing where it will land, in the month grid onto another day. Bookings synced from the scheduler and the CRM are deliberately NOT draggable: they belong to those systems and would silently snap back on the next sync. Changing or dragging one occurrence of a series always asks whether this occurrence or the whole series is meant - one grab must never move forty appointments by accident
• Top closers / top setters leaderboards + per-rep cash/call and cash/live-call
• Variant — scheduled chat leaderboards: the same ranked boards posted into the team chat on a timer, a daily one and a rolling week-to-date one, ranked on cash collected and read from the SAME metric layer the dashboard uses so a board and a dashboard can never disagree. Post it only once the headcount makes a ranking mean something — a leaderboard of one is a vanity tile.
• A scheduled board carries the same three settings a scheduled report does, for the same reason: the clock time, WHOSE clock it is read on (the reader may sit in a different country from the floor), and how many days back the board covers. An evening board covers the day it posts on and a morning board cannot, so moving the hour across the night without moving the period does not give an early board — it gives one that ranks the whole floor at zero, with medals, under real names, and nothing failing anywhere. Move both in one operation and key the once-a-day guard on the period reported rather than the day posted.
• Check what a period shift does to the ROLLING board before shipping it. A week-to-date board posted in the morning on a Monday covers the whole previous week rather than a Monday a few hours old — usually the better board, but a change to what the reader has been trained to expect, so say it rather than let them find it.
• A documented single-definition metric layer so AOV (day-of-close cash) and avg deal value (full contract) never get confused
• Retention and collection metrics: opt-in to booking rate, no-show rebook rate, instalment collection rate (money collected over money that fell due, not-yet-due excluded) and an overdue-instalment total
• Cash per call taken and cash per call kept, kept meaning it stayed on the calendar to its slot - no-shows in, cancels out, a rescheduled call counted once
• A post-call-form coverage tile published beside every outcome-derived rate, so a show rate computed from a handful of written-up calls can never read as though it covered them all
• A PCF-submission-rate strip + missing-PCF chase list to enforce data hygiene
• Combined + per-offer views with a scope toggle, head-to-head comparison and run-rate projection
• A whole-process overview page for a chosen period: leads in by source, calls booked (by booking date) and held (by appointment date), offers, wins, cash by processor, then every rate on its own card stating exactly what it is over - no-show as a floor with a leading >= because attendance is only ever recorded on failure, cancellations as observed facts, setter-to-closer transfer, offer / close / deposit rates - plus top objections from the post-call taxonomy with any legacy free-text field shown beside it and labelled as such
• Honesty rules baked into every tile: a base under the minimum prints the count, never a percentage; a metric that only a form can supply (deposits) treats every call without a submitted form as unresolved and prints a sentence instead of 0 %; stage counts for a period are shown as counts with arrows and never as transitions, because stages in the same window are not the same people
• A calculation line under every tile and rate card stating start, end, numerator, denominator and every exclusion in one sentence, so no number on the page needs a hover or a glossary to be trusted
• An outcome-enforcement panel at the top of the overview: every past sales call without a submitted post-call form, oldest first, with kind, rep, age and a link straight to the form - because a call without a form is neither held nor a no-show and is missing from every rate until it is filed

Runs on

What it is

Per-rep performance reporting across team-comparison and individual-drilldown dashboards, built on a shared roster with role-aware metrics. Compares reps across one or many offers, drills into a single rep, and exposes efficiency ratios (cash/call, cash/live-call) rather than just activity.

What you get

• A team-comparison dashboard (per-rep across offers)
• An individual-performance drilldown (KPI grid, per-base table, efficiency ratios)
• Role-aware metric sets (dialer vs setter vs closer) + cross-offer identity rollups

Runs on

What it is

A structured end-of-day reporting model where every rep files a daily EOD with a different field set per role (dialer / DM setter / closer / manager), captured straight into Airtable. A reconciliation dashboard then puts each closer self-reported EOD next to the source-of-truth PCF, surfacing cash/closes/calls deltas so over- or under-reporting is obvious.

What you get

• Four role-specific EOD field sets (dialer / setter / closer / manager)
• A reconciliation dashboard (per-closer cash/closes/calls deltas) + combined activity rollups
• Historical EOD import flagged so old rows never pollute live math
• Variant — deal mix: new and follow-up deals each counted by PIF / financing / instalments / deposits, with cash collected carried on the same split, so the day total is derived from the parts and cannot disagree with them
• Variant — objections heard vs overcome: the same fixed vocabulary asked twice, so the gap between the two is a coachable number rather than a free-text impression
• Variant — split setter reports: a phone report (dials, pickups, talk time, upsell dials, bookings and rebooks) and a DM report (platform, volume out, replies in, qualified conversations, pitches, calls booked and showed, DM closes), filed separately by anyone who does both
• Variant — chat echo: each filed report posted as a per-team card, routed by report type, edited in place on a correction, with every figure the systems also recorded printed beside the rep claim and agreement printed as a bare number so the comparisons that do appear are worth reading
• Variant — nightly chase: a once-an-evening reminder naming only the reps who still owe a report, linking the form, silent when the day is complete, with its own configurable send hour and timezone
• The chase tags the people it names in the message body itself, so it actually notifies them — a mention rendered inside a card notifies nobody on any major chat platform, and a reminder built that way runs for weeks naming the right people and reaching none of them. Only the reps who owe a report are whitelisted to be tagged, which makes an accidental everyone-ping structurally impossible.
• Variant — diagnostic layer: a fixed free-text block per role that turns a count into a coachable observation, with the hygiene checks asked as explicit yes/no

Runs on

What it is

A Goals tab on each dashboard where the owner sets targets against core sales metrics for a period. Each goal renders as a card with current value, % of target, a progress bar, a trend arrow vs the prior period, and a live countdown — and hitting 100% for the first time fires a one-time celebration.

What you get

• Per-dashboard goals (create/edit/delete), owner-only editing; non-owners see read-only progress
• A global HQ goals page listing every goal across every client
• Supported metrics: calls on calendar, deals closed, close rate, show rate, cash collected

Runs on

What it is

A multi-tenant web portal where each client logs in and sees only their own dashboards. Every dashboard is a hand-built HTML/JS view whose data is fetched server-side from your Airtable base and injected into the page before it reaches the browser, then polls a private API to live-update without a reload. One client can have many dashboards; the portal auto-builds the nav between them, white-labelled to your domain.

What you get

• A per-client login + private dashboard area, white-labelled by host (zero of our branding on your domain)
• Unlimited fully-custom dashboards per client — each its own HTML/JS file, full design freedom, not a locked template grid
• Auto-generated nav between your dashboards + an AI-insight surface
• A batteries-included client runtime (data binding, currency/percent formatting, resilient auto-refresh with backoff + re-auth, grouping/summary helpers)
• Per-viewer layout adaptation (a closer vs the owner can see different things) that survives every refresh

Runs on

What it is

A bar above every page of an operations portal listing the settings a human still has to supply, what breaks while each stays blank, and a link straight to the screen that fixes it. It exists because a missing configuration value is invisible in a way a broken one is not: the arithmetic still runs, the dashboard still renders a number, and nothing anywhere says the number is built on a blank. The owner sees the list every time they open the portal, so the gap closes in days rather than at the next audit.

What you get

• A detector module with one self-contained check per setting, each carrying its own consequence sentence
• A ranked banner component mounted in the portal layout
• Role scoping so only the people who can fix a gap are shown it
• Session-scoped dismissal with no permanent hide

Runs on

What it is

An n8n workflow that posts an end-of-day sales summary to Slack (or Discord) every night. It pulls the day calls, closes and setter activity from Airtable + Close, aggregates per-closer and per-dialer KPIs against targets, and has Claude write a 2-3 paragraph narrative grounded by a canonical context doc fetched at runtime. The AI step degrades gracefully — if Claude fails, the report still posts.

What you get

• The full workflow (schedule, window, fetches, aggregate, AI, format, Slack)
• A per-call log + daily totals + per-closer + per-dialer blocks vs KPI
• A scoped system-context doc attached to the AI step
• An optional speed-to-lead line (median + % within target) in the variant build

Runs on

What it is

Each dashboard owner gets an AI-generated narrative insight: every dashboard live data is compacted into a token-efficient statistical summary and sent to a report service that returns a markdown brief, rendered on an AI-insight page inside the portal and delivered on a daily schedule the client controls. It is the working precursor to ask-your-dashboard.

What you get

• A daily AI brief per client on a chosen send time + timezone
• An in-portal AI-insight page
• On-demand regeneration with a 24h guard
• A compaction layer that fits a whole multi-dashboard business into an LLM context without shipping raw rows

Runs on

What it is

A floating chat widget mounted on the client dashboards. You ask in plain English; Claude answers from the dashboard FULL live data — not a lossy summary. The record sets are far too large to stuff into a prompt (one client alone: ~14k registrants, hundreds of PCFs), so the server holds every row in memory and exposes them to the model as query/aggregate tools: it filters, counts and sums over the actual source data and pulls back only what it needs. Where a structure map exists, the AI also knows which dashboard every metric lives on and emits jump-to-metric buttons that navigate there, scroll to the card and draw a highlight ring on it.

What you get

• The floating chat widget — starter prompts, multi-turn history, full markdown rendering (tables, lists), a new-chat reset, session persistence
• The server Q&A engine (tool-use loop over live records) + the per-dashboard API route with owner-allowlist gating
• A per-client dashboard structure map (metrics, aliases, blurbs per page) driving both the AI answers and the navigation
• The jump-to-metric navigation layer (React locator, or a dashboard own locator on single-page tabbed builds)

Runs on

What it is

An Airtable automation code step that, given a post-call-form call outcome, moves the lead GHL opportunity to the matching pipeline stage — built to cover every pipeline stage against every PCF outcome, so CRM stage reporting stays trustworthy without anyone remembering to drag cards.

What you get

• The outcome-to-stage code step + a documented mapping of every stage against every outcome
• A run-time check that every mapped stage still exists, so a stage retired in the CRM fails loudly instead of silently parking leads

Runs on

What it is

Event call-lists in the CRM that point at the right event without anyone — and without a job — re-dating them. The preferred build has NO moving parts: the view filters the event activity OWN date inside a rolling relative window (start of today to one cadence length ahead), so on a weekly cadence the window contains exactly the next event, the list empties the morning after one runs and refills as the next week registrations land. Where the CRM cannot express a window on an activity own field, a daily job re-dates pinned views instead, changing only the date and preserving every other filter.

What you get

• Rolling-window views that need no job at all
• A daily workflow that re-dates any view the CRM cannot express as a rolling window
• A views list so new views can be added to the rotation
• A post-write verification and alert step

Runs on

What it is

A family of automations that post per-call notifications the instant a call event lands. Call-review requests/dones route to role-specific channels with the lead email; closer post-call alerts post outcome, cash, tier, source, the first lines of notes and a labelled AI synthesis (one strength + one improvement, each anchored to a quote) plus the recording link. It re-fetches the activity after a short wait so fields are populated (fixing the blank-post race).

What you get

• A webhook-driven workflow posting review requests + dones to role-specific channels
• Blank-field protection (wait + re-fetch) + re-send
• A reusable closer post-call alert pattern (verbatim notes + labelled AI synthesis + recording link)

Runs on

What it is

One shared card layout applied to every per-event alert an install fires — booking made, booking cancelled, application received, payment taken, payment failed, dispute opened, no-show, response-time breach, dial outcome. A single helper renders header, meta strip, rule, two-column field grid, rule, verbatim answers, quiet footer and an action button, and enforces the platform block limits centrally so a long answer set is SPLIT across blocks rather than silently truncated or rejected. Alerts carry the complete answer set: every question on the form keyed by its real title from the form definition, not only the handful mapped to CRM fields, and a booking alert pulls the answers the same person gave on their application so the qualifying number is on the card. Abandoned form submissions post a card that says it is partial and then EDIT THEMSELVES into the full submission when the person finishes, instead of posting a contradicting second card. Where a scheduling step sits inside the form, the alert is held until the form actually lands: the records write immediately, and only the notification waits, so a booking made mid-application stops announcing an incompleteness that is an artefact of event ordering rather than a fact about the lead.

What you get

• A single card helper applied across every event workflow, with platform limits enforced centrally
• Complete form-answer capture keyed to real question titles, persisted as well as displayed
• Cross-record enrichment so booking alerts carry application answers and the qualifying band
• Self-updating partial-submission cards (post as partial, edit into the full submission)
• Duplicate-run collapse and a concurrency-safe way to find an existing card
• Alert-held-not-record sequencing for events fired from inside a form, with the wait sized from live data and reported per run
• A de-duplicated, labelled attribution line that fits inside the footer and disappears entirely when nothing is tracked
• A channel author audit that catches a retired platform still posting its own alerts alongside yours
• Outcome-routed channels: one outcome, one channel, no firehose copy, so a high-volume day stays readable
• Deploy-time channel resolution: names resolved to ids and baked in, the bot joined where missing, a missing or archived channel failing the deploy rather than a run
• A rehearsal deploy mode that routes every alert to a test channel, so an end-to-end test never posts into a channel the team reads

Runs on

What it is

An hourly job that watches a family of integrations for delivery rather than for configuration. It probes the shared vendor credential directly, flags any member that is switched off or erroring, and catches the case nothing else catches: a run that reports success while recording API failures inside its own summary. It exists because coverage checks and health dashboards answer a different question — they confirm each source is connected to something, which stays true right through an outage. Silence is the healthy state; it speaks only when something is broken, repeats on a slow cadence while it stays broken, and says so once when it clears.

What you get

• A credential probe against the vendor API, reported as the root cause rather than as one finding among many
• Live discovery of the watched population from the automation platform, with no hard-coded list of jobs
• Silent-failure detection that reads a successful run’s own summary for recorded errors
• An assertion that every watched job has an error handler set
• Keyed de-duplication with a slow repeat cadence and explicit recovery notices
• A local dry-run mode that exercises the real engine against live APIs and sends nothing

Runs on

What it is

An n8n automation that keeps a fulfilment team Notion clients database in sync with newly-closed deals. Every 30 minutes it diffs closed deals against Notion cards by email and creates a card for any close not yet present — each enriched with a real Claude-generated call summary and the client country, pulled from the call transcript. It is idempotent and self-healing.

What you get

• The live 30-min sync replacing the paused zap
• Native Notion API integration + program/field mapping
• AI call-summary enrichment from the transcript
• A historical backfill of missing closes

Runs on

What it is

An end-to-end recruiting OS that runs apply to interview to onboard for a sales team. It captures applications, posts them to Slack for review, routes candidates into role-specific interview bookings, gates onboarding behind seven auto-graded knowledge quizzes, generates a personalised onboarding doc + recordings folder per hire, and provisions all their tool accounts from a single Slack click.

What you get

• A 3-stage Airtable pipeline (applications to onboarding) with Slack notifiers at each stage
• An application form in the client own brand — either base-native or a hosted public page writing the same row
• Per-role CRM-safe interview links + instant booking notifications
• One-click account provisioning (Google Workspace + CRM + roster + welcome email)
• A per-hire onboarding-doc clone + a per-hire recordings folder shared from the client address
• Seven auto-graded onboarding quizzes (62 graded questions) with auto-email + Slack results

Runs on

What it is

A handbook built into the operations portal the reps already log into, where each SOP declares which roles it is written for and the server shows a rep only theirs. A dialer sees the dialing SOPs, a closer sees the closing SOPs, and oversight roles see everything. Owners edit the documents in the browser, so a process change is a two-minute edit rather than a deploy. It exists because the alternative — a document library nobody can find and nobody trusts is current — is the reason a new rep needs a call.

What you get

• A role-filtered SOP section inside the existing portal, with per-document role lists
• Server-side enforcement of both read scoping and owner-only editing, on the pages and the API independently
• In-browser editing and creation for owners — no deploy, no schema change, with a live preview
• A dependency-free Markdown renderer that escapes before formatting and cannot emit a script or a javascript: link
• A starting set of documents written from the live systems: CRM day-to-day per role, the post-call form, and end-of-day reporting per role
• A start-here group every role sees: access and what your role can see, a glossary of every metric the dashboards use, a chat-channel map split into where humans talk and where automation posts, and the offer with its live prices and processor fees
• A commission document stating the live rates, the basis they are paid on, and that changes are forward-only
• Manager documents: adding a team member, issuing and resetting logins, changing access, and the daily and weekly review loop
• An executable access-matrix test covering every role against every document

Runs on

What it is

Everything the business holds about one person, assembled and read for them before they are called. The material is scattered across stores that were never designed to be read together: the tracking base holds the touches and the bookings, the recorder holds what was actually said, the CRM holds the notes, the form tool holds what they typed on the way in, and on many installs the chat notifications hold answers that reached no database at all. This gathers all of it on a timer, has a model read it, and posts a card the closer can absorb in ninety seconds, with the long material in a thread underneath.

What you get

• The gatherer: one lead, every store, individually fault-isolated, with a named gap list
• Transcript joining for both dialler records and recorded meetings, with a confidence marker on fuzzy matches
• Account-wide form search by email, with question titles resolved from the form definition
• Chat-notification mining where an automation posts data that reaches no database
• The read: quotes attributed to source, objections already voiced, what to open with, what could kill the call, and disagreements between sources left visible rather than resolved
• Card plus thread rendering inside platform limits, with a countdown that reads in minutes, hours or days
• Idempotency stamp written only on confirmed delivery, plus an arming timestamp so switch-on cannot dump a backlog

Runs on

What it is

When a dial or triage call ends in the CRM, this pulls the transcript, reads it with Claude, and writes the outcome onto the tracking record automatically. Where the CRM has no transcript — which is the normal case, verified live — it downloads the call recording and transcribes it with speaker separation first. Outbound dials are logged automatically because no money is at stake; anything matching a booked appointment is instead pre-filled for a human to confirm, so AI never decides a fact that commission depends on.

What you get

• The n8n pipeline: webhook, identity resolution, cost gate, transcript ladder, extraction, routing, write-back
• A verification probe set that establishes up front whether the client CRM can actually supply audio — run before anything is built
• Speaker-separated transcript normalisation, so the extractor always sees the same REP/LEAD shape regardless of source
• A forced-tool extraction schema with config-driven option lists and post-call validation of every value
• Dial outcome taxonomy, objection capture, next-step-with-date, qualification signals quoted verbatim, and do-not-contact detection
• Talk-time ratio per call where the CRM provides it free
• Dead-letter queue with per-reason grouping, bounded backoff for transcripts that arrive late, and an hourly reconciler
• A hosted transcription service on the client own infrastructure when the CRM cannot supply text: queue, worker thread, callback, per-job deduplication, and a state column on the call row so a failure is visible instead of looking like work not yet done
• A 20-call review pack for the sales manager to sign off agreement before switch-on

Runs on

What it is

A Slack-native task pipeline: an @-taggable AI bot watches a client-facing request channel (plus a 15-min whole-workspace sweep), reads every request with the FULL business knowledge base and live automation inventories in context, and turns it into a dual-scoped task — client-facing WHAT bullets in their channel, precise step-by-step HOW (exact zap/workflow/node/field) in the internal team channel with the right person tagged. Completions are announced back to the client as early/on-time/late, late tasks get bottleneck classification, and internal completion-rate reports run daily/weekly/monthly. The bot also answers any systems question in seconds and learns via permission-guarded knowledge notes.

What you get

• The Slack app manifest + event pipeline (instant webhook, dedup, thread-aware clarifications)
• The dual-scoping brain with full-KB + live-inventory context and judgement-level assignment rules
• Whole-workspace sweep for tasks mentioned outside the request channel
• Completion notices (early/on-time/late), bottleneck tracking, daily/weekly/monthly internal reports
• Permission-guarded learnable knowledge base (everyone reads/adds, only the owner deletes, suspicious adds flagged)

Runs on

What it is

Operating teams already live in the reporting portal all day; the list of what they owe each other lives somewhere else, which is why it goes stale. This puts both in the portal: a task list with an assignee, a start and end date, a priority and a done state, grouped by when it is due; and, on the main screen, a card board for the larger pieces of work — the things to publish, the formats to test, the processes to improve — each card opening into a detail sheet in the middle of the screen and closing again on a click outside it.

What you get

• Task list page with assignee, date range, optional times, priority, due-state grouping and person / status filters
• Initiative card board with a rolling window switch and a centred detail sheet
• One navigation entry that opens the three planning surfaces as sub-tabs - calendar, initiative board, task list - built with the same expanding sub-navigation the portal already uses for its record sections, so a reader learns the pattern once. Scattering them (a calendar block under the numbers, a task tab inside the CRM) hides two of the three from anyone not already looking for them
• One write route per surface with tenant-from-session and row-level security on both tables
• Reuse of the existing notification fan-out on assignment (bell, push, chat channel)

Runs on

What it is

A branded, structured intake that collects the complete, deduplicated union of everything we need so every dashboard, automation and AI report attributes correctly end-to-end. It exists as a print one-pager and a live interactive web form. The governing principle is that tracking never breaks inside a tool — it breaks at the joins between tools — so the make-or-break deliverable is the per-rep identity matrix, not the API keys.

What you get

• One-click account provisioning with a branded welcome email
• A live interactive intake with a dynamic roster builder, 15 tool categories, and per-tool permission hints
• A live build tracker the client watches phase-by-phase (real state, not a canned timeline), plus a dashboard preview already skinned with their brand
• A first-run tour of their command center the day they go live
• A print one-pager fallback + a full master spec (minimum core + maxed union, breaks-if-missing per field)

Runs on

What it is

A set of idempotent, zero-dependency importers that load historical data into the new system: bookings, old EOD CSVs and historical webinar attendance — each with heavy dedup, per-offer splitting and outcome mapping, so the new system launches with full history rather than a blank slate.

What you get

• Idempotent, DRY-RUN-default importers for bookings, EOD and webinar attendance
• Heavy dedup + per-offer splitting + outcome mapping

Runs on

What it is

The portal identity and access layer. Clients sign in by username + password and authenticate against Supabase Auth, issuing a JWT-backed session validated on every request at the edge. Role flags (admin / HQ) and lifecycle flags (onboarded / released / must-change-password) drive what each user can reach, and dashboard-level checks ensure a client cannot load another client dashboard even by guessing the URL. Access is then administered from the product itself at two levels — the operator layer that spans every tenant, and each tenant own admin screen for its own people — so a password reset, a role change or a revocation never needs an engineer.

What you get

• Username/password login with friendly error mapping
• JWT sessions refreshed per request, carrying role claims
• Role-based access (admin / HQ / client) + a staged onboarding/release gate
• Self-service seat administration: reset any password, change a role, move a seat between tenants, revoke access outright
• A team roster whose every attribute — including multi-role job function — is editable after creation, so nobody has to open the underlying database to fix a person
• Lockout guards: nobody can change their own role or revoke themselves, and the last owner seat can never be demoted or deleted
• Per-host white-label login + a resilient credential layer that self-heals missing secrets (incl. a self-renewing long-lived Meta token)

Runs on

What it is

A staff member looking at a customer in the internal console needs to see what that customer sees in a second, customer-facing app - their entries, their history, their conversations with the product. This is the link that gets them there without a shared password and without copying the data. Pressing the button mints a signed, short-lived, single-customer URL into the other app, which verifies it and renders that customer record read-only. Nothing is duplicated: the customer-facing app stays the only place that data lives, so a record deleted or re-keyed there is unreachable from the console the same second.

What you get

• Access card on the customer record in the staff console: one button, a disabled state with a reason when the customer has no account on the far side, and the last few accesses listed with who and when
• Signed lookup endpoint mapping an address to the far-side identifier, with a single generic failure
• Minting and verification of the link itself - fixed string order, constant-time compare, expiry check
• Read-only customer view in the receiving app: off the navigation, unlinked, with a persistent banner naming whose data is on screen and stating that access is logged
• Two audit tables - issued on the console side, opened on the receiving side - each naming the staff member
• Server-side refusal of every mutation reachable from the read-only view
• A disclosure clause for the customer terms, because the view exposes private records and conversation history to staff

Runs on

What it is

A pattern where a single canonical context doc is fetched at runtime by every AI workflow and injected as the system prompt before any business data is processed. Updating that one doc updates every workflow on its next run. It encodes KPI priority, output-discipline rules (numbers first, quote evidence verbatim, label AI synthesis, cite sources, never fabricate a close), report structures and a Slack formatting guide — and powers a whole suite of AI tasks.

What you get

• The canonical versioned context doc + the runtime-fetch wiring in each workflow
• A reusable task library: weekly sales report, weekly marketing report, daily EOD digest, closer post-call alert, pre-call brief, call review/scoring, anomaly alerts
• An output-discipline ruleset + a Slack formatting guide

Runs on