Everything that needs a decision, in one list your team can empty
/inbox gathers all of it into one list, opens every card with the ending it is asking for, and empties as your team takes them.- Trigger
- Inbox
- Lands in
- Dashboard, with anything you file landing in Slack
- Setup
- 1 min
- Needs
- Nothing else
Sent from the inbox: the pricing page has failed 14 probes
Shared for a second opinion, still waiting on a decision
- Down
- 38 minutes
- First failure
- 02:14
- Other pages
- Answering
Telling the channel is not deciding, so a shared card stays in the queue until somebody gives it an ending.
Five sweeps, one list
Nothing here is entered by hand. Each queue is read from a power your workspace already runs, so the inbox fills the moment those are connected and empties the moment your team works it.
Every card proposes one ending
The same two buttons on every row would ask you to translate a person who has waited two days into an issue or a task. Instead the list groups by what a thing actually is, and each card promotes the first ending its kind is offered, with the rest behind the chevron beside it.
Somebody got in touch and nobody has come back to them or claimed them. Answering is what takes them off this list. Endings, best first: Reply, Move it on, Hand over, Set a date, Move to another stream, Make it a task, Send to Slack, Pin to the board.
A follow-up your team accepted and then missed. Answer it, or move the date and hold the team to the new one. Endings, best first: Reply, Set a date, Move it on, Hand over, Move to another stream, Make it a task, Send to Slack, Pin to the board.
Tasks the team took on and has run past. Move the date, finish them or drop them, and whichever you pick is a change to the task itself rather than to this list. Endings, best first: Move the date, Mark it done, Hand it to someone, Drop it, Send to Slack. This kind cannot be dismissed.
An account Viably was reading has stopped answering, usually because its permission lapsed or was replaced. Nothing is collected until somebody reconnects it, and no platform serves the days back afterwards. Endings, best first: Make it a task, Send to Slack, Pin to the board. This kind cannot be dismissed.
Something you run answers wrong: a dead link, a redirect chain, markup Google rejects, an endpoint that is down. If Viably is authorized on the GitHub repository, it can create a pull request to fix the issue automatically. Endings, best first: Draft a fix, File as issue, Make it a task, Pin to the board, Send to Slack.
Nothing here is broken and nobody made a mistake. These are pages earning less than they should, searches whose result is not being clicked, and accounts that have stopped publishing. The work is writing or building something rather than fixing it. Endings, best first: Make it a task, Pin to the board, File as issue, Send to Slack.
News rather than work. Put it in front of the team or let it go, and either way nobody has to fix anything. Endings, best first: Pin to the board, Make it a task, Send to Slack, File as issue.
Two axes: which queue, and what state
One list for the whole company is workable and wrong for anybody whose job is not the website. The rail narrows on a single axis: everything, what is yours, one system, or one department. Whatever you pick is remembered, so a bare link to /inbox opens on the list you work.
Mine means the properties, contacts and tasks you own, plus everything nobody has claimed yet, since work without an owner is the work most likely to be dropped. The figure beside each entry counts the rows you would get if you clicked it, within the state you are already in, so the rail and the list can never disagree. Beside the queue runs the state of a decision:
Saying no, and taking it back
Most of triage is declining things, and a queue that re-proposes what your team already declined is one they stop opening. Every decision here is durable, carries the reason somebody gave, and can be undone from the archive.
The reasons offered depend on what you are declining. A broken page can be intentional, somebody else's, or not worth the work. A person can be handled elsewhere or not a fit, in your own stream's word for a relationship that ended. A search phrase can bring the wrong traffic.
Snoozing stores a threshold rather than a day. The item sleeps until the clicks, the money or the wait behind it grows by 50%, so something that never gets worse never interrupts you again.
Dismissing a defect as fixed holds it for 14 days and then tests the claim against what the crawl is still reporting. A fix that never shipped, or that fixed the wrong thing, is somebody's problem again this month rather than filed forever.
Dismissed items keep their reason and can be put back at any time, which is what makes declining freely the right way to work the list. Where things went lists everything that became an issue, a task, a pin or a pull request, with a link to where it landed.
Only your decisions. The cards are worked out on every read from the crawl, the contacts queues, the task board, the social accounts and the uptime probes, so there is no second store to sync and nothing to go stale. What Viably writes down is that you dismissed something, snoozed it, or filed it, and where it went.
Two reasons, and both are deliberate. A snoozed item returns once the number behind it grows by half. And one dismissal reason, saying a defect is already fixed, is a claim about the next crawl rather than a decision to live with it, so Viably tests that claim a fortnight later and brings the item back if the crawl still reports it.
Yes. Cards that share an explanation are drawn as a run under one heading, and a decision can be taken on the run rather than on each card. It applies to the siblings that arrive later too, which is what stops one recurring finding asking the same question every week.
Its items stop appearing, because they were only ever derived from what that power collects. Endings behave the same way: the buttons on a card are filtered by the powers your workspace actually has, so a card never offers to open a pull request in a repository Viably cannot reach.
Yes. The inbox belongs to the workspace rather than to a person, and every decision carries who took it and when, so a dismissed item reads as a colleague's judgement rather than as something that quietly vanished. What is personal is the queue you work, which is remembered per browser.
You decide in the dashboard and the results land in Slack. Any card can be posted into a channel with a note when it needs somebody else's eyes, and the tasks, issues, pins and pull requests that come out of triage arrive in the channels those powers already write to.
Open /inbox. Whatever your workspace already collects is in there waiting, and the inbox is on the free plan with nothing to configure.