← Help & Documentation

What StatusLoop is for

The problem it solves, who it suits, and where it deliberately stops.

StatusLoop exists for one job: collecting honest status from the people who own the work, and turning it into a view a leader can act on — without anyone spending a day a week assembling it.

The problem

Most organizations already have a status process. It usually looks like this: someone sends a reminder, a handful of people reply, the rest are chased individually, and the results are pasted into a deck the night before a review. By the time anyone reads it, some of it is a week old and most of it is green.

The failure is not that people are lazy. It is that the cost of reporting falls on the people doing the work, while the benefit lands somewhere they never see. StatusLoop tries to shrink that cost to a few minutes and make the benefit visible to everyone.

How it works, briefly

  1. Your work is organised into spaces, programs and projects.
  2. Each project has an owner.
  3. A cycle asks every owner for a status and a short narrative on a deadline.
  4. People who have not answered get reminded; people who have are left alone.
  5. The portfolio view, the trend lines and the exec deck build themselves from what came in.

Who it suits

Organizations running somewhere between ten and a few hundred projects, where a handful of people are accountable for knowing how it is all going, and where delivery is spread across more teams than any one person can keep in their head.

If you have five projects and talk to everyone daily, you do not need this. A spreadsheet is genuinely fine, and will stay fine for a while.

Where it deliberately stops

StatusLoop is not a work-management tool and does not want to be. It does not replace Jira, Linear, Asana or whatever your teams already use to run their day.

  • No sprint boards, no ticket workflow, no time tracking.
  • No attempt to be the system of record for engineering work.
  • No automated status. A rating is a human statement, because a derived one is wrong in exactly the cases that matter.
  • No finer-grained roles than admin and member. Permission complexity is usually a sign the real problem is elsewhere.

What good looks like after a month

Cycle coverage above ninety percent, narratives that name blockers rather than restate scope, and a leadership review that spends its time on the three red projects rather than on reading out the green ones.

Was this unclear? Tell us — we would rather fix the page than answer the same question twice.