How Harrington & Cole LLP replaced four disconnected tools with one Airtable workspace, cutting matter-intake time by 68% and automating 1,200+ status touchpoints a month.
Harrington & Cole LLP is a 60-person law firm headquartered in Halifax, Nova Scotia, with three practice groups and a docket of roughly 230 active matters at any given time. By early 2025 the firm was running case intake, conflict checks, scheduling and time capture across four disconnected systems: a legacy practice-management tool, shared Excel files on a network drive, Outlook calendars, and a paper intake form. Status updates lived in attorneys’ heads and email threads.
Over an 11-week engagement we replaced this patchwork with a single Airtable workspace, purpose-built tables, role-specific Interfaces for attorneys and paralegals, and an automation layer that handles the firm’s repetitive coordination work. The implementation was delivered without disruption to billable work and went live with all 60 users on the same day.
Outcomes after 90 days in production
68%: Faster matter intake
1,284: Automated touchpoints / mo.
0: Missed SOL deadlines
$41K: Recovered WIP in Q1
At a glance
Before: 4 systems, ~6 hrs to open a new matter, manual conflict checks, scheduling done by email.
After: 1 Airtable workspace, ~2 hrs to open a matter end-to-end, conflict-check workflow runs in < 60 seconds, hearing prep tasks auto-spawn 14 days out.
Background
The client and the problem
About the firm
Harrington & Cole LLP serves regional commercial clients across Atlantic Canada. Three practice groups (litigation, corporate / transactional, and employment) share a managing partner, a central paralegal pool, and a single billing department. The firm had grown roughly 40% in headcount over five years; its tooling had not kept up.
The pain points that triggered the project
Matter intake took up to six hours. A new lead required duplicate data entry across four systems, with manual conflict checks against an Excel register that one paralegal owned.
Status was invisible. Partners had no reliable view of which matters were stuck in discovery, which were close to trial, or which had open balances over 60 days.
Deadline slips were happening. Two near-misses on statute-of-limitations dates in 2024 prompted the managing partner to require automated alerting as a non-negotiable.
Time capture was lossy. Attorneys logged time at week-end from memory; the firm estimated 6–9% of billable hours were being lost.
Reporting was a fire drill. The monthly management report took the office manager roughly two days to assemble from exports.
Why Airtable
The firm evaluated three traditional practice-management products and Airtable. The decision came down to three factors: (1) the firm wanted a system its own staff could change without a vendor ticket, (2) the data model needed to fit the firm’s terminology rather than force the firm into a vendor’s, and (3) the integration story with Slack, Outlook and DocuSign needed to be straightforward. Airtable’s linked-record model, Interface Designer, and native automation framework made it the right fit.
Approach
How the implementation was run
We delivered the implementation in four phases over eleven weeks. A core working group made up of the managing partner, two senior associates (one per practice area), the office manager, and a paralegal lead met twice a week to validate the data model, review prototypes, and sign off on go-live readiness.
Phase
Weeks
What we did
Output
1. Discovery
1–2
Shadowed intake, conflict-check and billing workflows. Mapped 14 existing data sources. Interviewed 11 attorneys and staff.
Process map, data dictionary, ranked pain-point list.
2. Data model & schema
3–4
Designed 10-table relational schema. Built linked records for Cases ↔ Clients ↔ Hearings ↔ Documents ↔ Tasks ↔ Time entries.
Live Airtable base with sample data; ER diagram.
3. Interfaces & automations
5–8
Built the Attorney Dashboard, the Paralegal Workbench and the Partner Reporting interfaces. Designed and tested 8 automations.
3 production interfaces; automation library.
4. Migration, training, go-live
9–11
Migrated 1,847 historical matters, trained all 60 users in three cohorts, ran a 5-day parallel-run before cutover.
Single-day cutover with zero data loss.
Guiding principles
Match the firm’s vocabulary. Field names mirror how attorneys actually speak (e.g. matter, not project; SOL date, not deadline).
One source of truth. Every piece of data lives in exactly one table; everywhere else uses a linked record, lookup or rollup.
Make the right thing the easy thing. Intake, conflict checks, and time capture were redesigned so the compliant workflow is the fastest workflow.
Internal ownership. The office manager and one senior paralegal were trained as base administrators; they own day-to-day changes.
What Was Built
The Cases table: the heart of the workspace
Every matter the firm works on is a record in the Cases table. From here, attorneys can see the entire docket grouped by practice area, filtered to their own matters, or sliced by stage. The grid below shows the production view used by senior associates each morning to triage their day.
Image: Figure 1: The Cases grid view, grouped by practice area. Coloured stage chips give partners an at-a-glance read on where every matter sits. The footer rolls up open balances and average days-open across the visible records.
Highlights of this view
Grouping by practice area mirrors how the managing partner thinks about workload distribution.
Stage is a single-select with a controlled vocabulary (Intake → Pleadings → Discovery → Negotiation → Trial Prep → Closed). It drives both the kanban view and three automations.
Lead Attorney links to the Staff table, so renaming or reassigning happens in one place.
Open Balance at the bottom is a rollup from the Time entries table, no manual reconciliation needed.
Two more views the firm uses every day
Kanban by stage is how partners review pipeline in their Monday morning meeting. Dragging a card moves the matter through the lifecycle and triggers the corresponding automation chain.
Image: Figure 2: Kanban view of the Cases table, grouped by stage. Card colour and the avatar in the corner make ownership obvious even on a wall display.
The expanded matter record
Clicking any row opens a full-detail view of the matter. This is the single screen attorneys live in when they’re working a case. It consolidates parties, deadlines, team, financials and notes. WIP and Open Balance are rollups from the linked Time entries table; the Statute of Limitations warning is a formula that turns red automatically inside 90 days.
Image: Figure 3: The expanded record view for matter CASE-2024-0142. Rollups, formulas and linked records mean every number on this screen is computed live from the underlying tables: nothing is manually maintained.
The Data Model
Ten tables, one source of truth
The base is built around Cases as the central entity. Everything else (clients, hearings, documents, tasks, time, communications) links to a case. This single design decision is what makes the rollups, formulas and automations possible.
Image: Figure 4: The 10-table schema. Lines indicate linked-record relationships. Cases is the hub; Documents, Tasks, Time entries and Communications all link to a case.
Field-level decisions worth calling out
Stage is a single-select with synced colour. Changes here trigger 3 different automations.
SOL date is paired with a formula days_until_sol; the alert automation reads the formula field, so all date logic lives in one place.
Conflict_clear on Clients is a checkbox controlled by the conflict-check automation, an intake matter is blocked from advancing until this is true.
Time entries rolls up into Cases as WIP and Open Balance, so billing reports build themselves.
Communications is populated by the Gmail and Outlook integrations, every email about a matter is logged automatically.
Interfaces
Three role-based interfaces, one underlying base
Different people in the firm need different things from the same data. We built three Interfaces on top of the base, each tailored to a role. All three read from and write to the same tables. There is no duplication.
The Attorney Dashboard
This is the screen attorneys open when they sit down at their desk. It surfaces the four KPIs that matter to them, the next 30 days of hearings, and their personal task list, all filtered to their own user automatically.
Image: Figure 5: The Attorney Dashboard interface, scoped to the logged-in user. KPI cards on top; upcoming hearings and personal tasks below. Click-through on any matter title opens the full case record in a side panel.
Two other interfaces
Paralegal Workbench: task-centric view. Paralegals can claim open tasks, log time directly against a matter, and upload signed documents which auto-update the matter’s stage.
Partner Reporting: read-only firm-wide view with charts showing matters by stage, WIP trend, top 10 oldest open balances, and attorney utilisation. Replaces what used to be a 2-day monthly reporting exercise.
Automations
Automating the repetitive coordination work
Eight automations remove roughly 1,200 manual touchpoints from the firm’s month. None of them replace an attorney’s judgment: they remove the surrounding paperwork.
Image: Figure 6: The Automations panel. Eight automations, six currently enabled, with run counts visible per automation. The detail pane on the right shows the trigger and three actions of the hearing-reminder workflow.
The automation catalogue
Each automation is owned by a named person on the working group, documented in a Notion runbook, and reviewed quarterly.
#
Automation
Trigger
Actions
Replaces
1
New case → Conflict check workflow
Record created in Cases with stage = Intake
Searches Clients table for matches against parties, opposing counsel and judges. Posts result to Slack and sets conflict_clear if no match.
Manual lookup in Excel register
2
Hearing date approaching (14 d)
days_until formula on Hearings = 14 and status = Scheduled
Slack DM to lead attorney + creates 4 prep tasks (brief, exhibits, witness prep, filings).
Calendar reminders + paralegal phone calls
3
Statute of limitations alert (90/30/7 days)
Cases.days_until_sol formula crosses each threshold
Email to lead attorney; at 30d also CCs managing partner; at 7d escalates to a Slack channel.
Slack DM to managing partner with link to the entry.
End-of-month review (often too late)
6
Client onboarding sequence
Clients.conflict_clear changes to true
Sends client engagement letter via DocuSign, creates Drive folder with templates, books an intake call.
Three separate manual checklists
7
Weekly WIP digest
Schedule: every Monday 7:00 AM
Builds per-attorney summary of WIP, billed and aged AR; emails each lead attorney their digest.
Office manager spending Friday building reports
8
Stale matter (no activity 30 d)
Schedule: nightly scan
Sets a flag field; visible on the Partner Reporting interface for follow-up.
Nothing: these matters used to disappear
Worked example: automation #2 in detail
Trigger: a record in Hearings where the days_until formula evaluates to exactly 14 and status is Scheduled.
Action 1 (Find records): looks up the parent Case via the linked-record field to retrieve the lead attorney and client.
Action 2 (Send Slack): DMs the lead attorney with a deep link back to the case record and a one-line summary of the hearing.
Action 3 (Create tasks): creates four pre-templated prep tasks in the Tasks table, all linked to the same matter, with sensible default due dates working back from the hearing.
Replaced: three different paralegals each maintaining their own version of a hearing-prep checklist, and the senior associate manually pinging attorneys.
Integrations
How the workspace connects to the rest of the stack
Airtable doesn’t replace email, calendars, document storage or e-signature, and shouldn’t. It coordinates them.
System
Direction
What flows
Mechanism
Outlook / Microsoft 365
Two-way
Hearings sync to attorney calendars; calendar invites for new hearings auto-create Hearing records.
Microsoft Graph + Airtable sync
Gmail (firm address)
One-way (in)
Email referencing a matter ID is logged to the Communications table with a link back to the thread.
Native Airtable Gmail integration
DocuSign
Two-way
Engagement letters dispatched from Airtable; signed status triggers automation #4.
Webhooks via Airtable Automations
Slack
One-way (out)
Hearing reminders, SOL alerts, time-entry alerts, weekly WIP digests.
Native Slack action in Airtable Automations
Google Drive
One-way (out)
On client onboarding, a structured matter folder is created with the firm’s standard subfolder template.
Drive API call from Airtable script action
Notion
Reference only
Runbooks for each automation live in Notion; each Automation record has a URL field linking to its runbook.
Manual link
Permissions & data handling
Workspace plan: Airtable Business with SAML SSO via the firm’s identity provider. Two-factor authentication enforced for all 60 users.
Field-level permissions: rate cards, WIP and AR fields are read-only to associates; visible only to partners on the Partner Reporting interface.
Privileged matters: a checkbox on Cases hides a matter from all users not on its team via a row-level filter applied to every view.
Audit: Airtable’s revision history is retained, and a nightly snapshot is exported to the firm’s encrypted backup bucket.
Results
Measurable change after 90 days in production
Metric
Before
After
Change
Matter intake (lead → opened)
≈ 6 hours
≈ 1 hr 55 min
−68%
Conflict check turnaround
Up to 48 hr
< 60 sec (automated)
−99%
Missed SOL deadlines (rolling 12 mo.)
2 near-misses
0
−100%
Monthly management report build time
≈ 14 hours
≈ 25 min (live dashboard)
−97%
Time-entry capture latency
Avg. 4.2 days
Avg. 0.6 days
−86%
WIP recovered Q1 (vs. prior quarter)
n/a
$41,200
+ revenue
Automated touchpoints / month
0
1,284 (across 6 active flows)
n/a
Active users (firm-wide)
n/a
60 / 60
100% adoption
In the words of the firm
The thing that surprised me wasn’t the dashboards: it was the fact that we don’t talk about case status in hallways anymore. Everyone is looking at the same picture, and the system tells us when something needs attention before it becomes a fire. We have not had a near-miss on a deadline since the day we went live.
What we’d do again, and what we’d change
Worked well: embedding the working group from week one. Every design decision had a real attorney’s name attached to it, which made go-live painless.
Worked well: shipping the Attorney Dashboard before the Partner Reporting interface. Adoption is driven by the people doing the work, not the people watching the work.
Would change: we waited until phase 3 to wire up the Outlook two-way sync. In hindsight, that should have been in phase 2, calendars are how attorneys actually work.
Would change: add a fifth interface for the firm’s receptionist. Inbound caller intake is still slightly clunky.
How Loomstack Inc. consolidated its customer-success stack into a single Airtable workspace, surfacing at-risk accounts 47 days earlier and lifting net revenue retention from 102% to 114%.
Loomstack Inc. is a Series B B2B SaaS company providing workflow automation tooling to mid-market and enterprise customers, with roughly $24M ARR across 280 paying accounts. By Q4 2025 the customer success team was operating across five disconnected tools: HubSpot for CRM data, Zendesk for support tickets, Stripe for subscriptions, a homegrown product-usage dashboard, and a sprawl of Google Sheets for everything that didn’t fit elsewhere. Health scoring was a quarterly spreadsheet exercise, and renewal forecasts were assembled by hand the week before each board meeting.
Over a 9-week engagement we replaced this stack’s coordination layer with a single Airtable workspace, a unified accounts table, computed health scores updated nightly, role-specific Interfaces for CSMs and the VP, and an automation suite that triggers playbooks before churn risk turns into a churn ticket. HubSpot, Zendesk and Stripe still own their primary data; Airtable is the operating surface on top.
Outcomes after 90 days in production
114%: Net revenue retention
47 d: Earlier risk detection
3,742: Automated runs / mo.
$1.2M: Saved ARR (Q1)
At a glance
Before: 5 disconnected tools, quarterly health scoring done in a spreadsheet, renewal forecast assembled by hand, average risk detection lag of 51 days.
After: 1 Airtable workspace as the CS operating layer, health scores recomputed nightly, live forecast on the VP dashboard, average risk detection lag of 4 days.
Background
The client and the problem
About Loomstack
Loomstack sells a workflow automation platform to mid-market and enterprise operations teams across North America and EMEA. Headcount is 180; the customer-facing org is split into 14 CSMs (segmented by Enterprise / Mid-Market), 6 support engineers, and 4 account executives covering expansion. The CS leadership reports to a VP of Customer Success who in turn reports to the COO.
The pain points that triggered the project
Churn was being detected too late. The first signal an account was in trouble was usually a renewal coming up in 30 days and a CSM scrambling. Two enterprise logos worth $640K combined churned in Q3 2025 with effectively no warning.
Health scoring was theatre. A quarterly spreadsheet exercise produced colour-coded statuses that nobody trusted, by the time it shipped, the underlying data was already 4–6 weeks stale.
CSMs lived in eight tabs. A typical customer review meant opening HubSpot, Zendesk, Stripe, Mixpanel, the usage dashboard, the renewal sheet, the QBR notes doc, and the Slack channel, for every account.
Forecasts were unreliable. The VP’s renewal forecast was built in a spreadsheet from CSM-submitted estimates; variance against actuals was running ±22% per quarter.
Playbooks didn’t run. The CS playbook library lived in Notion but was almost never triggered, because nothing automatically noticed when a playbook should fire.
Why Airtable
Loomstack evaluated three category-leading customer success platforms and Airtable. The decision came down to four factors: (1) Loomstack already had clean data sitting in HubSpot, Zendesk and Stripe, what they needed wasn’t another database, but a coordination layer on top, (2) the CS ops team wanted to own the system and iterate on it weekly without a vendor implementation queue, (3) the health-score formula needed to be theirs, not a vendor’s black box, and (4) integration with Slack was non-negotiable. Airtable’s linked-record model, sync sources, and native Slack actions made it the right fit.
Approach
How the implementation was run
We delivered the implementation in four phases over nine weeks. A core working group made up of the VP of Customer Success, two senior CSMs (one per segment), the head of CS Ops, and a RevOps analyst met twice a week to validate the data model, review prototypes, and approve each automation before it went live.
Phase
Weeks
What we did
Output
1. Discovery
1–2
Shadowed CSMs through 5 customer reviews. Audited HubSpot, Zendesk, Stripe and the usage dashboard. Workshopped the health-score formula with leadership.
Process map, data dictionary, agreed health-score definition.
2. Data model & sync
3–4
Designed 11-table relational schema. Configured one-way syncs from HubSpot (accounts/contacts), Stripe (subscriptions) and Zendesk (tickets).
Live Airtable base with synced data; ER diagram.
3. Interfaces & automations
5–7
Built the CSM Command Center, the Account Detail Workspace and the VP Forecast Room. Designed and tested 9 automations.
3 production interfaces; automation library.
4. Pilot, training, go-live
8–9
Piloted with 4 CSMs for one week, trained all 14 CSMs and the VP team, ran a 3-day shadow-mode period before full cutover.
Single-day cutover; 14 / 14 CSMs active on day 1.
Guiding principles
Don’t replace systems of record. HubSpot, Zendesk and Stripe stay as systems of record. Airtable is the system of action on top: pulling from each, surfacing what matters, and writing back where appropriate.
One health score, one definition. Health is a single formula owned by CS leadership, not three competing scores. Every place it appears in the workspace is the same calculation.
Surface signals, don’t bury them. An at-risk account should be impossible to miss. Risk surfaces on the CSM dashboard, the VP forecast, and as a Slack alert, within 24 hours of the signal.
CS Ops owns the base. The head of CS Ops and a RevOps analyst were trained as base administrators and now ship changes weekly without engineering or vendor involvement.
What Was Built
The Accounts table: the heart of the workspace
Every paying customer is a record in the Accounts table. From here, CSMs can see their book of business at a glance, sliced by segment, plan, health band, or renewal window. The grid below shows the production view used by the VP each Monday to triage the team’s at-risk accounts.
Image: Figure 1: The Accounts grid view, grouped by segment and coloured by health band. The footer rolls up total ARR and counts at-risk / critical accounts across the visible records.
Highlights of this view
Health is a coloured chip driven by a formula on the record. It’s the same calculation everywhere it’s shown.
ARR is a rollup from the linked Subscriptions table, which is one-way synced from Stripe, no double-entry, no drift.
CSM is a linked record to the Staff table, so rebalancing books happens in one place and propagates everywhere.
NPS (last) is a lookup from the most recent record in the NPS Responses table, refreshed automatically.
Two more views the team uses every day
Kanban by health band is the view the VP uses on Monday morning. Cards are stack-ordered by ARR, so the largest at-risk accounts always sit at the top. The colour bar on the left of each card encodes the band; the avatar in the corner is the CSM.
Image: Figure 2: Kanban view of the Accounts table, grouped by health band. Healthy / At risk / Critical / Onboarding / Churned columns make book composition obvious in one glance.
The expanded account record
Clicking any row opens the full account detail. This is the screen a CSM lives in during a customer review, every field a CSM might want is on one page, computed live from the underlying tables. The Health Score, Usage Trend, Open Tickets and Days to Renewal all turn red automatically when they cross their respective thresholds.
Image: Figure 3: The expanded record view for ENT-00142 (Halcyon Robotics). Notice that the timeline at the bottom shows the champion-change event detected on Apr 18 that automatically triggered a save playbook.
The Data Model
Eleven tables, one source of truth
The base is built around Accounts as the central entity. Everything else (contacts, subscriptions, tickets, health scores, renewals, playbooks, NPS responses) links back to an account. This single design decision is what makes the rollups, formulas and automations possible.
Image: Figure 4: The 11-table schema. Accounts is the hub; Subscriptions and Tickets are synced from Stripe and Zendesk respectively; the rest is native to Airtable.
Field-level decisions worth calling out
health_score is a single formula combining four sub-scores: usage (40%), support (25%), NPS (20%), commercial signals (15%). Weights live in a Settings table so leadership can tune them without code changes.
health_band is a derived formula (Healthy / At risk / Critical) with bands at 80 and 60, the only place the thresholds are defined in the entire workspace.
days_to_renewal is a formula reading from renewal_date; the renewal automations all read this field, so date arithmetic lives in one place.
Subscriptions is one-way synced from Stripe: Airtable doesn’t write back. ARR is rolled up from synced rows.
Tickets is one-way synced from Zendesk every 15 minutes, open_tickets on the Account is a count rollup.
Interfaces
Three role-based interfaces, one underlying base
Different people on the CS org need different things from the same data. We built three Interfaces on top of the base, each tailored to a role. All three read from and write to the same tables. There is no duplication.
The CSM Command Center
This is the screen a CSM opens when they sit down at their desk. It surfaces the four KPIs that matter to them, the live health distribution of their book, a renewal forecast for the next six months, and a prioritised list of accounts that need attention today, all filtered to their book automatically.
Image: Figure 5: The CSM Command Center, scoped to the logged-in CSM. KPI cards on top; health distribution and renewal forecast charts below; on the right, the accounts that need attention today, sorted by ARR × risk.
Two other interfaces
Account Detail Workspace: the single screen a CSM uses during a customer review. Live health timeline, ticket history, usage chart, contacts directory, active playbooks, and a notes stream, all on one scrollable page.
VP Forecast Room: read-only org-wide view for CS leadership. Net revenue retention trend, weighted renewal forecast by quarter, churn-risk dollar amount, and CSM utilisation. Replaces what used to be a manual Friday afternoon spreadsheet exercise.
Automations
Automating the work that catches churn early
Nine automations remove roughly 3,700 manual touchpoints from the team’s month, but more importantly, they catch churn signals while there’s still time to act. None of them replace a CSM’s judgment; they make sure no signal slips through.
Image: Figure 6: The Automations panel. Nine automations, eight currently enabled, with run counts visible per automation. The detail pane on the right shows the trigger and three actions of the renewal-playbook workflow.
The automation catalogue
Each automation is owned by a named person on the CS Ops team, documented in a Notion runbook, and reviewed monthly.
#
Automation
Trigger
Actions
Replaces
1
Health score recompute (nightly)
Schedule: 2:00 AM, every night
Runs the health-score formula across all accounts; writes a row into Health Scores; updates health_band.
Quarterly spreadsheet exercise
2
Score drop > 15 pts → Alert CSM
Health Scores.delta_30d < −15
Slack DM to CSM + tags account as ‘momentum loss’; logs into the activity timeline.
Nothing: drops were missed
3
Renewal in 90/60/30 days → Playbook
Accounts.days_to_renewal IN (90, 60, 30)
Branches on plan + health to pick playbook (e.g. Enterprise + <80 → exec save). Spawns 5 linked tasks.
Manual playbook lookup in Notion
4
Trial ending in 7 days → Sales handoff
Subscriptions.status = trial AND term_end in 7 days
Creates handoff record; assigns AE; Slack DM to AE with usage summary; books a calendar slot.
CSM-to-AE handoff via email
5
New ticket P1 → Slack war room
Tickets.priority = P1 (synced from Zendesk)
Posts to #cs-warroom; tags CSM, AE, support engineer; creates a Linear issue if flagged.
Manual Slack post by support
6
NPS detractor → Recovery sequence
NPS Responses.score ≤ 6
Sets account flag; emails CSM with NPS comment; creates a follow-up task due in 48 hours.
NPS responses going unread
7
Usage anomaly → Tag account
Usage signal: WAU drop > 25% w/w
Sets a ‘usage_drop’ tag; surfaces it on CSM dashboard ‘Needs attention’ panel.
Caught (sometimes) at quarter-end
8
Onboarding day 14/30/60 check-ins
Schedule: nightly scan of accounts in Onboarding
Spawns the right check-in task at each milestone; emails customer with the day-30 product-tour link.
Three different CSM templates
9
Champion change detected → Playbook
Contacts.is_primary changes OR HubSpot role-change signal
Creates ‘Champion change’ playbook record; spawns a 5-step exec-meeting save plan.
Nothing: usually noticed too late
Worked example: automation #3 in detail
Trigger: nightly check on every Account where days_to_renewal equals exactly 90, 60, or 30 and status = Active.
Action 1 (Conditional branch): evaluates plan + health. Enterprise + health < 80 routes to Playbook A: Executive Save; everything else routes to Playbook B: Standard Renewal.
Action 2 (Create Playbook + tasks): writes a row in the Playbooks table linked to the account, then spawns 5 tasks with due dates working back from the renewal date.
Action 3 (Notify): Slack DM to the CSM with a deep link to the account; appends the record to the VP’s weekly forecast view.
Replaced: CSMs manually checking renewal calendars and looking up playbooks in Notion (frequently the wrong playbook, frequently too late).
Integrations
How the workspace connects to the SaaS stack
Airtable doesn’t replace HubSpot, Zendesk, Stripe, or the product analytics warehouse. It coordinates them.
System
Direction
What flows
Mechanism
HubSpot
One-way (in)
Accounts and Contacts sync nightly. Field-level mapping for industry, employee count, lifecycle stage and owner.
Airtable HubSpot sync source
Stripe
One-way (in)
Subscription rows sync every 4 hours. ARR rolls up from subscription records to the account.
Stripe → Airtable via Zapier
Zendesk
One-way (in)
Tickets sync every 15 minutes. Priority, status, assignee, and time-open are all rollup-able.
Native Zendesk sync
Slack
One-way (out)
Health drops, P1 tickets, renewal-playbook triggers, NPS detractor alerts.
Native Slack action in Automations
Mixpanel / Snowflake
One-way (in)
Daily WAU and feature-adoption metrics per account, used as inputs to the health score.
Snowflake → Airtable via reverse-ETL
Linear
One-way (out)
P1 tickets that need engineering escalation create a Linear issue with customer context attached.
Linear API call from script action
Gmail / Outlook
One-way (out)
Customer-facing emails (NPS follow-ups, day-30 onboarding tour) sent from automation actions.
Native email actions
Permissions & data handling
Workspace plan: Airtable Business with SAML SSO via the company’s identity provider. Two-factor authentication enforced for all users.
Field-level permissions: ARR and renewal amounts are read-only for CSMs and hidden from support engineers; visible to AEs and the VP.
Book-level filtering: CSMs see only their own accounts by default on every interface; the VP sees the full org. No CSM can edit another CSM’s accounts.
Audit: Airtable’s revision history is retained, and a nightly backup is exported to the company’s S3 bucket via the Airtable API.
Results
Measurable change after 90 days in production
Metric
Before
After
Change
Net revenue retention (NRR)
102%
114%
+12 pts
Average risk-detection lag
51 days
4 days
−92%
Renewal forecast variance
± 22%
± 6%
−73%
At-risk ARR identified earlier
n/a
$1.2M (Q1)
+ saved revenue
CSM time spent on reporting
≈ 6 hr / week
≈ 45 min / week
−87%
Playbook trigger rate
≈ 14% of cases
100% of cases
+ coverage
Automated touchpoints / month
0
3,742 across 8 active flows
n/a
CSM adoption (firm-wide)
n/a
14 / 14 active on day 1
100%
In the words of the team
The thing that changed isn’t really the dashboard: it’s that the team has time. My CSMs aren’t building reports any more, they’re actually talking to customers. And when an account starts going sideways, we know about it the next morning, not three weeks later when the renewal blows up. We saved $1.2M of ARR last quarter that would otherwise have walked out the door.
What we’d do again, and what we’d change
Worked well: co-designing the health-score formula with leadership in week 1. Because they owned it from day one, nobody argued with the scores once they started shipping.
Worked well: shipping the CSM Command Center first and the VP Forecast Room last. Adoption follows the front line.
Would change: we underestimated the data-cleanup burden in HubSpot during phase 2. About 11% of accounts had missing or stale ownership; cleaning that up consumed three days we hadn’t planned for.
Would change: add an in-product feedback widget that writes directly to the NPS Responses table. The current Typeform-based flow has a higher drop-off than we’d like.