How an Operations Lead Rebuilt Her Planning System with Notion AI

A case study following Ravi's colleague Leena — an operations lead at a 40-person company — through two failed Notion setups and one that finally stuck.

Leena manages operations for a 40-person B2B software company. Her work spans vendor contracts, internal process documentation, cross-functional meeting coordination, and quarterly planning for the operations function. She is the kind of person who has tried every productivity tool — and the kind of person who abandons most of them.

Her Notion history is instructive.

Attempt One: The Beautiful System That Collapsed

In early 2024, Leena built a Notion workspace from scratch using a template she had bookmarked for months. It had a master database for all projects, a linked task database, a meeting notes section, a company wiki, and a personal goals area. Everything was logically connected, beautifully structured, and consistently used for exactly eleven days.

The collapse came from a predictable direction: a chaotic stretch at work. Two simultaneous vendor renegotiations, a team offsite to plan, and an urgent process audit that nobody had anticipated. For three weeks, she did not open Notion at all.

When she came back, the system felt foreign. The elaborate property structure required decisions she did not have the bandwidth to make. The template that had felt empowering when she was relaxed felt like a burden when she was overwhelmed. She left it.

“The system I built was designed for my best self,” she said later. “The problem is my best self only shows up about half the time.”

This is a direct articulation of Failure Mode 3 from the myth-busting article: systems designed for peak performance fail under average-week conditions.

Attempt Two: The Minimal Rebuild

Six months later, Leena tried again with a different design principle: the system should be maintainable during a bad week.

She stripped the workspace down to three elements: a Projects list (flat, no relational links), a meeting notes database, and a goals page (a regular Notion page, not a database). Total setup time: two hours.

This version lasted longer — about six weeks — but hit a different wall.

The meeting notes were piling up. She had dozens of entries from cross-functional syncs, vendor calls, and planning sessions. Finding information required manual search. “I could not answer a basic question like ‘what did we decide about the onboarding timeline’ without spending fifteen minutes scrolling through notes.”

The system had solved the maintenance problem by eliminating the structure that would make information retrievable.

The Turning Point: Relational Structure Plus Selective AI

The third attempt came after a colleague mentioned using Notion AI’s Q&A feature for meeting-dense workweeks. Leena rebuilt the workspace again, this time with two design constraints she had not combined before:

Constraint 1: Relational databases, linked hierarchically (Goals → Projects → Weekly Notes) Constraint 2: Minimum viable fields — maximum five properties per database on day one

She built the Goals database with four properties: Title, Area, Target Date, Status. The Projects database had five: Title, linked Goal, Status, Due Date, Blockers. The Weekly Notes database had three: Week Of, linked Projects, Reflection.

That was it. No tags. No priority levels. No effort estimates. No secondary databases.

She also changed her documentation behavior: every meeting that touched a project got a brief notes page linked to that project. Not comprehensive notes — just decisions made and action items. Often under ten sentences.

Where Notion AI Changed the Calculation

After three weeks of consistent capture (still imperfect — maybe 70% of meetings got notes), Leena tested the Q&A feature for the first time.

She asked: “What are the open action items from my vendor meetings in the last two weeks?”

The response synthesized across four meeting notes pages and returned a coherent list. It took eight seconds. The manual equivalent would have been twelve minutes.

“That was the moment I stopped thinking of the system as work,” she said. “It started giving back more than it took.”

Over the following four weeks, she established a pattern around three Q&A prompts used during weekly review:

What projects are currently showing a Blocked status, and what are the listed blockers?
Summarize the decisions made across operations-tagged meetings in the last seven days.
Which projects have a due date in the next two weeks?

These prompts returned useful answers because the underlying database structure was relational and the meeting notes were consistently linked to projects. The AI Q&A was surfacing the structure she had built — it was not creating synthesis from nothing.

The Role of AI Writer in Project Scopes

Leena added AI Writer to her workflow for project creation. When a new initiative came up (a vendor audit, an onboarding process redesign, a team capacity planning exercise), her previous approach was to create a Notion page and start typing notes.

The new approach: create the project entry, open the page, and prompt:

