How to Write OKRs: Measurable Goals and Reliable Check-Ins

An OKR pairs an Objective, the meaningful outcome a team wants to pursue, with Key Results, measurable evidence of progress toward it. For example, a sales team might aim to make first-time buyers more confident in the evaluation process and measure whether qualified leads convert to opportunities at a higher rate. Using a discovery checklist may support that result, but it is not the result itself.

Useful OKRs create a measurement agreement. Another person should be able to tell what is being measured, for whom, over what period, from which source, and how to reproduce the reported value. This guide explains how to write that agreement, review evidence at the correct data grain, and change a definition without erasing history.

The examples use a sales workflow, but the operating principles apply to any team that needs goals which can be owned, reviewed, and explained.

What is an OKR?

OKR means Objectives and Key Results. The Objective states the intended outcome. Its Key Results define observable finish lines. An initiative is an action or project intended to help achieve a Key Result.

Microsoft’s historical OKR guidance illustrates the distinction with a measurable result that moves a metric from one value to another and an initiative such as conducting research. Microsoft Viva Goals was retired on December 31, 2025, so that guidance is useful here as methodology, not as a current product recommendation.

Use this fast classification test:

• If a statement describes a desired condition and has a measurable finish line, it may be a Key Result.
• If it describes work to perform, treat it as an initiative.

For example, “Use a discovery checklist on every first call” describes an activity. “Increase qualified lead to opportunity conversion from 18% to 25% for qualified leads created in Q3” describes an outcome, provided the conversion is defined precisely.

Three to five Key Results per Objective is common guidance, not a universal rule. Microsoft’s former guidance recommends three to five, while Google’s archived guide refers to approximately three. Choose a small number that captures the outcome without turning every task into an OKR.

OKRs and KPIs: how they fit together

A KPI is a performance measure. An OKR supplies a time-bound goal and strategic context for selected measures. A KPI can become a Key Result when it is tied to an Objective, target, cycle, and defined scope. A KPI does not become an OKR merely because it appears on a dashboard.

Atlassian also presents OKRs and KPIs as complementary. A KPI helps monitor operational health. A Key Result identifies a deliberate change the team intends to make during a defined cycle.

Ask: “Is this measure a deliberate change we intend to make during this cycle?” If not, keep it as an operational KPI rather than forcing it into an OKR.

Write an OKR that can be measured and reviewed

Start with a concise, directional Objective that describes impact rather than a task or a metric by itself. Then choose a small set of measurable Key Results. A useful starting formula is:

Move [metric] from [baseline] to [target] for [population] by [date].

One illustrative sales Objective is: “Make first-time buyers more confident in the evaluation process.” A corresponding Key Result could be: “Increase qualified lead to opportunity conversion from 18% to 25% for qualified leads created in Q3, by September 30.”

The percentage is not sufficient on its own. Define the numerator, denominator, cohort, exclusions, and attribution rule so that different reviewers do not calculate different results.

• Numerator: qualified leads in the defined cohort that become opportunities.
• Denominator: qualified leads created in the same cohort period.
• Scope: specify how duplicates, test records, reopened opportunities, and imported records are handled.
• Attribution: state the agreed source or rule used to connect an opportunity to a lead.

Keep initiatives separate. Using a discovery checklist, reviewing rejected opportunities, and training representatives may support the outcome, but completing those activities does not prove that conversion improved.

If a trustworthy baseline is unavailable, assign an owner and a dated baseline measurement task first. Do not invent a starting value or disguise that task as the Key Result.

Give every Key Result a metric contract

A metric contract is a practical implementation recommendation. It is not a vendor published OKR schema. The contract records enough information for another owner to reproduce the measure and for a reviewer to understand an update.

• Identity and accountability: objective ID, Key Result ID, accountable owner, and data steward.
• Time: cycle start, cycle end, and update cadence.
• Measurement: metric name, metric definition, baseline, target, unit, direction, population or scope, and aggregation method.
• Evidence: source system, source report or query, evidence location, retrieval time, and metric definition version.
• Change control: the person who can approve a target or definition change and the rule for preserving prior observations.

Direction should say whether the measure must increase, decrease, remain within a range, or meet a threshold. For a rate, define how counts are aggregated. Do not add daily conversion percentages to produce a quarterly rate. Combine the relevant numerator and denominator counts for the agreed cohort, then calculate the rate.

Rules and schema validation are better than AI for predictable checks such as required fields, allowed units, date order, and numeric ranges. AI can suggest clearer wording, identify terms such as “better” or “faster,” or flag a likely task statement. A person must approve the meaning, target, and metric definition.

If the measure depends on CRM reporting, CRM systems consulting may be relevant when reviewing source data and reporting definitions.

Align ownership and dependencies without copying goals

Team OKRs should contribute to company priorities without simply repeating their wording. Microsoft’s historical alignment guidance describes objectives linked up, down, and across an organization. A team Objective can support a parent priority while expressing a distinct outcome. The guidance also describes setting strategic direction first and inviting team input about feasibility and dependencies.

