“Free OKR Template for Notion (Download + Guide)”

What should a Notion OKR template contain?

It should contain an objective, three to five key results, a baseline, a target, a current value, a computed score, an owner, a confidence rating, and a review date. Any property not tied to one of those nine items is a field someone stops filling in by week three.

The table below is the field list I use, with the exact Notion property type. Types matter more than names, because the type decides whether Notion can compute anything from the field.

Notice what is missing: no “status” emoji property, no “priority”, no “RAG dashboard” page. Those are reporting artefacts. In a small team they become a second, contradictory source of truth.

The same logic applies on the key-result side. Each key result needs Metric type (increase, decrease, or done/not done), Baseline, Target, Current, Unit, and Weight. A key result without a baseline is a wish with a deadline.

How do you build the OKR databases in Notion, step by step?

Build the key-result database first, then the objective database, then the relation, then the rollup. Doing it in that order avoids the most common dead end, which is creating a relation before the target database has the properties the rollup will need.

1. Create a page and add an inline database called Key Results. Use a full-page database if you plan more than fifty rows per quarter.
2. Add properties: KR (Title), Metric type (Select), Baseline (Number), Target (Number), Current (Number), Unit (Text), Weight (Number), Confidence (Select), Updated (Date).
3. Add a formula property called “Progress %” that converts baseline, target, and current into a 0–1 fraction. The formula is in the next section.
4. Add a second formula property called “Weighted points” that multiplies Progress % by Weight.
5. Create a second database called Objectives with Objective (Title), Quarter (Select), Owner (Person), Confidence (Select), Check-in (Date), and Notes (Text).
6. Add a Relation property on Objectives pointing at Key Results. Turn on “Show on Key Results” so the link appears on both sides. Notion creates the reverse relation automatically.
7. Add a Rollup property on Objectives: relation = Key Results, property = Progress %, calculate = Average.
8. Add a second Rollup on Objectives: relation = Key Results, property = Weighted points, calculate = Sum.
9. Add a database template inside Objectives, so the “new objective” button pre-fills three key-result slots, a quarter, and a check-in date.
10. Save the whole page as a team template by duplicating it into your teamspace and locking the master copy.

Step 10 is the one people skip. A template that lives inside the working database gets edited by whoever is frustrated that week, and six weeks later two teams are scoring differently.

Which formulas make OKRs scoreable in Notion?

Two formulas are enough: a progress fraction and a weighted contribution. Everything else, including traffic lights and percentages, can be derived from those.

The progress formula handles three metric types in one expression:

if(prop("Target") == prop("Baseline"), if(prop("Current") >= prop("Target"), 1, 0),
if(prop("Metric type") == "Decrease",
  (prop("Baseline") - prop("Current")) / (prop("Baseline") - prop("Target")),
  (prop("Current") - prop("Baseline")) / (prop("Target") - prop("Baseline"))))

The first line handles the degenerate case where baseline equals target, which happens constantly with “ship three case studies” style key results. Without that guard, Notion returns an error and the rollup silently drops the row, which is worse than an error.

The weighted points formula is deliberately trivial: `prop(“Progress %”) * prop(“Weight”)`. With weights that sum to 1.0 across the key results of an objective, the Sum rollup returns a score on the same 0–1 scale Google popularised. If weights sum to 1.3, the objective can score 1.3, and your quarterly review becomes a negotiation about arithmetic.

Two things Notion will not do for you. It will not stop a weight column from summing to the wrong total, so add a formula check on the objective that flags it. And it will not let a rollup read another rollup, so all computation must live on the key-result row, never on the objective.

A quick note on confidence: keep it a Select with three values, not a number. “At risk” is a judgement, not a measurement, and teams that score confidence numerically spend meetings arguing about whether 0.4 is worse than 0.35.

What does the arithmetic look like in practice?

Here are three worked examples, using the kind of numbers a real team types into the template.

Example 1 — revenue key result. Baseline ARR is $1,200,000, the target is $1,800,000, and current ARR is $1,450,000. Progress = (1,450,000 − 1,200,000) ÷ (1,800,000 − 1,200,000) = 250,000 ÷ 600,000 = 0.417, or 42%. A team that reports “we’re at 62% of target” is describing distance to the target, not progress toward it, and the two numbers differ by twenty points.

Example 2 — a weighted objective. Three key results carry weights of 0.5, 0.3, and 0.2. Scores are 0.42, 0.80, and 1.00. Weighted points: 0.21 + 0.24 + 0.20 = 0.65. The objective scores 0.65 against a 0.7 target, so it is amber, not red. Equal averaging would have produced 0.74 and a false green light — the most important key result was the weakest one, and weighting is what surfaced that.

