Skip to content

Goals and OKRs

Business-Gym tracks goals as objectives with key results, and the point of the feature is that a key result’s number is measured, not typed. You bind each key result to a live source — Stripe, Microsoft Clarity, your ad accounts, your own Business-Gym data — and the platform reads it on a schedule.

Where no source can measure a key result, the page says so plainly instead of showing a number it does not have. That honesty is the part worth understanding before you set your first objective.

Where do goals live, and who can change them?

Section titled “Where do goals live, and who can change them?”

Open Goals in the left navigation. The page is titled “Goals (OKRs)” and holds your company-level objectives and their key results; a department Head’s own goals live on the Goals tab of that Head’s page, which you can reach from working with a Head.

Reading is open to everyone with access to the workspace. Creating, editing, deleting and updating progress are owner/admin only — a read-only user sees the board without the controls.

Two bulk controls sit on the panel: Import OKRs takes a pasted block or a CSV and creates objectives, key results and guards in one pass, and Export OKRs downloads the current set as a CSV.

You bind it to a live source. Each key result has a Bind live source control; it asks which metric you are binding (the key result’s own metric, or its guard metric), a connector, a query / metric id, and a refresh cadence.

Sources that exist today include Stripe (recurring revenue, active and trialing subscriptions, 30-day churn, new customers), Microsoft Clarity (sessions, engagement time, rage-click rate), Meta Ads and Google Ads (month-to-date spend, clicks, cost per click), and a set of metrics computed from your own Business-Gym data — gross margin, collection rate, days sales outstanding, open tasks, pending approvals, workflow success rate. See integrations for what each connection is allowed to do.

A bound source whose credentials are not configured yet does not fail silently or invent a value. It reports itself as not connected, and the key result stays unmeasured until the credential lands.

Once a day, at 04:13 UTC, a scheduled job re-reads every bound key result and guard for your active Heads and for your company-level objectives. An owner or admin can also press Refresh now on the Goals page, which re-pulls immediately and reports how many key results synced.

Two limits are worth knowing. The refresh cadence you choose when binding (hourly, daily, weekly) is stored on the binding but not yet honoured by the scheduler — the scheduled sweep runs daily for every bound key result regardless. And the sweep covers enabled Heads only, plus company-level objectives; a disabled Head’s key results do not refresh.

Every read is read-only. Refreshing a metric never writes back to Stripe, an ad account, or a CRM.

What happens when nothing can measure a key result?

Section titled “What happens when nothing can measure a key result?”

The page tells you, in those words. An unbound metric reads “not bound”, a bound-but-never-synced one reads “no data yet”, the roll-up shows “no signal yet” for that key result, and a workspace with no measured key results at all shows “Not measured yet” rather than a fabricated 0% or 100%.

Some key results have no automatic source and probably never will — the number only exists because a human checks it. Those stay honest in two supported ways: you type the value with the Update control on the key result, or you bind the source as manual, which tells the daily sync to skip it and never overwrite your entry.

It counts how much of your goal set is actually measured, and it is the fastest read on the page. The banner appears above the board and shows lines like “12 of 40 key results measured”, “8 to bind — connect a source to see progress”, “5 waiting on credentials”, and “9 guards unbound — bind to enforce”.

Each phrase maps to a real state. To bind means no source at all. Waiting on credentials means the connector has a working reader but its keys are not configured yet. Guards unbound means a guard exists on paper but cannot be enforced.

The banner renders nothing when every key result is measured and every guard is bound, and it disappears rather than guessing if the coverage figure fails to load.

A guard is a counter-metric a Head must not breach while moving a key result — the anti-Goodhart check. You set three fields together: the guard metric, a direction (stay at or below / stay at or above), and a threshold. A partial guard is not applied.

In the Guard alerts view a guard is either breached, or listed as a quiet note when nothing proves it safe:

  • Breached — its last reading crosses the threshold, even when that reading is old. This is the only guard state that alerts you: it shows in your CEO digest, and a new breach opens a decision card.
  • Could not be confirmed — the guard is set up, but no current reading proves it safe (its reader had no data, failed, or none is connected). The note says when the last good reading was. It is not an alarm, but missing data is never read as safety: no Head proposes a new step for the key result until a current reading proves the guard safe. Work already assigned goes on.
  • Incomplete — some guard fields are set but not all. Set its metric, threshold and direction; until then no Head proposes a step for it.

A guard whose current reading is on the safe side is not listed. That is the same fail-closed instinct described in autonomy and the hard floor.

A Head drafts them and you approve them. On a Head’s Goals tab, Derive OKRs proposes department objectives from the company OKRs that Head is accountable for. They land in a “Proposed — review & approve” section as drafts, with Approve and Reject on each one.

A Head never activates its own goals, and a draft never counts toward the roll-up until a human approves it. This is the same propose-only posture as the rest of the platform: nothing here executes on its own, and anything that would send externally or move money stays human-approved. Approvals land in the approvals queue.

Most of the goal surface is built and running; the honest gaps are in cadence and connector coverage. Use this list to set expectations before you plan work around it.

  • Objectives, key results, progress, import and export — live.
  • Binding a key result or guard to a live source — live, owner/admin only.
  • Reading Stripe, Clarity, ad-account and own-data metrics — live per connector, each gated on its own credentials.
  • Meta Ads and Google Ads readers — built, but off behind a feature flag until access is granted.
  • Daily 04:13 UTC sync plus on-demand refresh — live.
  • Per-binding refresh cadence (hourly / weekly) — stored, not yet honoured by the scheduler.
  • Coverage banner and roll-up coverage counts — live.
  • Guards (a breach alerts you; a guard that cannot be confirmed fails closed) — live.
  • Head-derived department OKRs with human approve or reject — live.
  • Manual key results that the sync never overwrites — live.