> ## Documentation Index
> Fetch the complete documentation index at: https://sleekplan.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Categories vs. tags vs. statuses
> Statuses, categories, and tags each organize feedback in a different way. Learn what each is for, how to decide which axis becomes your category, and see real setups for single-product SaaS, multi-product companies, agencies, game studios, and more.
Sleekplan gives you three ways to organize posts: **statuses**, **categories**, and **tags**. They are not competing options. Each answers a different question, and most teams use all three at once. Getting the split right keeps your board readable for the people submitting feedback and powerful for your team behind the scenes.
## The three at a glance
| | Status | Category | Tag (Label) |
| --------------------- | -------------------------------------------- | ------------------------------------------- | ----------------------------------------- |
| **Answers** | Where is this in our workflow? | What kind or area is this? | Any other angle we track |
| **Per post** | One | One | Many |
| **Who sees it** | Users and your team | Users and your team | Your team by default (can be made public) |
| **Changes over time** | Yes, it moves through stages | Rarely | Rarely |
| **Mainly powers** | The [roadmap](/help/roadmap) and progress | The public board filter and the submit form | Internal filtering and triage |
| **Examples** | Under Review, Planned, In Progress, Complete | Feature / Bug, or Web app / iOS app | Enterprise, Quick win, Q3, Design-team |
## Status: where a post is
A [status](/help/feedback/statuses) tracks a post through your workflow and is the one attribute that changes as work moves forward: Under Review, then Planned, then In Progress, then Complete. Each post has exactly one status, users can see it, and the statuses you enable for the roadmap become its [columns](/help/roadmap#status-view).
Status is the "when / how far along" axis. Keep it as a set of stages that move in one direction. Resist the temptation to bend a status into a kind or an area, that is what categories and tags are for.
## Category: the one axis your users see
A [category](/help/feedback/categories) is the primary way you group posts, and the only grouping your users see and pick from when they submit. A post has exactly one category, it shows publicly, and it is a short dropdown, so keep the list tight.
Because it is the single user-facing axis, the important decision is **what the category axis represents**. Two patterns cover most teams:
* **Kind of feedback:** Feature, Bug, Improvement. The default, and a great fit when you have one product.
* **Product or area:** Web app, iOS app, Android, API, Billing. The better fit when you have several products or platforms and people need to find their corner first.
Pick the axis your users would most naturally sort by when they browse or file feedback.
## Tags: every other axis, for your team
A [tag](/help/feedback/tags) (shown as a **Label** on a post) is a flexible marker. Posts can have many, and by default they are internal, there to help your team slice and triage. Whatever your category axis is **not**, tags can be. When you want to, you can also [make tags public](/help/portal-widget/public-tags) so users apply them when posting and filter the board by them.
## The trick: category takes one axis, tags take the rest
This is the whole game. A post gets **one** category but **many** tags, so the category claims your single most important axis and tags carry everything else. That means categories and tags naturally trade places depending on how you set up your category:
| If your category is… | Categories look like | And tags carry |
| -------------------- | ------------------------- | ----------------------------------------- |
| **Kind of feedback** | Feature, Bug, Improvement | Web app, iOS, Enterprise, Quick win |
| **Product or area** | Web app, iOS app, API | Bug, Feature, Improvement, Enterprise, Q3 |
Notice how the "kind" and "product" axes swap between the category column and the tag column. Decide which one your users care about most, make that the category, and push the other onto tags.
## Setups by team
A few ways real teams split the three. Status is always your workflow, so only the category and tag choices change.
**Category:** Feature, Bug, Improvement. **Tags:** Mobile, Enterprise, Quick win, plus an effort marker. The classic starting point.
**Category:** Web app, iOS app, Android, API, Billing. **Tags:** Bug, Feature, Improvement, plus customer tier. Users pick their product first; the kind moves to tags.
**Category:** one per client (Acme, Globex). **Tags:** kind of work, priority, and whether it is in-retainer.
**Category:** the area that owns it (Dashboard, Checkout, Notifications). **Tags:** kind and the sprint or quarter.
**Category:** Gameplay, Graphics, Multiplayer, Economy. **Tags:** platform (PC, PS5, Xbox, Switch) and severity.
**Category:** product line. **Tags:** Firmware, Hardware, or Companion app, so one board covers the whole stack.
## Rules of thumb
* **Your primary user-facing axis is the category.** It is the grouping users always see and choose. Pick what helps them browse and submit; move everything else to tags.
* **Keep categories short, let tags grow.** Categories are a dropdown people pick from, so aim for a handful. Tags are internal by default and can be as many as you need.
* **Statuses are always progress.** If an attribute changes as work advances, it is a status. If it describes what a post *is*, it is a category or a tag.
* **Make the primary axis a category, secondary axes tags.** The category is always public. Tags stay internal by default, but you can [expose them](/help/portal-widget/public-tags) as a second public axis when it helps users filter.
* **You can evolve.** Many teams start with category as the kind of feedback, then switch it to product when they launch a second app and move the kind to tags. Re-tagging existing posts takes a little cleanup, so it is worth deciding early.
## Related
Manage the stages a post moves through.
Set up your one user-facing grouping.
Create the internal labels that cover every other axis.
Slice the board by any status, category, or tag.