What is a ticketing system?

What information does a ticket contain?

A ticket contains the request, its conversation history, a status and an owner, with enough context to decide the next step. Additional fields help only when people use them to make a decision or find related work.

Imagine a fictional bicycle repair shop. A customer emails that a replacement wheel still rubs against the brake. The useful record includes which repair they mean, what they observe, any photographs, who is investigating and what happens next. A subject line alone cannot explain whether the customer is waiting for a reply or the shop is waiting for a photograph.

Common ticket fields include:

• Requester: the person asking for help and how to reach them.
• Subject and description: the problem in terms someone else can understand.
• Owner: the person accountable for moving the request forward.
• Status: whether work is active, waiting or resolved.
• Priority: the relative urgency, using agreed criteria.
• History: messages, internal notes and changes to the record.

Keep internal discussion distinct from replies the requester can read. A private note saying "ask the mechanic whether the fitting was checked" serves a different purpose from an email asking the customer to bring the bicycle back.

How does a request move through a ticketing system?

A request arrives, becomes a ticket, gets an owner, moves through investigation or waiting states and reaches a resolution. The names of those states and the rules for reopening vary by product.

The repair shop can start with a simple illustrative lifecycle:

Step	What happens	What the owner must know
Receive	An email or form records a new problem	Whether a related case already exists
Assign	One person takes responsibility	Who will provide the next update
Investigate	The team checks the repair history	What evidence is still missing
Wait	A customer or supplier needs to respond	Who is being waited on and when to follow up
Resolve	A repair or explanation addresses the problem	Whether the outcome is recorded clearly

For a concrete product example, Zendesk documents six standard statuses: New, Open, Pending, On-hold, Solved and Closed. Pending means waiting for the requester; On-hold means waiting for another party. Closed is a system-managed final state. Those meanings belong to Zendesk, not to every support product.

An owner should still know what to do when a state changes. "Waiting" without a named dependency and a follow-up date can become a place where requests disappear.

How is ticketing different from a shared inbox?

A shared inbox lets people work on the same conversations, while ticketing emphasizes a case's progress and resolution. The categories overlap: a shared inbox with owners and statuses can provide the tracking a small support team needs.

Google's Collaborative Inbox documentation describes assigning conversations and marking them complete, needing no further action or as duplicates. That is a useful example of basic request tracking without a separate, elaborate help-desk process.

Requirement	Ordinary mailbox	Shared inbox with tracking	More structured ticketing
Read and reply	Yes	Yes	Yes
Know who owns the next step	Often handled manually	Assignment	Assignment and potentially routing
Distinguish waiting from finished	Labels or folders	Conversation states	Defined ticket lifecycle
Handle specialized service rules	Manual process	Depends on product	May offer queues, targets and escalation

A ticketing system does not automatically provide phone support, service-level agreements or advanced routing. Check those capabilities separately when they matter. The shared-inbox explanation covers the lighter approach in more detail.

When does a business need ticketing?

A business needs clearer request tracking when handoffs, repeated contacts or unclear responsibility cause missed work. There is no universal ticket-volume threshold that makes a system necessary.

For the bicycle shop, the warning sign might be a customer phoning after three emails that nobody owns. Another sign is the mechanic answering from a personal mailbox while a colleague sends a contradictory reply from the shop address.

Start by writing down who owns each open request and what it is waiting for. If that simple discipline solves the problem, a small shared inbox may be sufficient. More specialized software becomes useful when different teams need different queues, response targets or reports that a manual process cannot maintain reliably.

Which ticketing measurements are useful?

Useful measurements show whether people receive a timely answer and whether the underlying problem gets resolved. Count unresolved work and repeated contacts alongside response speed.

For a first review, look at the oldest open requests, the time until a meaningful first reply, the number waiting for a customer and the number reopened after an apparent solution. State whether response-time calculations use working hours or elapsed hours. A weekend changes the interpretation.

Fast closure alone can reward the wrong behavior. If the shop closes a case after sending a generic instruction and the customer returns with the same fault, the shorter resolution time does not show better service. Read a sample of the actual conversations before setting a target.

How does Mojobase track support requests?

Mojobase Support, inside Customers, tracks conversations with one assignee and Open, Waiting or Closed states. A shared support address uses hosted business email on your domain or a connected Gmail or Outlook mailbox. The conversation stays with its customer context.

The AI drafts answers from published Handbook pages and replies directly only for topics set to Auto. Uncertainty goes to a person, and replies appear in Activity. Mojobase does not offer phone or SMS support, SLA policies or advanced routing rules. Choose a specialist when those are essential; the Freshdesk alternatives guide and support workflow show the trade-offs.

Compare Tidio alternatives and the small-business help-desk shortlist when choosing a support queue.