Example 3 — the cost of check-ins. Six objectives with four key results each is 24 numbers. At 90 seconds per number, including opening the row and typing a short note, that is 36 minutes a week. Multiply by thirteen weeks and you have nearly eight hours per quarter spent on measurement. That is a reasonable price for a decision-making system and an unreasonable price for a ritual, which is why the check-in belongs in a 20-minute weekly meeting, not in an asynchronous reminder nobody reads.

Example 4 — the decrease metric. Support first-response time starts at 9.5 hours and should fall to 4 hours. Current is 6.2 hours. Progress = (9.5 − 6.2) ÷ (9.5 − 4) = 3.3 ÷ 5.5 = 0.60. Reversing the subtraction, the way a copied increase-formula would, gives a negative number and a rollup that looks broken.

What does a filled example look like?

A single objective, fully populated, is the fastest way to see whether a template is complete. This one is for a twelve-person B2B software team.

Objective score: 0.69. Confidence: at risk. Check-in: 9 February. Note: “Import shipped but activation lift is smaller than modelled; two enterprise accounts onboarded manually and are excluded from the median.”

That note is worth more than the score. A template that only stores numbers produces a scoreboard; one that stores a sentence of context produces a decision. Build the Notes field, and make the weekly meeting read it out loud.

Which views are worth creating?

Three views cover almost every need: this quarter by owner, at-risk items, and a scorecard grouped by quarter. More than five views is a sign that people are using Notion as a reporting tool when they should be using it as a working tool.

The “at risk” board is the one that earns its place. Grouping by confidence turns a flat list into a triage surface in about four seconds, and it answers the only question a leadership meeting actually has: where do we intervene this week?

Where does the template break?

It breaks in four predictable places, and knowing them in advance is cheaper than discovering them in a quarterly review.

Notion cannot enforce process. Nothing stops someone from editing a target downward in week ten. The fix is social, not technical: lock the properties on the master template, and require a note in the row whenever a target changes. Notion’s page history only goes back seven days on the free plan, so an audit trail is not something you can rely on there.

Rollups are shallow. One level, fixed aggregations, no weighted average, no rollup of a rollup. If your OKR tree has company objectives rolling into department objectives rolling into team key results, Notion will not compute the chain without a formula layer that most teams cannot maintain.

Goals and work live in different places. A key result scores 0.4 because the underlying project is late, and Notion cannot tell you which of the fourteen tasks in that project is the reason. You end up opening a second tool, which is where the check-in evaporates.

Permissions are coarse. Notion shares at the page and database level. If compensation-linked objectives sit in the same database as everyone’s, you either share too much or duplicate the database and lose the rollup.

The honest trade-off: Notion is the best place to *write and discuss* OKRs, and a mediocre place to *run* them. That is a reasonable split — as long as you decide it deliberately rather than discovering it in April.

When is a dedicated tool the better choice?

When the OKR score has to move because work moved, not because someone remembered to type a number. That is the dividing line.

This is where Doitify comes in, and since it is our product, treat this paragraph as disclosure rather than review. Doitify connects goals to projects, tasks, sub-tasks, checklists, owners, and due dates in one workspace, with Kanban boards, Gantt charts, roadmaps, workload views, and work and performance reports. A key result can be tied to the project that produces it, so progress comes from completed work rather than a manual check-in. Doitify Copilot and AI Coach help turn a stated goal into tasks and a plan.

The trade-off is real in both directions. A five-person team with three objectives does not need task-level linkage; a Notion database is faster to set up and free. A forty-person organisation with quarterly commitments to a board needs the linkage, because manual score-keeping at that size fails quietly.

What are the most common mistakes?

• Scoring distance to target instead of progress from baseline. It flatters every team in the first month and hides the hardest key result.
• Writing key results as tasks. “Launch the new pricing page” is a task. “Increase trial-to-paid conversion from 8% to 12%” is a key result, and it can be missed even when the page ships.
• Five objectives per team. Three is usually the ceiling; beyond that the weekly check-in becomes a reading exercise.
• No baseline. Without one, the formula has nothing to subtract from and someone quietly invents a zero.
• Editing targets mid-quarter without a note. The score stops being comparable, and next quarter’s planning starts from a fiction.
• Treating the template as the system. The template is a container. The review cadence is the system.

Conclusion

A good OKR template for Notion is small: two databases, one relation, two formulas, three views. The value is not in the fields you add but in the arithmetic you refuse to do by hand. Once progress is a formula, the quarterly review stops being a debate about adjectives and becomes a conversation about two numbers and a note.

Build the key-result database first, guard the formula against equal baselines, and weight the key results so the important one cannot hide behind two easy ones. Then decide, deliberately, whether Notion is where your OKRs live or merely where they are written down.

If this post on OKR template for Notion was helpful, you might also enjoy Workplace Productivity Statistics for 2026 and Free Decision Log Template: Columns, Examples, and How to Use It.