📊 Leadership Dashboard

The Leadership Dashboard is a client-side HTML/JavaScript application. It runs entirely in the browser, connecting directly to Airtable via its REST API and to Gmail via a deployed Google Apps Script web app. There is no back-end server.

On load, the dashboard fetches 9 Airtable tables in parallel: Accounts, Fixed Costs, Tenancies, Transactions, Rental Units, Tenants, Categories, Sub-Categories, and Businesses. It also fires non-blocking fetches for invoices, Gmail sync, and Fintable status.

Those nine are not the whole list. The same load also reads Strategic Projects (tblHrpTMd5LNYn8v1, js/dashboard.js:185), Tasks and Prospects for the KPI compute (:487, :458), Team Members and AI Agents for the agent cards, and AI Recon Audit for the accuracy score. Opening the page also writes to Airtable, in two places: the Strategic KPI automation below, and the recon audit log in section 6.

Some Strategic Projects carry their own KPI compute code. It is written by hand and stored in the KPI Compute Code field on the project record in Airtable. Opening the dashboard runs that code in your browser and saves the answer back to Airtable. The page is not read-only.

1. loadDashboard() calls loadStrategicKpis() as its first action (js/dashboard.js:929), which reads the Strategic Projects table (:110, :185).
2. Every open project that has compute code goes to runAutomatedKpis() (:514). Projects with a close date are skipped, so a closed quarter cannot drift away from its snapshot (:519).
3. The code runs in the browser through new Function() (:429). A safety check blocks obvious dangerous wording first (:410), and the note beside it in the code is honest that this is a speed bump rather than a wall. Only put compute code in that field if you wrote it yourself.
4. The answer is saved straight back onto the project record (:611-617): KPI Current, KPI Last Updated, KPI Last Updated By, and a KPI Detail JSON blob holding the workings, capped at about 95KB.

1. Open app.operationsdirector.co.uk in any browser.
2. On first load, the login screen appears requesting your Airtable Personal Access Token (PAT).
3. Enter your PAT and press Enter or click Connect. The dashboard loads all data from Airtable.
4. Your PAT is saved to localStorage (key _dlr_pat) and persists across browser sessions until you log out or clear storage.

The dashboard uses a stale-while-revalidate caching strategy to provide instant page loads. On every successful data load, the full dataset is saved to localStorage under the key _dlr_dashcache_v1.

The Operations Hub uses a fixed left sidebar for navigation. Each page also has a standalone URL for deep-linking and sharing.

The financial overview section shows five KPI cards. All figures are calculated from live Airtable data.

Above the financial KPI cards, the reconBar section displays two cards side by side:

1. Unreconciled Transactions — expandable card showing the count and list of all transactions where txReconciled is false and txAccountAlias matches one of the monitored accounts (Santander or TNT Mgt Zempler). Each row shows date, label, and amount.
2. Run Reconciliation button — inside the expanded card, a blue Run Reconciliation button calls triggerReconciliation(this), which runs the AI matching engine from js/reconciliation.js. A status span (id="reconStatus") shows progress.
3. AI Reconciliation Accuracy — shown as a separate KPI card (only rendered if the accuracy log has at least one entry). Displays the percentage of reconciliation matches confirmed as accurate, colour-coded: ≥90% green, 75–89% amber, <75% red.

After the tenancy cards, the dashboard checks for potential CFVs not yet flagged in Airtable. The logic:

1. For each tenancy with tenPayStatus = “In Payment” and active tenant status and rent > 0:
2. Calculate daysOver = days since the current month’s due day (0 if not yet due).
3. If daysOver ≥ CFV_TOLERANCE_DAYS (= 2 days) AND tenPaidThisMonth is falsy AND no cfv_dismissed_[tenancyId] key in localStorage…
4. …the tenancy counts as a potential CFV.

If any potential CFVs are detected, an amber banner is inserted below the tenancy cards: “N potential CFVs detected — click to review”. Clicking the banner calls switchTab('cfv') to navigate directly to the CFV tab.

This section compares actual spending over the last 31 days against monthly budget targets. Transactions are filtered to the 31-day window using txDate and matched to sub-categories by sub-category record IDs in the REC constants.

Built by buildCashFlow() in js/cashflow.js. Projects daily inflows and outflows for 31 days from today’s opening balance.

The table has seven columns. There is no Net column (js/cashflow.js:719-726).

All the money columns are read from the same worked-through series (waProjected, js/cashflow.js:712-714), not from the raw Airtable rows, so each row reconciles exactly: Opening + In − Out − Withdraw = Closing. The table prints that same line under its totals row (:770).

The forecast is not a plain projection of Airtable data. Two things are applied on top of it before the table is drawn.

