How to Create and Manage Tickets in CrmLeaf
All editions. Core feature - no add-on required. Turning mailboxes into tickets automatically requires the separate Email Ticketing add-on module.
Availability: All editions. Core feature - no add-on required. Turning mailboxes into tickets automatically requires the separate Email Ticketing add-on module.
Overview
Tickets is the support desk inside CrmLeaf. Each ticket records one request or issue raised by a requester, and holds the whole conversation about it in one place. Because a ticket can be linked to a client and to a project, support work sits alongside the commercial and delivery records for the same customer instead of in a separate tool.
This article covers creating a ticket, working it through its statuses, and closing it.
How It Works
A ticket is raised, classified, assigned to an agent, worked through replies, and then resolved and closed. Status is the single indicator of where the ticket stands.
Raise → Classify → Assign → Reply → Resolve → Close
- A ticket carries a type, a group, a channel, a requester and an assigned agent.
- A ticket can optionally be linked to a client record and to a project.
- Tickets move through four statuses: open, pending, resolved and closed.
- Every change is written to the ticket's activity log, so the history of the request is preserved.
- Tags and @mentions bring colleagues and topics into the ticket.
- If round-robin assignment is configured, the agent is chosen automatically instead of manually.
Who Can Use This Feature?
Administrator
- Configure ticket types, groups, channels and agents.
- Set the visibility scope that decides which tickets each role can see.
- Reassign tickets and close them.
User
- Create tickets and record the requester's request.
- Work assigned tickets, add replies and change the status.
- Link a ticket to the related client or project.
Access depends on the modules and role assigned by your Administrator.
Prerequisites
- At least one ticket type, group and channel configured (see How to Configure Ticket Types, Groups and Agents in CrmLeaf).
- At least one user enabled as an agent.
- The client and project records already exist, if you intend to link the ticket to them.
For Users
Step 1: Open the ticket list
What to do: Review the tickets you can see. Use Search and Filter to narrow the list by status or by the classification fields your Administrator has configured.
What to verify: You see the tickets you expect. If the list looks short, your visibility scope may be limited to tickets you own or were added to.
Step 2: Create the ticket
What to do: Select Add and complete the ticket form. Record the requester, the type, the group and the channel the request arrived through, and describe the request. Link the client and project if the request relates to one. Complete every mandatory field, then select Save.
What to verify: The ticket is created with status open and an agent is shown as assigned.
Step 3: Work the ticket
What to do: Open the ticket and add a reply to the requester, or an internal note for colleagues only. Attach files where they help. Use @mentions to pull in another team member. Add tags so similar tickets can be grouped later.
What to verify: The reply appears in the ticket conversation and the activity log records the change.
Step 4: Resolve and close the ticket
What to do: Set the status to pending while you are waiting on the requester or a third party. When the request is answered, set the status to resolved. Set it to closed once no further work is expected.
What to verify: The status shown on the ticket and in the list matches the real state of the request.
Field and Option Reference
| Field / Option | Description | Required |
|---|---|---|
| Requester | The person who raised the request. | Yes |
| Type | The classification of the request, from the types your Administrator configured. | Yes |
| Group | The support group that handles the ticket. Only agents enabled for that group can be assigned. | Yes |
| Channel | How the request reached you. | Yes |
| Assigned agent | The agent responsible for the ticket. Set automatically when round-robin assignment is used. | Yes |
| Client | Optional link to the client record the request belongs to. | No |
| Project | Optional link to the related project. | No |
| Tags | Free labels used to group and find related tickets. | No |
The ticket form is customisable, so the fields shown in your account and their order may differ from this list.
Expected Result
The ticket is saved with status open, appears in Tickets, is assigned to an agent, and records every reply and status change in its activity log.
Why This Matters for Service Organisations
For most professional services organisations, the relationship does not end at go-live. An implementation becomes a support retainer, a managed service, or a warranty period, and the requests that arrive relate directly to work the same firm delivered. When those requests live in a shared mailbox, nobody can answer the questions that decide whether a retainer is worth renewing: what the client asked for, and which engagement it came from.
How It Supports Professional Services
- A ticket can be linked to both a Client record and a project, so post-delivery requests stay attached to the engagement that produced them instead of forming a separate history.
- The four statuses give a delivery team one shared vocabulary for response and resolution, which is what a retainer review is normally conducted against.
- Round-robin assignment distributes incoming requests across the agents enabled for a group, so a managed-service queue always has a named owner rather than a collective one.
- Ownership-scoped visibility lets a specialist see only their own queue while an engagement lead sees the whole client's history - both views are legitimate.
- Ticket type is a reporting dimension, so genuine faults can be separated from chargeable change requests when a retainer's scope is disputed.
- The activity log preserves who did what and when, which is the evidence a service organisation needs in a contractual dispute.
Typical Service Workflow
Client → Project → Delivery → Support ticket → Retainer review
The ticket-to-client and ticket-to-project links are product features, so support sits alongside delivery without any manual reconciliation. Recovering chargeable support effort is a practice the organisation operates: time is logged against the project's tasks in the normal way, not on the ticket itself, and billable time is then invoiced.
Other Product-Type Use Cases
The same desk serves an internal IT or facilities helpdesk with no client link, a manufacturer handling product complaints, and a solar or construction business logging post-handover callouts against the installation project.
Related PSA Capabilities
- How to Build a Knowledge Base — reduces repeat questions on a support retainer.
- How to Set Up Round-Robin Ticket Assignment — keeps a managed-service queue owned.
- How to Manage Clients and the Client Portal — the client record a ticket links to.
Important Notes
- Menu names and their position can differ between product editions and can be customised for your account, so your sidebar may not match these paths exactly. Use Search or your Quick Access items if you cannot find a screen.
- Ticket visibility is ownership-scoped (
owned,added,both,all). Two users on the same team can legitimately see different ticket lists. - resolved and closed are separate statuses. Use resolved for "answered" and closed for "finished with".
Common Scenarios
Example: a client reports a fault on a live project. Create the ticket, link it to the client and the project, and assign it to the group that owns that work. The project team can then see the support history against the same project they are delivering.
Example: waiting for information. The agent has asked the requester for a document. Set the ticket to pending so it is not counted as active work, and return it to open when the reply arrives.
Troubleshooting
| Issue | Possible Cause | Resolution |
|---|---|---|
| The ticket list is empty or much shorter than expected. | Your permission scope limits you to tickets you own or were added to. | Ask your Administrator to review your ticket visibility scope. |
| The agent you want is not available for selection. | That user is not enabled as an agent for the selected group. | Ask your Administrator to enable the agent for the group. |
| A required classification value is missing from the form. | The type, group or channel has not been configured yet. | Configure it first in the ticket settings. |
| The project cannot be linked. | The project record does not exist, or you cannot see it under your project visibility scope. | Create the project first, or ask for access to it. |
Frequently Asked Questions
Can a ticket exist without a client or project?
Yes. The client and project links are optional. Internal requests can be raised without them.
Who chooses the agent?
Either you do, when creating the ticket, or the system does automatically when round-robin assignment is set up.
Can I reopen a closed ticket?
Change the status back to open if you have permission to edit the ticket.
Does the requester see internal notes?
No. Internal notes are for your team; only public replies are part of the conversation with the requester.
Related Articles
Our support team answers on business days. Reference SUP-01 so we can jump straight in.