Draft a brief project scope for an operations initiative. Objective: [two-sentence description]. Include: one-sentence goal, three key milestones with rough timing, main risk to flag, and how success will be measured.

The AI produces a starting draft in fifteen seconds. Leena edits it down — usually removing half the output, keeping the structure. Total time to a documented scope: four minutes instead of twenty.

“It’s not that the AI draft is good,” she noted. “It’s that having a draft to edit is faster than writing from nothing. The thinking is the same — the blank page friction is gone.”

This is an honest description of how AI Writer is most useful. It removes blank-page friction. The thinking and editing remain yours.

The Breakdown That Did Not Break the System

In week eight, Leena had another bad stretch — a company-wide restructuring announcement that consumed two unplanned weeks. She missed three weekly reviews and her daily notes were sparse.

The difference from the first attempt: when she came back to the system, it was still navigable. The minimal property structure did not require reconstruction. The relational links still worked. The Q&A could still surface the last valid state of each project.

“I lost two weeks of context, but the system was still there. That has never happened before with anything I have set up.”

The recovery took one Friday afternoon: running the three weekly review Q&A prompts, updating project statuses, writing a brief reflection on what had slipped during the interruption. Two hours to restore planning clarity after a two-week disruption.

What the Daily Planning Layer Still Could Not Do

Even with the Q&A synthesis working well and the project database current, Leena identified one gap the system did not address: the start-of-day planning conversation.

The Notion system answered “what is the state of my projects?” but not “what should I actually do today, given everything competing for my attention?” The database showed all active projects. It did not help her reason through which one deserved her first two hours.

For that gap, she started using a dedicated daily planning conversation — a brief, structured AI chat at the start of her morning using Beyond Time, which prompts her through priority-setting based on the day’s constraints. The Notion system provided the project context; the daily planning conversation helped her decide what to do about it.

“They solve different problems. Notion is my memory. The morning planning is my thinking.”

The Lessons That Generalize

One: Design for a bad week before a good one. The system should be maintainable at 60% capacity, not 100%.

Two: Relational linking is non-negotiable. Without it, AI Q&A cannot traverse the planning hierarchy and the system is just a searchable filing cabinet.

Three: Documentation quality compounds. The first few weeks of notes are thin. The eighth-week Q&A returns qualitatively better synthesis than the second-week Q&A. The system gets more valuable the longer you use it.

Four: AI Writer reduces blank-page friction, not thinking time. The scope drafts are starting points, not finished documents. The value is speed-to-editable-draft, not quality-of-final-output.

Five: No Notion system fully replaces the planning conversation. The database tells you where things stand. Deciding what to do next still requires reasoning — and that is better done in dialogue than in a database view.


Related: The Complete Guide to Notion AI for Planning · Why Notion AI Planning Pages Get Abandoned · The Notion Plan OS: A Framework for AI-Powered Goal Tracking


Your action for today: Look at your current Notion workspace (or wherever you track projects) and count the number of properties per database. If any database has more than seven required fields, remove the three you fill in least consistently. Simpler capture is the single most reliable predictor of sustained use.


Tags: notion ai case study, operations productivity, notion planning system, knowledge work, ai planning workflow

Frequently Asked Questions

  • Is this a real case study?

    Leena is a composite persona based on patterns common among operations-function knowledge workers who use Notion for cross-functional planning. The specific challenges, failure modes, and resolutions described reflect real patterns observed in Notion power users — not a single individual's story.

  • What role does Notion AI play in an operations context specifically?

    Operations roles tend to benefit especially from Notion AI's Q&A and summarization features because the work is documentation-heavy: meeting notes, project scopes, cross-team decision logs, and status updates accumulate at high volume. The AI's ability to synthesize across that content saves meaningful time compared to manual search and review. Auto-fill is also valuable for operations workflows where incoming requests need consistent tagging and routing.

  • Can this system work for a team, or only for individuals?

    The Notion Plan OS is designed for individual planning, but each layer can be extended for team use. The Projects database is naturally collaborative — multiple team members can own different projects. The Goals database can include team-level goals alongside personal ones. The main adaptation for team use is establishing shared norms around documentation quality, since Q&A across a team workspace depends on consistent capture across multiple contributors.