How an issue actually gets resolved.
Problems reach the person who can fix them, and it’s all on the record.
Staging deploys have needed a manual DB migration for three weeks
Nobody owns the migration step, so every release picks up an hour of hand-holding. Raised twice in standup, never ticketed.
Card-based triage
Nothing sits in a backlog. You see one issue at a time and act on it.
Your queue is a stack of cards, not a table with forty rows and a filter bar. The top card is the only thing asking for a decision, and there are three decisions available: resolve it, reject it, or escalate it to your manager.
Every card leaves your queue the moment you choose. The stack shrinks, the next issue surfaces, and the choice you made is written to the record automatically.
[NEEDS PRODUCT INPUT] Where a rejected issue goes — back to the person who raised it, or closed outright — is not settled in the codebase. Copy here avoids claiming either.
One tap moved the issue from Dan’s queue to his manager’s — not to a channel.
Escalation that follows your real org chart
One tap sends it to your actual manager, as your organisation defines them.
Escalating is not a vague “can you loop in your manager” message. Each membership carries a manager, so Raise already knows exactly one person the issue should go to next, and it lands in their queue as a card like any other.
Because the route is structural rather than social, the awkwardness disappears. Nobody has to decide who to bother.
[NEEDS PRODUCT INPUT] What happens when an issue reaches someone with no manager above them — the top of the chain — is not defined yet.
Full audit trail on every handoff
Always answerable: who knew about this, and when.
Every resolve, reject, escalate and reassign writes a transfer record — from whom, to whom, which action, the note, the timestamp. You do not opt in and you cannot forget to log it, because the log is how the issue moves.
Six months later the trail still answers the question that matters after something goes wrong: was this raised, and where did it stop.
- RaisedDan Osei12 Aug · 09:14
"Third release in a row that needed the migration run by hand."
- EscalatedDan Osei → Marcus Vale16 Aug · 11:02
"Needs a decision on owning the migration step. Above me."
- ReassignedMarcus Vale → Ana Ruiz16 Aug · 15:40
"Ana owns release tooling — handing this to her with my sign-off."
- ResolvedAna Ruiz21 Aug · 10:27
"Migration folded into the deploy job. Runbook updated."
The three things that keep the loop honest.
Triage, routing and the record are the product. These make sure the structure behind them stays true.
Org structure & manager approvals
The chart that drives escalation stays accurate because changes to it are approved.
New members join as pending and reporting-line changes need a manager’s approval. Each membership holds its own role, title and level, so escalation always has a defined next step.
Analytics on bottlenecks
Surface the bottleneck, not just the backlog count.
See where issues stall, how long resolution actually takes, and who is accumulating unresolved items. A backlog number tells you there is a problem; this tells you where it is.
Finance is where issues sit. That is a staffing conversation, not a backlog one.
One login, many organizations
One account, separate roles, separate reporting lines.
A single account can belong to several organizations, each with its own role, title and manager. Contractors, board members and anyone working across two companies switch context without a second login — and without one org’s structure leaking into another’s.
Start with one team and one queue.
Raise an issue, assign an owner, escalate when it stalls. The trail writes itself.
Free while we are in early access. No card required.