1. Weekly commitments. Wages of £330 and a Top-up of £140 are added to the Out column every Friday by default (js/cashflow.js:459-465, applied at :491). That is £470 a week, roughly £2,000 a month, and it is not held in Airtable. It lives in this browser only, under the localStorage key _wa_settings (:1192). Edit the amounts and days in the controls above the table. A different browser, or a cleared cache, falls back to those defaults.
2. Recommended withdrawals. The advisor walks the 31 days and, at least three days apart, marks an amount that is safe to take out, in £50 steps (:517-552). It only takes what still leaves the safety floor intact on that day and on every day after it. Once marked, the withdrawal is subtracted from every later Opening and Closing (:546-549), so the Closing balance you are reading already assumes you took that cash. The green Safe to withdraw (31-day cycle) figure above the table is the total of them (:629).

Where the safety floor comes from: the largest single expected payment in, times 30%, scaled by how late payments have actually been running (analysePaymentLag(), :502-508), rounded up to the nearest £50 and never below £500. You can type over it in the floor box, which is also stored in _wa_settings.

The AI commentary section (id="aiCommentary") is generated in renderDashboard() using live KPI data. It covers six titled sections:

• Financial Health: Confirmed monthly income (In Payment), best-case total (+ CFV Actioned), fixed costs, gross margin range, and whether the upper range is healthy (≥40%).
• Profit Targets: Current best-case gross profit vs the £14,000 required target. If on track, shows surplus; if off track, shows shortfall and % achieved.
• Operational Performance (31-Day): Actual rental income, maintenance status (vs £1,000 budget), wages status (vs £1,500 budget).
• Occupancy & Voids: Occupancy rate, void count, estimated cost per void per month (monthly income ÷ occupied units), and ROI of filling voids.
• CFV Risk: CFV exposure vs £1,500 allowance, count of unactioned CFVs and value at risk.
• Quick Wins: Prioritised action list: fill voids (1), action CFVs (2), reduce maintenance if over budget (3), plus a note about mortgage clusters on days 1–6.

Below the AI commentary the dashboard works out how to split one payment across the cards. It is a single-payment allocator, not a weekly schedule. There is no Friday timetable and no £750 buffer any more. The card list is built inline in renderDashboard() (js/dashboard.js:1950-1990) and the split is redrawn by recalcCCStrategy() (:2046).

Any card with nothing owed drops out of the list entirely (:1966).

How the split is worked out

1. The Payment box starts at the low operating cushion figure, rounded down (:1991). You can type any amount over it and the split redraws as you type.
2. Cards are sorted by estimated APR, dearest first (:2049). This is the avalanche method: pay the minimum on everything, then put all the rest against the dearest card.
3. Every card gets its minimum first (:2054). If your figure is below the total of the minimums, the total of the minimums is used instead (:2052).
4. Whatever is left goes to the dearest card until it is cleared, then to the next (:2055-2059).
5. The summary line estimates next month’s interest on whatever is still owed after the payment (:2077-2085).

The standalone Balance Calculator has gone, along with its own opening balance box and its Select All, Deselect All, Inflows Only and Outflows Only buttons. The what-if tool now sits inside the cash flow forecast itself: open any day in the table and every expected item has a tick box beside it (js/cashflow.js:670-673 for money in, :681-684 for money out).

1. Ticked means the item is still expected and counts towards the forecast. Untick it to take it out.
2. Unticking redraws the table, the totals and the chart straight away (toggleCFExclusion(), :1148).
3. Items already reconciled in Airtable are shown struck through with a Reconciled badge and have no tick box. They are already in the bank, so there is nothing to model.
4. The amber dashed What-If line on the chart shows the balance with your unticked items removed, and also takes off the wages budget spread evenly across the 31 days (buildWhatIfLine(), :1159-1179). It only appears once something is unticked.

1. Open Google Apps Script at script.google.com and open the existing project (or create new).
2. The script reads Gmail threads labelled 3. to pay, extracts invoice fields (payee, amount, due date, reference), and handles markPaid actions.
3. Deploy as a Web app: Execute as Me, Who has access: Anyone.
4. Copy the Web app URL and paste into GMAIL_SCRIPT_URL in js/config.js.
5. Verify by loading the Invoices tab — invoices should appear with a live badge.

Four cards at the bottom of the KPI grid track the north star: getting up to 90% of repeatable operational work done by AI agents. Two of them measure the outcome.

What counts as AI work (both cards use the same rules): a task completed with an AI agent on the Team Member field, or work an agent prepared that was approved first time. Work that was sent back for changes never counts as AI work, whatever the links say, because a human had to redo it.

How the money figure is worked out: every completed task carries a time estimate (how long a person would need). AI hours are those estimates summed for AI work, then valued at £17.50 per hour: the UK office admin wage plus employer National Insurance and pension. The rate and the go-live date live in js/config.js (AI_LABOUR_RATE_GBP_PER_HOUR, AI_WORK_EPOCH), so changing them is one edit. Figures are whole pounds; pence on an estimate would be false precision.

Trust guards: both cards publish the share of completed tasks carrying a time estimate and warn below 80% (a task without an estimate is invisible to the sums). An empty query shows "no data", never a fake 0% or £0. The health bar's "AI Time & Money Saved card computed" check confirms the card loaded on every sync.