How It Works
This operating model pulls MRR and revenue data from Salesforce, applies configurable filters, and computes a financial model. Here's how each piece works.
1. Operating Model at a Glance
This is Harper's official revenue and cash model — the successor to the company's Google Sheet operating model. It pulls deal data from Salesforce, layers on the finance team's forecasting assumptions and the actuals from the books, and computes the numbers leadership, the board, and investors use: MRR, ARR, cash, and runway.
The source of truth is the default scenario (currently “Base Case”). Every other scenario is a what-if built on top of it — historical actuals flow from the default into every scenario automatically, and only forward-looking assumptions differ.
Core numbers: MRR and ARR (recurring SaaS revenue only — On-Premise and Services are one-time and excluded from ARR); MRR vs. gMRR (gMRR is the raw deal value, MRR nets out the revenue share owed on Akamai-sourced deals, and all cash math always uses net MRR); AR Invoiced, Net Burn, Cash Burn, and Runway (what we bill, what we spend on an accrual basis, what actually leaves the bank, and how many months of cash remain — 0 months means out of money, an infinity symbol means we're cash-flow positive with no projected runout).
The ARR Bridge breaks month-over-month ARR into New, Expansion, Contraction, and Churn — the standard walk used in board decks, 10-Q filings, and VC/PE benchmarks.
Freshness & auditability: the model reads from Salesforce and never writes back to it; every scenario is snapshotted automatically and every manual edit is logged with who, what, and when — so any historical number can be reproduced.
Questions: use the in-app chat (bottom-right of every page) or the read-only Claude connector — both answer from this model's own math, not a separate estimate.
2. Where the Numbers Come From
Two inputs feed the model. Salesforce supplies deal data through a read-only sync — Harper only ever reads from Salesforce here, it never writes anything back — including each deal's monthly revenue schedule, stage, and forecast category. Manual inputs cover what Salesforce doesn't track: operating expenses, cash balances, and other actuals straight from the accounting books, entered once on the default scenario so every other scenario sees the same numbers.
An admin can trigger a Salesforce sync manually at any time, and can also turn on an automatic daily sync (05:00 ET) with no need to redeploy anything. Either way, the exact time of the last successful sync is always shown in the sync indicator at the top-right of every page — hover it for the full timestamp, row count, and who triggered it.
3. Key Metrics, Defined Once
Every term below is used consistently everywhere in the app:
4. Scenarios: Which Number to Trust
The default scenario (currently “Base Case”) is the one number everyone should treat as truth — it carries the actual results from the books and Salesforce's synced pipeline. Every other scenario is a what-if: a different set of forecast assumptions (growth rate, deal probabilities, expense projections) layered on the same historical facts.
That sharing is automatic and one-directional: historical actuals always flow from the default scenario into every other scenario, so nobody re-enters the same numbers twice, and every scenario agrees on what already happened. Only forward-looking, forecast-only figures are free to differ between scenarios.
A scenario can also be marked “Start fresh” so it keeps that shared history but starts its own future with a blank slate instead of inheriting the default's forward assumptions — useful for a clean, investor-conservative forecast. See Advanced / Reference below for the mechanics.
5. The ARR Bridge
The ARR Bridge walks Platform ARR from one month to the next through four buckets: New business, Expansion (existing customers growing), Contraction (existing customers shrinking), and Churn (lost customers) — plus a small Prob. Shift residual when probability weighting is on (a deal's probability changed but nothing else did). The first month of any view opens at the real prior month's number, not zero, so an unchanged existing customer never gets miscounted as “new.”
Two filters are locked on this view because unlocking them would corrupt the math. Deal Type is always all three types together, because hiding any one type can make an existing customer's history disappear and get miscounted as brand-new. Closed (won) deals are always included, because they're the realized customer base every other month is measured against. You can still add pipeline categories (Commit, Best Case, etc.) on top of Closed to see “what if this pipeline closes” — but Closed-only is the standard board and investor view, matching how public SaaS companies report ARR walks.
The banner above the bridge also shows trailing 12-month Gross Retention and Net Dollar Retention, calculated the same way as the leadership renewal tracker. When the live data needed for Gross Retention isn't available (for example, viewing a saved snapshot), it correctly shows as unavailable rather than guessing.
6. Filters That Change the Answer
Every dashboard and the Live Model share the same set of filters, in the Filters panel:
- Forecast Category — which Salesforce pipeline stages count (Closed, Commit, Most Likely, Best Case, Pipeline).
- Deal Type — New, Expansion, or Renewal business.
- Channel — how the deal was sourced (a named partner like Akamai, or Direct). This is sales attribution only, not economics — a deal's revenue-share deduction is decided per deal, not by its channel label.
- Date range and probability weighting — the window you're looking at, and whether to discount pipeline deals by their close probability.
One nuance on Channel: the Live Model always includes hand-entered MRR (Modeled Additions and manual overrides) no matter which channels you've selected, because the cash math needs the full picture — so a single-channel Live Model view won't sum to the all-channels total. The Revenue Dashboard, by contrast, is exact when you narrow to specific channels: the numbers you see sum precisely to Salesforce's total for those channels.
If you save a scenario's filters with every channel box checked, it's stored as “all channels” — including any partner Salesforce adds later — rather than freezing today's exact list.
7. Snapshots, Audit Trail & Access
Every scenario is automatically snapshotted every night (04:15 ET), and a Salesforce sync — whether triggered manually or by the automatic daily sync — captures a before-and-after pair around it. That gives a complete, reproducible trail: any historical number can be traced back to the exact data that produced it.
Every manual edit anyone makes is written to the History log with who made it, what changed, and when.
Access is role-based: viewers can see everything but not edit; editors can additionally change scenarios and model inputs, and see edit history; admins can additionally manage users, trigger syncs, and see sensitive reports like renewal hygiene. Sign-in is Google OAuth restricted to an allow-list of company (and approved external) email addresses. Salesforce access is read-only, always — nothing this app does can change a record in Salesforce.
8. Ask the Model
A floating chat button (bottom-right of every page) lets you ask plain-English questions about whatever scenario you're viewing — “What's driving Net Burn this quarter?”, “Who are our top customers?” — and get an answer computed from this model's own numbers, citing the scenario and settings it used. It's strictly read-only: it can explain the model but can never change any data, so it's safe to point at live numbers. An admin turns it on per person.
Advanced / Reference
Everything below is the detailed mechanics behind the sections above — useful for power users, RevOps, and anyone double-checking a specific number. Click a topic to expand it.
Data Source
MRR and revenue data come from three Salesforce sources: OpportunityLineItemSchedule records (monthly schedules attached to each deal), Opportunity metadata (close date, billing effective date, term length, and amount), and a separate query for unscheduled opportunities (deals with no line items). If SOQL fails, the system falls back to the Salesforce Reports API. Sync is triggered manually via Admin → Salesforce Sync, or automatically once a day at 05:00 ET when an admin has enabled the daily sync toggle there (see the sync indicator in the header for the last successful sync).
Deals without any line items are included by extrapolating the total Amount evenly across the deal's term length (defaulting to 12 months if no term is specified).
Revenue Streams
Deals are split into three streams based on the Salesforce Product Family:
- Platform — Cloud/SaaS product MRR (the core recurring business)
- On-Premise — Legacy on-premise deployments (e.g., Lumen, Verizon), shown as monthly amounts but typically billed up-front
- Services — Professional Services billings (one-time implementation fees, non-recurring)
Use the Revenue Streams filter to include/exclude any combination.
MRR vs gMRR (Akamai Rev-Share)
gMRR (gross MRR) is the full schedule amount from Salesforce.
MRR (net MRR) applies a 20% revenue share deduction for deals sourced through Akamai. For Akamai partner deals, MRR = gMRR × 0.8. All other deals are unaffected.
An Akamai deal is identified when Lead Source = "Partner" AND Primary Partner contains "Akamai" (case-insensitive). When Primary Partner data is unavailable (SOQL mode), Lead Source = "Partner" alone is used as a proxy.
Weighted by Probability
When enabled, each deal's MRR is multiplied by its Salesforce probability (0-100%). Closed Won deals are 100%, while Pipeline deals might be 10-20%. This gives a probability-weighted MRR view.
When disabled, all included deals count at face value regardless of probability.
Forecast Categories & Slip Months
Salesforce assigns each deal a Forecast Category: Closed, Commit, Most Likely, Best Case, or Pipeline. The filter controls which categories to include.
Slip Months push MRR forward in time to account for deal timing uncertainty. These values are configurable per scenario in the Filters panel and default to 0 for all categories. A typical conservative configuration might be:
- Closed & Commit: 0 months (firm deals)
- Most Likely: 1 month
- Best Case: 2 months
- Pipeline: 3 months
Important: Renewals are never slipped regardless of forecast category — they're expected to close on schedule.
Deal Types
Filter by Salesforce Opportunity Type to focus on specific deal categories:
- New — First-time deals with a new customer or product
- Expansion — Upsells or additional products for existing customers
- Renewal — Contract renewals for existing customers
Uncheck a type to exclude it from all computations (MRR dashboard, ARR bridge, detail views, Live Model). This is useful for isolating just renewals to evaluate retention, or just new business to evaluate pipeline strength.
Accounts to Exclude
Some accounts should be excluded from the model (e.g., churned customers with residual schedules). Use the multi-select to exclude specific accounts by name.
Opportunity Overrides
Override the probability for specific deals, or exclude them entirely from all computations. Overrides are stored per-scenario, so different scenarios can model different assumptions about the same deal.
Probability override sets a different probability than what Salesforce shows. For example, if you know a Best Case deal is closing, override its probability to 100% to model it as committed MRR. This only affects weighted mode.
Exclusion removes an opportunity from ALL computations — MRR dashboard, ARR bridge, detail views, and the Live Model — regardless of weighted or unweighted mode. Exclusion takes precedence over a probability override.
Access opportunity overrides via the Manage Overrides button in the Data Filters section. The modal lets you search by account or opportunity name, filter by All / Overridden / Excluded tabs, and view key deal details (TCV, close date, term, SF probability). Account and opportunity names link to Salesforce.
Overrides do NOT modify any data in Salesforce — they only affect how this model computes MRR.
Renewals to 100%
The "All renewals → 100%" toggle in the Opportunity Overrides modal sets all renewal-type deals to 100% probability for MRR calculations. This is applied automatically at computation time — new renewals synced from Salesforce are included without re-toggling. You can still manually override a specific renewal's probability; manual overrides always take priority over the bulk toggle.
Growth Projections
When enabled, the model can project MRR growth beyond the Salesforce pipeline using a trailing growth rate.
Auto-detect analyzes each month's deal composition. When high-confidence deals (Closed + Commit) drop below 75% of total MRR for 2+ consecutive months, projections start there.
The growth rate is either manually specified or auto-computed from trailing months of actual data.
Renewal Projection
The renewal projection engine automatically extends open Platform opportunities past their natural Salesforce schedule end, preventing customers from appearing to mass-churn at term expiry.
How it works: For each open Platform opportunity where Billing_Frequency != "One-Time", the engine projects the last month's MRR forward through the scenario end date, weighted by the opportunity's Salesforce probability. This synthetic MRR is additive to whatever the schedule already covers.
Which opportunities qualify:
- Open stage (not Closed Won or Closed Lost)
- Platform product family (Cloud/SaaS)
- Billing frequency is Monthly, Annual, Quarterly, Custom, or null — anything except "One-Time"
Type=New toggle: By default, Type=New opportunities are also extended (a pipeline deal that hasn't closed yet may still represent committed future MRR). Turn off "Extend Type=New opportunities forward" in the scenario edit modal for a conservative view that only extends existing customers (Renewal and Expansion types).
Visual indicator: In the Live Model, renewal-projected cells render in italic gray (Platform MRR (Net) row only). In the Account Detail and Opportunity Detail modals, projected rows get a light-blue row background plus a Projected badge. In the Revenue Dashboard chart, renewal-projected months are dashed and marked with "~" in the axis label.
Renewal Hygiene: Accounts with active MRR but no open Renewal or Expansion opportunity will NOT be extended — the engine has no open opp to project from. The Renewal Hygiene report (under Admin → Settings) surfaces these gaps so RevOps can create the missing renewal opportunities in Salesforce.
Modeled MRR Additions
The "Modeled MRR Additions" row in the Live Model lets you layer per-month MRR assumptions on top of computed Platform MRR. This is a modeling tool — useful for scenarios like "BigCustomer closes Q3 2027 at $500K MRR" without modifying Salesforce data.
How to use it: In the Live Model, click any cell in the "Modeled MRR Additions" row and enter a dollar amount. The value is additive to Platform MRR for that month and can be set for any month (past or future — no future-only restriction, since this is a modeling tool, not actuals). Leave the cell blank (null) to exclude it.
What it flows into:
- Platform MRR (Net) display is unaffected — you can see base MRR separately
- Platform ARR (Net) = (Platform MRR (Net) + Modeled MRR Additions) × 12
- AR Invoiced includes Modeled MRR Additions
- Net Burn → Cash → Cash Runway all flow through naturally
Bridge classifier note: Modeled MRR Additions are aggregate per-month entries — they are not attributed to specific customers or opportunities. They raise the total MRR baseline the Bridge classifier sees but do not generate New Business, Expansion, or Churn events. The Bridge detail rows and per-customer amounts in the Customers tab are unaffected. This is by design: the Bridge reflects real account-level movements; the narrative total includes your model.
Actuals vs Forecast
The system distinguishes past actuals from forward-looking forecasts:
- Actual — Strictly past months (month is before the current calendar month). In the dashboard, this means realized Salesforce data; in the Live Model, the column header shows ACTUAL beneath the month label.
- Projected — The current in-flight month and all future months. In the Live Model, the column header shows PROJECTED. For example, on May 12, May reads as PROJECTED until the month closes — because we're only partway through it.
- Default (no badge) — In the dashboard, months computed from Salesforce pipeline data (forecast categories, weighted by probability, with slip applied) sit between Actual and Projected.
- Projected (growth projection) — When growth projections are enabled, this label is also used for months extrapolated beyond where the Salesforce pipeline has high confidence.
- Italic gray — In the Live Model's Platform MRR (Net) row, cells that include renewal projection (synthetic continuation of open SF opps past schedule end) render in italic gray. The same class is used for apportioned OpEx forecast defaults — hover the cell to see which signal applies. In the Account Detail and Opportunity Detail modals, projected rows additionally get a light-blue row background plus a Projected badge.
Live Model Formulas
The Live Model computes a full financial picture for each month:
Cells with a blue left border have manual overrides. Click any editable cell to enter a value; clear it to revert to auto-computation.
Navigation: Use the year pills (All / 2024 / 2025 / …) to filter the visible columns to a single year, or click Today to jump to the current month. Row labels stay pinned horizontally as you scroll across months. When you scroll down past the column headers, a floating copy of the month-header row (and its horizontal scrollbar) pins to the top of the viewport so you can keep your bearings deep in the table.
Keyboard Navigation (Editable Cells)
The Live Model supports Excel-style keyboard navigation in editable cells. Each keystroke saves the value before moving on; downstream computed cells (Net Burn, Cash Burn, % of Revenue, etc.) refresh in the background a moment later.
Scenarios
A Scenario is a saved set of filter configurations plus manual input overrides for the Live Model. The default scenario (typically "Base Case") represents the canonical view with all the actuals from the books. Additional scenarios let you explore alternative forecast assumptions (e.g., aggressive growth, conservative pipeline, different slip months) without disturbing the base case.
Use the Scenario dropdown in the header to switch between scenarios. The gear icon opens the scenario manager where you can create, clone, edit, or delete scenarios.
Inheritance: how non-default scenarios share actuals with the default
Past months in the Live Model contain actuals (operatingExpense, cashBalance, AR Invoiced override, Linode bill, etc.) sourced from the general ledger. These are facts — they don't change across scenarios. Future months contain forecast assumptions — those can differ per scenario.
To keep this clean, non-default scenarios inherit ModelInput values from the default scenario at read time. When an actual is updated on the default scenario, every other scenario instantly reflects the change — unless that scenario has its own explicit override for that field.
- On the default scenario — every editable cell is "yours." Edits save directly. No inheritance machinery applies.
- On a non-default scenario — cells with a "↪" prefix and gray background are inherited from the default scenario. Cells with a teal border are this scenario's specific overrides. Editing an inherited cell creates an override (turns teal); clearing an override (Esc to empty, then Enter) reverts the cell to inherited.
- Cloning a scenario — the new scenario copies the source's filter configuration but does not duplicate ModelInputs (they're inherited, not copied). Using the "New Scenario" modal's explicit Start Fresh checkbox always wins — whatever you check or uncheck there is what the new scenario gets. Using the plain "Clone" button instead (no modal) keeps the source scenario's own inherit mode: cloning a normal scenario yields a normal clone; cloning a fresh scenario yields a fresh clone.
Implementation note: scenario-specific override records only contain the fields you explicitly changed; everything else falls through to the default scenario at read time. This keeps non-default scenarios light and avoids "actual drift" across scenarios over time.
Fresh scenarios
A scenario can be marked fresh (inheritMode: "actualsOnly", shown as a "Fresh" badge next to its name) so it only inherits realized (past + current) months — future months are this scenario's own and start out blank unless you enter something. Use this to build an investor-conservative or clean-slate forecast without the default scenario's forward assumptions (mrrOverride, Modeled MRR Additions, Projected Expenses, funding, adjustments, notes, etc.) silently carrying over.
Toggle it from the New Scenario modal (creation) or the scenario edit modal (any time after). Flipping it ON for an existing scenario shows a confirmation and immediately blanks its currently-inherited future cells; flipping it OFF needs no confirmation and simply re-fills them. Values you entered yourself, in either direction, are never touched — the mode only decides what fills a blank cell. A month automatically starts inheriting the moment it becomes the current calendar month, with no re-save required.
Setting a scenario as default
Promoting a non-default scenario to default is more than a flag flip — that scenario stops inheriting from the previous default, so it would lose every value it was visually inheriting (past actuals, OpEx detail, etc.). To prevent this, the system runs an inheritance migration before flipping the flag: every value the new default would have inherited from the old default is copied into the new default's own records first. The new default's view is identical pre- and post-swap.
Where the new default already has its own value for a field, that value is preserved (the old default's value is not overwritten). The confirmation modal shows you exactly how many values will be copied and how many disagreements will be kept.
If the newly-promoted default was a fresh scenario, this migration only copies the old default's realized (past + current) months into it — future months stay whatever the fresh scenario already had (usually blank), since a fresh scenario never inherited the old default's forward assumptions in the first place. Once a scenario IS the default, inheritMode is moot: the default never inherits from anything, regardless of its own setting.
Each swap is one-way, not an undo. If you swap defaults back later, the same copy happens in reverse — values unique to the now-default scenario will be copied into the previous default. So while swapping is always available, the previous default may not end up identical to its pre-swap state.
Live Model Charts
Four charts appear above the Live Model table to visualize key financial metrics:
- Cash & Cash Runway — Cash balance (left axis) and months of cash runway remaining (right axis). Cash Runway is cash-basis and forward-looking: 0 when out of money (cash ≤ $0); the interpolated months to the projected cash-zero crossing when the model foresees one (so a lumpy upcoming outflow like the Linode AP paydown pulls runway down right away); otherwise cash ÷ trailing-3-month avg Cash Burn (projected past the model). Cash-flow-positive months have no runout — the runway line drops out (∞).
- Cash Burn vs Net Burn — Bars show Cash Burn (cash actually leaving the bank), color-coded green/red. Dashed purple line shows Net Burn (Accrual) — the operating loss from the GL. The gap between them is the Linode payment-plan effect.
- ARR Growth — Platform ARR (Net) over time. Hover for month-over-month growth rate.
- Platform MRR (Net) vs OpEx — Recurring SaaS MRR against operating expense. The gap between them is the monthly operating margin on the SaaS business.
Dashed chart segments indicate projected months. In the ARR and MRR charts, dashes mark months extrapolated by growth-rate projections; solid lines are actuals or Salesforce-backed data. In the Cash & Cash Runway chart the runway line is always dashed — it's inherently forward-looking.
ARR Bridge
The ARR Bridge tab shows month-over-month Platform MRR changes (On-Premise and Services excluded) decomposed into their underlying drivers using account-level MRR transitions. For each account, this month's total unweighted MRR is compared to last month's. Classifications are based on unweighted deal movements; displayed values are weighted when probability weighting is enabled. The first month of your date range opens at each account's real prior-month MRR (not $0), so an unchanged existing customer is "retained," never "New Business." Only a range with genuinely no data before it shows an all-new first month.
- New — Accounts with $0 last month that now have MRR (brand new customers)
- Expansion — Existing accounts with higher unweighted MRR (upsell, cross-sell, price increase)
- Contraction — Existing accounts with lower unweighted MRR (deal value decreased)
- Churn — Accounts that had MRR last month but $0 this month (lost customers)
- Prob. Shift — The residual from retained accounts whose probability changed without any deal movement. For example, a deal moving from Commit at 90% to Best Case at 60% changes weighted MRR but has no unweighted movement, so the difference appears here.
Click any cell to see account-level detail. When an account has multiple Salesforce opportunities, sub-rows show each deal's individual contribution with new, ended, or changed badges to clarify what drove the movement.
Why Forecast Categories and Deal Types are constrained on this view
The classifier compares each account's full MRR month-over-month, so two soundness conditions must hold:
- Deal Types → all 3 (locked). Deal types are taxonomic; filtering to a subset categorically hides existing customers. For example, a "Renewal-only" filter erases everyone whose only deals are renewals — when their next renewal kicks in, the classifier sees prevMRR = 0 and incorrectly labels them as New Business. Locking to all three ensures the classifier sees the full customer history.
- Forecast Categories → Closed always included. Closed-Won deals form the realized customer base. As long as that base is present, you can layer additional categories on top — Commit, Most Likely, Best Case, Pipeline — to construct forward-looking bridges. The Closed checkbox is locked on; the other 4 are user-toggleable.
This gives you both views:
- Closed only — the canonical realized-ARR walk reported in public-company 10-Q filings (Snowflake, MongoDB, Datadog, Cloudflare), the KeyBanc Capital Markets Annual SaaS Survey, and a16z/Bessemer benchmarks. Use this for board decks and investor reporting.
- Closed + selected forecast layers — e.g. Closed + Commit answers "what does the bridge look like if our high-confidence pipeline closes?" Useful for internal forecasting; not a published metric.
Other filters — date range, account exclusions, opportunity overrides, weighting, slip months — are honored as-is.
Account & Opportunity Detail
Click any account name or opportunity name throughout the app (bridge detail, MRR drilldown, opportunity overrides) to open an in-app detail modal. No Salesforce access required.
Account Detail shows:
- Summary cards: current MRR, runrate ARR (Platform × 12), health trend, active opportunity count, and revenue streams
- MRR tab: stacked bar chart and table of monthly MRR by stream (Platform, On-Premise, Services)
- Opportunities tab: all deals for the account with type, stage, forecast category, probability, and scheduled totals. Click an opportunity name to drill further.
- Bridge History tab: month-over-month Platform MRR classification (new, expansion, contraction, churn, retained). Like the global ARR Bridge view, this tab uses the same soundness conditions: Deal Types is locked to all 3, and Forecast Categories always includes Closed (with whatever other categories the user has selected layered in). The MRR and Opportunities tabs continue to honor your sidebar filters as-is.
Opportunity Detail shows deal metadata (type, stage, forecast, probability, close date, term length) and the full monthly schedule.
Internal users (@harperdb.io) see an "Open in Salesforce" link in both modals. External viewers do not.
Customers
The Customers tab decomposes monthly Platform MRR into per-customer contributions, with a stacked bar chart over time and a concentration table snapshot anchored to today's calendar month (or the last month in your date range with realized data, if today is outside it).
- Stacked bar chart — each customer is a separate segment of the monthly bar; total height is total Platform MRR. A secondary line shows total customer count over time. A vertical "Today" reference line marks the current month.
- All Customers mode (default) — every customer is its own segment, useful for showing the full customer base growth over time.
- Top 15 + Other mode — the 15 largest customers by latest-month MRR are shown individually; remaining customers roll up into "Other". Cleaner view when you want to focus on the largest accounts.
- Concentration table — sorted by % of total revenue, showing each customer's MRR, ARR, % of total, customer-since date, and trend. Click a customer name to open the Account Detail modal.
- Trend column uses a rolling 3-month window: compares the recent 3-month average to the prior 3-month average. Growing (+10%), Stable (±10%), Declining (-10%), Churned (had MRR, now $0), Pending (first MRR is in the future — they haven't started yet), New (no prior history to compare).
- Filters — all standard filters apply (date range, account exclusions, deal types, forecast categories, weighting, slip months, MRR vs gMRR). Use the Excluded Accounts filter to model "what if we lose customer X" scenarios directly.
This view surfaces customer concentration while letting viewers see the underlying customer-acquisition trend independent of any single large customer.
Note: per-customer growth projection is not applied in v1 (current projection logic extrapolates aggregate revenue). If your date range extends past the last month with realized data, the chart and table truncate at that month with a hint banner. For projected forward views, use the MRR Dashboard.
Channels
The Channels tab is the diversification view: it groups Platform MRR by sales channel instead of by customer. A channel is the deal's Salesforce partner (e.g. Akamai Technologies, Cloudflare Inc) or Direct — it's pure sales attribution and is independent of rev-share economics (the Akamai 0.8× net-MRR discount is applied per-deal regardless of how a channel is labeled).
- Stacked chart — monthly Platform MRR split by channel, with a secondary line tracking the top channel's share of total MRR: a falling line means the revenue base is diversifying. A Mix % toggle switches to a 100%-stacked share view.
- Concentration table — each channel's MRR, ARR, % of total, and trend, with a snapshot-month picker to re-anchor it to any realized month. Click a channel name to open the Channel detail modal (summary, monthly chart, and its accounts + opportunities, which cross-link to the Account/Opportunity modals).
- Channel filter (Filters panel & scenario editor) — narrow the whole app to one or more channels. It applies on every view including the ARR Bridge. On the Revenue Dashboard the filter is exact (per-channel revenue sums to the Salesforce total; clearing all shows $0). On the Live Model the hand-entered MRR layers (Modeled MRR Additions / overrides) are always included because the cash math needs them — so a channel subset there won't sum to the unfiltered total, and a banner explains it.
- Real data resolves to Akamai Technologies + Direct; new partners appear automatically as they show up in Salesforce.
Ask the Model — AI Q&A on Harper
The floating chat button (bottom-right) opens Ask the model: ask plain-English questions about whatever scenario you have selected — "How much cash runway do we have?", "What's driving Net Burn in September 2026?", "Who are our top 5 customers?", "What's our net revenue retention?" — and get a prose answer grounded in the live model. You can also right-click any cell in the Live Model (including computed cells like Net Burn, Cash, and Runway) and choose "Ask about this cell" to ask about that exact figure.
It's intentionally a read-only sidecar: it can read and explain the model but can never edit data, change scenarios, or run actions — so it's safe to point at production numbers.
Three answer tiers — two are served entirely by Harper
Every question is resolved by the cheapest path that can answer it correctly. The chip on each answer tells you which tier handled it, how long it took, and what it cost:
A running tally at the bottom of the panel shows how many AI calls have been avoided and the cumulative cost saved by the two Harper tiers.
What Harper is doing under the hood
- Local embedding model, on-node. The semantic tier turns each question into a vector using a small open embedding model (
nomic-embed-text) running inside Harper itself — no external API, no data leaving the box. This is the "small language model as a sidecar on Harper Fabric" pattern: lightweight AI co-located with your data.
- Harper is the vector store. Each question's embedding is stored alongside its answer in a Harper table — the same database serving the model also holds the semantic cache. To find a semantically-similar prior question, the cache pulls the active scenario's cached entries and ranks them by cosine similarity in the app, returning the nearest match within a strict distance threshold. (Vectors live in Harper; the similarity math runs co-located with the data.)
- Correctness guard. Numbers carry meaning, so two near-identical questions that differ on a value are not treated as the same: "when does cash hit zero?" and "when does cash hit $50K?" look almost identical by vector distance, but a numeric/temporal guard keeps them apart so a cached answer is never served for a different question.
- Self-healing cache. Editing the model (overrides, exclusions, filters, manual inputs) invalidates the affected cached answers automatically, so the chat never serves a stale number after you change an assumption.
It understands your scenario's configuration
The answers aren't just lookups — the Q&A is aware of the same levers documented above. When a number is what it is because of how the scenario is configured, it says so: it will cite a specific excluded opportunity (and the MRR it would have contributed), a probability override (e.g. a renewal forced to 100%, and the dollar effect), slipped deals, or a filter difference from the default scenario (e.g. "this scenario excludes Renewals"). So "why is Net Burn higher here than in the Base Case?" gets an attributed answer, not just a restated figure.
All answers are grounded strictly in the model's own computed values — the AI is instructed to cite only real figures from the data, never to invent numbers.
Operating Model