Look at your board right now. There's a card that says "[3pts] Login timeout on staging — P1". The story points are in brackets. The environment is a word buried mid-title. The severity is a label that half the team forgot to add. That title is doing the job of a spreadsheet, badly.
This is what happens when a Kanban board only knows two facts about a card: which column it's in, and who owns it. Status and assignee are enough for a to-do list. They are not enough to run a sprint. The moment your team needs to sort by story points, filter to a specific environment, or triage by severity, that information has to live somewhere — and if the tool won't hold it, your team invents workarounds. Prefixed titles. Color-coded labels that mean different things to different people. A separate tracking sheet that goes stale by Wednesday.
Why the title-and-label hack breaks
The workarounds feel fine at first. Then they don't.
- Titles aren't queryable. You can't sort a board by a number that's wrapped in brackets inside free text. "Show me every card over 5 points" becomes a manual scan.
- Labels don't hold values. A label is a boolean — it's either on the card or it isn't. "Severity" isn't a boolean. It's a scale. Cramming sev-1, sev-2, and sev-3 into three separate labels means three ways to forget one, and no way to enforce that exactly one is set.
- Free text drifts. One person writes "staging," another writes "stg," a third writes "STG env." Now you can't filter reliably, because the data was never structured to begin with.
The fix isn't discipline. You will not out-discipline a data model that doesn't exist. The fix is giving the card real fields.
What "first-class card data" actually means
A custom field is a named slot on the card with a defined type. Zoobbe cards support four types, and each one solves a different version of the problem above:
- Number — story points, estimate hours, T-shirt-size-as-integer. Now "points" is a real value you can read at a glance and reason about, not a substring.
- Single-select — environment (dev / staging / production), severity (sev-1 / sev-2 / sev-3), work type (bug / feature / chore). One choice, from a fixed list. No drift, no typos, no "is it staging or stg."
- Date — code-freeze date, target release, when QA signed off. Distinct from the card's due date, which usually means something else.
- Text — a PR link, a Sentry issue ID, an affected version string. The stuff that's genuinely freeform.
The key shift: severity stops being a label you hope someone remembers, and becomes a slot the card expects you to fill. Environment stops being a title prefix and becomes a single-select you can't misspell.
A worked example: modeling a bug card for an eng team
Say you run a squad of six and you've been drowning in the login-timeout kind of card. Here's the card model that replaces the title hack:
| Field | Type | Example value |
|---|---|---|
| Story points | Number | 3 |
| Environment | Single-select | Staging |
| Severity | Single-select | Sev-2 |
| PR link | Text | github.com/…/pull/482 |
| Target release | Date | 2026-08-04 |
Now the title is just "Login timeout on staging." Readable. The structured facts sit in the fields where they belong. A note for eng leads specifically: Zoobbe already ships a native priority on every card (Normal, High, Low, Urgent), so you don't need a custom field for that. Keep priority for "how soon" and a custom severity select for "how bad" — they're different axes, and conflating them is how a cosmetic sev-3 ends up marked Urgent because it was the only knob available.
Where this pays off in a sprint
Structured fields aren't just tidier. They change what the board can tell you.
- Sprint planning. Points as a real number means you're reading estimates off the cards instead of decoding titles. When capacity is the whole conversation, the data being in a proper field is the difference between planning and archaeology.
- Triage. A single-select severity that's required in your team's convention means no bug slips through unclassified. You know at a glance whether the staging card is a sev-1 fire or a sev-3 someday.
- Handoffs. The PR link and target-release date live on the card, not in a Slack thread three people can find and three can't.
And because Zoobbe's automations read card state, structured fields become triggers you can act on. A rule can watch for a priority change, move a card, assign a member, or drop a comment. Fields give automations something reliable to key off — you can't automate against a number hidden in a title.
The Trello comparison, honestly
Plenty of teams reach for Trello first, and Trello can do custom fields. The catch worth knowing before you commit: in Trello, custom fields are a Power-Up gated behind a paid plan. You're adding an add-on, and on the free tier you're back to stuffing story points into the title.
In Zoobbe, custom fields are built into every board's cards — no Power-Up to enable, no Premium tier to unlock a number field. They sit alongside native Kanban, automations, and per-card time tracking in the same product. That's the real tradeoff: with Trello you assemble the workflow from parts, some of them paid; with Zoobbe the card is already a structured object out of the box. Trello is a genuinely good board. This is simply a different bet about what belongs in the core versus behind a paywall.
If your team has ever argued about whether a bug is "staging" or "stg," you don't have a discipline problem. You have a missing field.
Getting started without over-engineering it
You do not need twelve fields on day one. That's just a spreadsheet wearing a Kanban costume. Start with the two that hurt most — for most eng teams that's story points (number) and severity (single-select). Add environment when a cross-env bug bites you. Add a target-release date when a handoff drops. Let the fields earn their place by solving an actual recurring annoyance, and delete any that the team stops filling in.
FAQ
What field types do Zoobbe custom fields support?
Four: text, number, date, and single-select. Story points map to number, environment and severity to single-select, target dates to date, and links or IDs to text.
Is severity the same as a card's priority?
No, and it's worth keeping them separate. Zoobbe cards have a native priority (Normal, High, Low, Urgent) for "how urgent." Model severity as its own single-select custom field for "how bad" — the two axes answer different questions.
Do custom fields cost extra on Zoobbe?
No. They're part of every board's cards. That's the main difference from Trello, where custom fields are a Power-Up on a paid plan.
Can automations use custom field data?
Zoobbe automations run on triggers like card moved, priority changed, or a due date approaching, and can move cards, assign members, set priority, or add comments. Structuring your data in fields gives those rules something reliable to work with.
How many custom fields should a card have?
As few as solve a real, recurring problem. Start with the one or two facts you keep cramming into titles, and add more only when a specific handoff or planning gap forces it.
The board that dies is the one still pretending a card is just a title and a column. Give the card the fields your work actually has, and planning stops being detective work. See how Zoobbe models it.