Give each Key Result one accountable owner, even when several teams contribute. That owner is responsible for the result. A data steward is responsible for the quality and interpretation of the source measure.

For shared results, name contributing teams, agree on one authoritative metric source, and resolve conflicting definitions before the cycle begins. Use least privilege access and avoid including employee sensitive details that are not needed to measure the result.

Run check-ins as evidence reviews, not status rituals

Choose a cadence that fits the measure. Weekly operating reviews are commonly recommended, but cadence alone does not prove that a team is making progress. A useful check-in records an observation, the evidence behind it, blockers, and next actions.

Keep the dated observation separate from the final cycle score or aggregate. The CRM or analytics source remains authoritative for the underlying metric. The OKR register holds the agreed target, contract, check-in record, and evidence reference.

For a hypothetical manual review, the Key Result owner obtains the current value from the approved CRM report, checks that the report uses the agreed cohort and definition, and records the observation in the OKR register. A compact observation might contain:

{
  "key_result_id": "kr_sales_q3_01",
  "observed_at": "2026-08-07T09:00:00Z",
  "value": 0.21,
  "unit": "rate",
  "source_system": "CRM",
  "source_record_id": "report_run_88421",
  "metric_definition_version": 2,
  "evidence_location": "approved report or query reference",
  "reviewer": "Revenue Operations"
}

This is an illustrative record design, not a HubSpot or other vendor schema. Preserve the source identity, retrieval time, calculation method, and evidence reference as appropriate to the system.

If data is missing, stale, contradictory, or inaccessible, route it to the owner rather than silently carrying forward an old value. A human written exception note can be summarized with AI, but an AI summary is commentary, not the authoritative metric.

Use automation as a controlled observation process

For automated updates, treat the following as a general design pattern, not a claim that a particular OKR integration is currently available. A permitted scheduled process retrieves a source value, checks its freshness, unit, metric definition version, data grain, permissions, and cycle dates, then saves a check-in event with provenance.

1. Retrieve: read the permitted source report, query, or event.
2. Validate: confirm that the source is available, the value is in range, the unit and definition version match, and the observation belongs to the cycle.
3. Deduplicate: use a stable source event or report run ID where available.
4. Write: save the observation and evidence reference to the OKR register or goal system.
5. Escalate: stop the write when validation fails and route the exception to the integration owner or Key Result owner.

Define one row as one observation of one Key Result at one timestamp under one metric definition version. If a source has no stable record ID, construct a deterministic event key from the organization, cycle, Objective, Key Result, observation time, source, definition version, and normalized value. If multiple valid citations or report runs can exist at the same timestamp, include the source record ID or a content hash as well.

Do not use only Key Result ID plus date, since multiple legitimate observations can occur on the same day. A read then insert check alone can race under concurrent writes. Use a database enforced unique constraint or a transactional upsert. These are illustrative architecture recommendations, not vendor published fields.

Score results and revise definitions transparently

Scoring conventions differ. Google’s archived re:Work guidance describes a 0.0 to 1.0 scale and an average around 0.6 to 0.7 for ambitious OKRs. Treat that as a historical Google practice, not a universal target or a current policy for every Google team.

A partial score needs context. Inspect execution, baseline quality, measurement quality, and external changes. Neither a low score nor 100 percent completion proves, by itself, that the target was well or poorly set.

If conditions change or the measurement proves defective, record the reason, approver, effective date, and impact on comparisons. Preserve the old definition and observations. Version the definition or create a replacement Key Result rather than silently overwriting the history. Explain whether past values can be recalculated under the new definition. If they cannot, mark the break in comparison.

Choose a template or system with its limits in view

HubSpot’s current OKR template page describes an Excel workbook or PDF and broad fields for objectives, measurable Key Results, and progress tracking. The downloadable asset is gated and was not independently inspected. The landing page does not establish a public schema, API, validation rules, approval workflow, or automatic synchronization.

A shared spreadsheet can suit a small team that can review evidence manually and preserve dated observations. Consider a more structured system when metric definitions, access, owners, and update rules are stable enough to govern. Keep the system of record explicit: the CRM or analytics system owns its underlying measure, while the OKR register owns the agreed goal and review record.

Teams evaluating workflow setup may consider ClickUp setup and automation, without assuming that a specific OKR template or integration is included.

Microsoft Viva Goals is not a current option. Microsoft retired it on December 31, 2025. Its still accessible methodology and check-in pages describe historical product guidance, not a deployable workflow in 2026.

A short implementation checklist

Before publishing an OKR cycle, check whether the metric is ready and whether its evidence can be reviewed. Automate only after ownership, access, and exception handling are agreed.

Useful OKRs are not just ambitious statements. They are owned outcomes with measurements that can be reproduced, reviewed, and revised without losing the evidence behind them.