Skip to content
English
  • There are no suggestions because the search field is empty.

4.1 Cycle Planner System Guide

What cycle planners are, how architects use them, and the client-facing standard

What is a cycle planner?

A cycle planner is a Google Doc created for every 2-week delivery cycle with a client. It is the single source of truth for what is being worked on, what's done, what the client needs to do, and what comes next. It is shared with clients at the end of every meeting with the recap email. The client can view, add comments, and edit the Cycle Planner. This applies to any other document shared to the customer. They have the ability to see, edit, and add comments.

 

Required sections in every cycle planner

Section

What it contains

Definition of Done

A two-column table: 'New done state' vs. 'Current state'. Defines what success looks like by the end of the cycle. Must be specific and measurable — not vague.

Inclusions / Exclusions

What is intentionally being done this cycle vs. what is explicitly not being done. Prevents scope creep and sets clear expectations with the client.

Open Questions / Unknowns

Any blockers, dependencies, or unknowns that need resolution before or during the cycle. Tag the person responsible for answering each one.

The Work

Task table with columns: Task, Owner, Notes & Links, Status. Every task has an owner. Status must use the standard values defined below.

 

Task status definitions

Every task in The Work table must have one of these eight statuses. Using consistent statuses across all architects makes the cycle planner readable by anyone — including clients, Phil, and whoever covers if an architect is OOO.

 

Status

What it means

When to use it

Example

Not Started

The task has been identified and added to the cycle planner but no work has begun. Default state for all new tasks at the start of a cycle.

Use this when the task is planned but the architect has not yet touched it.

A new workflow has been scoped but not yet opened in HubSpot.

In Progress

The architect is actively working on this task. Work has started but is not yet ready for review or delivery.

Switch to this the moment any work begins — even if it's just research or planning for that specific task.

The architect is building the workflow in HubSpot but it is not yet tested or live.

Blocked

Work cannot continue because of something outside the architect's control — a dependency, missing access, a client decision, or a technical blocker. The architect is not idle; they are stopped.

Use immediately when a blocker appears. Never leave a task as In Progress if it is actually blocked — that hides the real status.

The architect needs admin access to a client's HubSpot but it has not been granted yet.

Waiting on Customer

The task requires input, a decision, or an asset from the client before work can continue or be completed. The ball is explicitly in the client's court.

Use when you have clearly communicated what you need from the client and are now waiting. Include a note on the task with what was asked and when.

The architect sent a Loom asking the client to approve a new lifecycle stage mapping and is waiting for a reply.

Client Review

The work is done from RevGravy's side. The task has been delivered to the client for their review, testing, or sign-off before it can be marked complete.

Use when the architect has shared the deliverable with the client and is waiting for their confirmation — not just acknowledgement.

A new dashboard has been built and shared with the client. They are reviewing the reports before the architect closes the task.

Needs Discussion

The task has an open question or ambiguity that requires a conversation — with the client, with Phil, or between the architect and Manuel — before work can proceed or be finalized.

Use when forward progress requires alignment that hasn't happened yet. Tag the right person in the cycle planner or Slack to unblock it.

The client mentioned two conflicting requirements in the meeting. The architect needs to clarify which takes priority before building.

Next Cycle

This task was in the current cycle plan but will not be completed this cycle. It is explicitly queued for the next cycle. This is different from Blocked — it is a deliberate reprioritization, not a stoppage.

Use when capacity ran out, scope changed, or the task is lower priority than newly surfaced work. Always add a note explaining why it moved to next cycle.

The architect completed the three priority items but didn't get to the reporting task — it is moved to Next Cycle rather than left as In Progress.

Completed

The task is fully done. The deliverable exists in the client's HubSpot (or other tool), has been communicated to the client, and requires no further action from either side.

Only mark Completed when there is nothing left to do on this task. If it still needs client confirmation, use Client Review instead.

The workflow is live in HubSpot, the architect sent a Loom walkthrough, and the client confirmed they can see it working.

Status flow — how tasks typically move

Most tasks follow this path through a cycle:

 

Not Started  →  In Progress  →  Client Review  →  Completed

Tasks that get stuck branch off the main path:

  • Blocked
  • Waiting on Customer
  • Needs Discussion
  • Next Cycle

Never leave a task as In Progress if it is actually Blocked or Waiting on Customer. Those two statuses exist specifically to communicate why progress stopped — hiding that information behind In Progress makes the planner misleading for clients and the team.

 

Naming convention

Format

[Client Name] — [Start Date] to [End Date] - 2-Week Cycle Planner  

Example: ANLS - March 26th to April 9th - 2-Week Cycle Planner

 

Client-facing standard

Phil's decision

Cycle planners ARE shared with clients. This was confirmed by Phil in March 2026. The cycle planner is not a RevGravy-internal document — it is a shared plan between RevGravy and the client. Clients use it to track what's being done, add to-dos on their side, and reference it between meetings.

 

How architects currently create cycle planners

Method

When to use

Auto-draft (Make.com automation)

For all clients with Fellow.ai enabled. Fires automatically after each meeting. Architect reviews and finalizes within ~10 minutes.

Manual creation

For Vannoppen, Nuance Medical, or any other future customer with no-AI policies (no Fellow). Also used as fallback if automation fails. Copy the previous planner, update the Definition of Done and task table. You can find the Project Planner link on the Company Record. 

 

HubSpot project required fields

Field

Why it matters

Project Type

Must be set to 'Cycle' for cycle planner projects. Distinguishes from ad-hoc requests.

Cycle Start Date

When the 2-week cycle begins. Used for on-time rate tracking in the Ops Dashboard.

Cycle End Date (Planned)

The agreed 2-week end date. Used to calculate whether delivery was on time.

Cycle Planner URL

Link to the Google Doc. Used by the recap automation to include the planner link automatically.