The Complete Guide to Ticket Tags, Custom Fields, and Views

A helpdesk with a hundred open tickets and no way to organise them is just a fancy inbox. The power of a ticketing system comes from its ability to classify, filter, and surface the right information at the right time. Tags, custom fields, and views are the three tools that make this possible—and if you're currently drowning in a flat list of unsorted tickets, they're about to become your best friends.

Used well, they turn chaos into structure. Agents find what they need instantly. Managers spot patterns. Automations route work without human guesswork. Used poorly, you end up with a tangled mess of overlapping labels that no one understands—a problem Deloitte's Global Contact Center Survey identifies repeatedly: poor data hygiene is one of the top barriers to better reporting and smarter support operations.

This guide covers how to design and maintain all three so they actually help rather than hinder your support operation.

Tags: flexible labels for anything

Tags are the simplest organisational tool in a helpdesk. They are freeform labels you attach to tickets to mark them with additional context that the standard fields don't cover. Think of them as post-it notes you can apply to every ticket without changing the ticket's core structure.

What tags are good for

Tags excel at capturing ad hoc or cross-cutting information. They're useful when:

• Tracking trends — If you notice a spike in complaints about a specific feature, tag those tickets to quantify the trend later and build a case for fixes
• Flagging for follow-up — Tags like "needs-manager-review" or "escalate-to-billing" route tickets without changing the formal workflow
• Categorising by topic — Tags like "billing," "onboarding," "bug-report," or "integration" help you analyse what customers are actually contacting you about
• Supporting automations — Many automation rules use tags as triggers. A tag of "vip-customer" might route a ticket to your most experienced agent automatically (we'll cover this more in our guide to helpdesk automation)

Common mistakes with tags

The biggest problem is proliferation. Because tags are freeform, teams end up with dozens or hundreds of them, many overlapping or misspelled. "Refund," "refunds," "refund-request," and "refund_request" coexist in the same system, making reporting unreliable and leaving agents wondering if they're using the right tag.

To prevent this:

• Establish a naming convention — Use lowercase, hyphen-separated tags. Decide on singular vs plural and stick to it
• Maintain a tag dictionary — Document every approved tag with its definition and when to use it. Yes, this sounds like overhead. It saves far more overhead later
• Restrict tag creation — If your helpdesk allows it, limit who can create new tags. Agents apply existing tags but may need approval to add new ones
• Audit regularly — Review your tag list quarterly. Merge duplicates, retire unused tags, and update the dictionary

Tag architecture patterns

A useful pattern is to use tag prefixes to create informal categories:

• product-accounting, product-crm, product-bookings — Which product the ticket relates to
• issue-bug, issue-feature-request, issue-how-to — The nature of the request
• status-waiting-on-vendor, status-escalated — Workflow markers
• source-email, source-phone, source-chat — How the ticket arrived (if not captured automatically)

This prefix approach makes tags self-documenting and easier to search. Anyone new to the team can look at a ticket tagged product-crm and issue-bug and immediately understand the context.

Custom fields: structured data for every ticket

While tags are flexible labels, custom fields are structured data points you add to your ticket form. They have defined types—dropdown menus, text fields, checkboxes, date pickers—and they capture specific information consistently.

When to use custom fields instead of tags

The rule of thumb is straightforward: if the information is consistently needed and has a finite set of possible values, use a custom field. If it's occasional or unpredictable, use a tag.

Custom field examples:

• Product area (dropdown): Accounting, CRM, Bookings, Timesheets
• Issue type (dropdown): Bug, Feature Request, How-To, Billing Query
• Order number (text field): Freeform entry for the customer
• Contract renewal date (date picker): When the customer's contract expires
• Number of affected users (number field): How many people this impacts
• Environment (dropdown): Production, Staging, Development

Designing effective custom fields

Keep the list short. Every custom field you add is a field someone has to fill in. If agents need to complete ten custom fields on every ticket, they'll rush through them or skip them. Limit required fields to the essentials—typically three to five. "Mandatory" fields are only mandatory if you actually need the answer before the agent can work.

Use dropdowns over free text wherever possible. Free text is harder to report on because the same information gets entered differently. If the answer is one of a known set of options, make it a dropdown. (An agent will write "URGENT," "urgent," "Urgent," and "!URGENT!" before they'll pick from a list, but the list forces consistency.)

Separate customer-facing and agent-facing fields. Some fields should be filled in by the customer when they submit a ticket (like order number or product area). Others should be filled in by the agent during triage (like priority or issue type). Your helpdesk should let you control which fields appear on the customer form versus the agent interface. Only ask customers for information you actually need—the ICO's data minimisation principle applies to ticket forms just as much as to marketing forms.

Make conditional fields. Not every field is relevant to every ticket. If you have a "product area" dropdown, additional fields specific to that product should only appear when the relevant product is selected. This keeps the form uncluttered and avoids confusion. No one needs to see a "storage size" field when they're filing a billing question.

Custom fields and reporting

The real power of custom fields shows up in reporting. Because the data is structured, you can build reports that answer questions like:

• What percentage of tickets are bug reports versus feature requests?
• Which product area generates the most support volume?
• What is the average resolution time for billing queries versus technical issues?
• Are tickets from enterprise customers resolved faster than those from free-tier users?

None of these questions can be reliably answered with tags alone. Tags lack the structure needed for consistent aggregation. If you want to build a custom support report that actually tells you something meaningful, custom fields are your foundation.

Views: your window into the queue

Views are saved filters that show agents a subset of tickets based on defined criteria. Instead of looking at every open ticket in the system, an agent works from a view that shows only the tickets assigned to them, or only urgent ones, or only tickets tagged with a specific product.

Essential views every team needs

My open tickets — Tickets assigned to the current agent that are not yet resolved. This is the default working view for most agents. Every agent should have this built-in.

Unassigned tickets — Open tickets that have not been picked up by anyone. This is the triage queue where new tickets land. Someone is watching this all day.

Urgent and high priority — All open tickets at P1 or P2 priority, regardless of assignment. This gives managers and senior agents visibility into critical issues. If you're not prioritising your tickets yet, our guide to ticket prioritisation walks you through building a priority scheme that actually works.

Pending customer reply — Tickets where the team has responded and is waiting for the customer. These should not clutter the main working view—they're on pause until the customer replies.

Approaching SLA breach — Tickets within a defined percentage of their SLA deadline (typically 80–90%). This is an early warning system that helps prevent breaches before they happen.

By product area — Separate views for each product or team, showing only relevant tickets. If you support three products, you might have three separate product views plus the global views above.

Building effective views

Views are defined by filter criteria. Common parameters include:

• Status — Open, pending, on hold, solved, closed
• Priority — Urgent, high, normal, low
• Assignee — A specific agent, a group, or unassigned
• Tags — Any combination of tags
• Custom fields — Values from your structured fields
• Channel — Email, chat, phone, social media
• Created date — Tickets from the last 24 hours, last week, etc.
• SLA status — Within target, at risk, breached

Most views combine multiple criteria. For example, a view for the billing team might filter on: status is open, product area is "billing," and assignee group is "billing-team."

View hierarchy and access

Not everyone needs to see every view. Structure your views in tiers:

• Global views — Available to all agents (unassigned tickets, SLA warnings)
• Team views — Available to members of specific groups (billing team queue, technical support queue)
• Personal views — Created by individual agents for their own workflow preferences

Allow agents to create personal views, but maintain the global and team views centrally so the team has a consistent foundation. This balances flexibility with standardisation.

How they connect: tags, custom fields, and views as a system

Tags, custom fields, and views don't work in isolation—they work as a system. Custom fields provide the structured data. Tags add flexible context. Views use both to surface the right tickets to the right people.

Here is how they connect in a typical workflow:

1. A customer submits a ticket and fills in custom fields (product area, order number)
2. An automation rule reads the custom fields and applies tags (e.g., if product area is "billing," add the tag "billing")
3. The automation also assigns the ticket to the appropriate group based on the custom field value
4. The ticket appears in the billing team's view because it matches their filter criteria
5. An agent picks up the ticket, adds additional tags during investigation ("refund-processed"), and updates custom fields as needed
6. Managers use views filtered by tags and custom fields to generate real-time dashboards and spot trends

Platforms like Relentify Helpdesk support this full workflow with custom field types, tag management, and configurable views that update in real time as tickets move through your pipeline.

Maintenance and governance

An organisational system is only as good as its maintenance. Without regular care, tags multiply, custom fields become outdated, and views stop reflecting how the team actually works. Here's what to do:

Monthly: Review tag usage reports. Merge or retire tags with fewer than five uses in the last 90 days. Check for near-duplicate tags and fix them.

Quarterly: Audit custom fields. Are all required fields actually being filled in? Are any fields consistently left blank? Adjust or remove fields that are not adding value.

When processes change: Update views to reflect new team structures, product areas, or SLA targets. A view that no longer matches reality is worse than no view at all because it gives a false sense of organisation.

Document everything: Maintain a support operations handbook that lists every tag, custom field, and view along with its purpose, owner, and creation date. When someone asks "what does this tag mean?" there should be a clear answer.

Frequently Asked Questions

Q: How many custom fields should we have? A: Start with three to five required fields. Add more only if you're consistently asking for the same information. Every extra field slows down ticket creation and reduces completion rates. You can always add more later; it's harder to remove them once agents are using them.

Q: Should we use tags or custom fields for priority? A: Use a custom field for priority, not a tag. Priority is core information that every ticket has and needs to be set consistently. Many helpdesks have a dedicated priority field built-in for this reason.

Q: What's the difference between a tag and a view? A: Tags describe a ticket. Views are ways to look at tickets. A tag is a label you apply; a view is a saved filter. You might tag a ticket "escalated," and then create a view that shows all escalated tickets. They're complementary tools.

Q: Can we automate tag application? A: Yes—most modern helpdesks support automation rules that apply tags based on ticket properties. If a customer has a "vip" custom field set to true, you can automatically apply the "vip-customer" tag. This reduces manual tagging and makes your system more reliable. See our guide to helpdesk automation for more detail.

Q: How do we prevent tag chaos? A: Establish a naming convention (lowercase, hyphens), maintain a documented tag list, and audit quarterly. Restrict who can create tags—agents apply existing ones but need approval to add new ones. This is overhead in the moment but prevents a naming mess later.

Q: What if a ticket doesn't fit our custom field options? A: That's what tags are for. Custom fields capture structured, predictable data. Tags capture the exceptions and edge cases. If you find the same exception appearing repeatedly, consider adding a new custom field option or even a new field.

Q: How often should we update our views? A: Review your views whenever your team structure or support process changes. At minimum, audit them quarterly. A view that no longer reflects reality is confusing and wastes time.

Q: Should customers see custom fields in their ticket view? A: Generally no. Show customers the ticket status, priority, and any updates from your team. Hide internal custom fields like "assigned-to," "environment," or "source-tracking-id." Customers don't need to see your internal metadata.

The payoff

Investing time in your ticket organisation system pays dividends across every area of support. Agents find the right tickets faster. Automations route work more accurately. Real-time dashboards tell a clearer story. And customers get better service because the team behind the scenes is working from a well-organised system rather than a chaotic queue.

The work is not glamorous, but it is foundational. Get your tags, custom fields, and views right, and everything else in your support operation becomes easier. You'll also find it far easier to train new team members when the system is documented and consistent.

Ready to bring order to your ticket queue? Relentify Helpdesk gives you custom fields, unlimited tags, and flexible views so you can build exactly the system your team needs. Try it free for 14 days.