Overview
A workflow playbook for SaaS teams managing project intake work with boards, notes, owners, review cadence, and measurable follow-through. The page maps the operating problem, recommended structure, Kanvly setup, and measurement loop for this long-tail workflow.
The project intake problem for SaaS teams
Nobody struggles with project intake work in the abstract; they struggle at the seams, where one person's "done" becomes another's "to do." That is exactly where SaaS teams feel it, because release context, customer feedback, enablement work, and recurring operations all move at the same time.
A task list cannot carry that weight on its own. The workflow has to show where each piece sits, hold the reasoning behind it, and surface the work that has quietly gone cold.
Recommended workflow stages
A practical first version uses these stages: Submitted, Clarifying, Prioritizing, Approved, Scheduled, Declined. The exact names can change, but each stage should represent a decision or state that the team can recognize quickly.
Avoid creating a stage for every exception. If a state appears only once, it may belong in a card note instead of the permanent workflow.
- Submitted: make the entry and exit rule explicit.
- Clarifying: make the entry and exit rule explicit.
- Prioritizing: make the entry and exit rule explicit.
- Approved: make the entry and exit rule explicit.
- Scheduled: make the entry and exit rule explicit.
- Declined: make the entry and exit rule explicit.
What context belongs beside the work
Intake items should preserve requester context, business reason, urgency, effort hints, approver notes, and the decision that sets expectations.
The workspace needs to preserve product decisions, launch notes, customer-facing follow-up, and internal ownership without creating a separate tracker for every function. Split the context away from the cards and the board degrades into a status display — accurate-looking, but no longer the place anyone goes to actually understand the work.
What this looks like in practice for SaaS teams
Take a realistic snapshot: about 26 project intake workflow items in flight, spread over Submitted, Clarifying, Prioritizing, Approved, Scheduled, Declined. Scale is not what hurts the SaaS group — overloading "Submitted" with work that means different things to different people is.
Run it on a 7-day cycle and the first thing to settle is what "Declined" actually requires before a card is allowed to land there. Because release context, customer feedback, enablement work, and recurring operations all move at the same time, that one definition removes more thrash than any extra field. A 25-minute review that touches blocked, waiting, and stale "Submitted" cards is usually enough to keep release readiness, support handoff quality, customer follow-up completion, and stale launch work moving in the right direction.
Kanvly setup pattern
Let the Kanvly board carry the motion between Submitted and Declined, and let linked notes and pages carry the reasoning — briefs, decisions, playbooks, handoff detail. The rule of thumb: a card you can read in seconds, backed by context you can rely on.
The payoff for SaaS teams is one place to operate from instead of a rollout to manage. Begin with a single live workflow, watch what repeats, and template only that.
Measure the workflow, not only the output
For SaaS teams, the measurement loop should watch release readiness, support handoff quality, customer follow-up completion, and stale launch work.
Health shows up as quieter coordination: fewer "what's the status?" pings, fewer ownerless cards, and decisions that are still findable once a card has moved past Declined.
- Lock the stage definitions first; decorate the cards second.
- Give every active card an owner, next action, and due date where appropriate.
- Link decisions and briefs to the work they affect.
- Run a short, predictable pass over blocked, waiting, and aging "Submitted" cards.
- Capture learning before archiving completed work.