A support ticket is a customer request that arrives as an email and becomes a task inside include GO. Where an ordinary task is work you planned ("Weekly Mow — Edge & Blow"), a ticket is work someone asked for: "Sprinkler head broken at the front entry," "Please send last month's invoice again." Tickets ride the same task machinery as everything else — they live on a project, carry a workflow state, and hold a message thread — so a customer's question and the work that answers it end up being the same record.
Navigation: in the left sidebar, click Tasks, then click Inbound in the view-mode row above the grid.
How tickets arrive
Tickets are created by inbound email. A customer writes to your support address; include GO receives the message, creates a ticket task, and replies to the customer automatically. Nobody has to be watching an inbox.
Two things have to be true for that to work, and both are configured once:
- A support inbound address is set in Settings under Email Settings, on the Inbound Mailboxes card. There are two fields — Support Inbound Email and Sales Inbound Email — and they decide which queue a message lands in. If the same address is entered in both, Support wins, so the message stays in the triage queue rather than being filed as a lead.
- The business unit must be active and a production environment. A sandbox business unit will not receive live customer mail just because the field has been filled in.
An inbound address can only belong to one business unit. If the same address is claimed by two, include GO refuses to guess and the message is not routed — a deliberate fail-safe rather than a coin flip.
What happens when an email lands
In order:
- The sender is looked up by email address. If exactly one active client account is linked to that person, the ticket is matched to that account. If the sender is unknown — or is linked to more than one account — the ticket is left unmatched, which is the normal case for a first-time customer.
- The ticket is placed on a project. If the matched account has exactly one project tagged Support, the ticket lands there. Otherwise it is parked on a catch-all project named Unsorted Support, which include GO creates once and then reuses. Unsorted Support has no client attached — it is a parking bay, not a job.
- The ticket is created. Its name is the email's subject line (or "Support request" if the subject was empty). It is tagged Support, put on the Support Ticket Workflow in the New state, and left unassigned.
- A priority is set automatically. include GO reads the subject and body and picks Low, Normal, High, or Urgent. If it cannot read the message confidently — or the service is unavailable — it sets Normal. Priority never blocks a ticket from being created, and your team can change it freely afterwards.
- The customer gets an acknowledgment. An automatic reply goes out immediately — by default with the subject "We received your request: …" and a reference number. You can rewrite that wording in Settings under Auto-Reply Templates.
- Your team is notified, if you have configured who should hear about new tickets. See The settings that feed tickets.
The email body does not become the task's description. It is recorded as the first message on the ticket's thread, which is why you read a ticket by opening its chat rather than by looking at a Description field.
Replies and repeat emails
include GO works hard to avoid turning one conversation into five tickets.
- A reply to an open ticket is added to that ticket's thread. Threading is matched on the email's own reply headers, so it still works when the customer's mail client rewrites the subject line.
- A near-duplicate is folded in. If the same sender emails again within 14 days, on the same project, with the same subject — ignoring Re:, Fw: and Fwd: prefixes — the message is appended to the existing open ticket instead of opening a new one. When that happens, no second acknowledgment is sent and no second notification fires.
- A reply to a closed ticket opens a new one. Closed is permanent and is never reopened. The new ticket is linked back to the closed one, and its first message is prefixed with a marker naming the ticket it continues. The Inbound grid shows that link under the ticket name as ↳ continues "…", so a continuation is recognisable at a glance instead of looking like a brand-new request.
- Automatic replies and bounces are discarded rather than logged as customer messages, so an out-of-office auto-responder cannot start a ticket ping-pong.
The Inbound view
Open Tasks and look at the view-mode row above the grid: All, Sales, Production, Archive, Snow, and Inbound. Click Inbound and the task grid is replaced by the support-ticket grid — a different set of columns for a different job. The My Tasks switch disappears in this view, because Inbound has its own queue split instead.
Two things are worth knowing about what this view holds:
- Tickets do not appear in the All view. They have their own home here, so inbound email never dilutes your regular task list or inflates your task counts.
- Inbound shows support tickets only. Mail that arrives on your sales inbound address becomes a task too, but it belongs to the sales pipeline and surfaces on the Sales view rather than here.
Triage and My Queue
Two tabs sit at the top-left of the Inbound view:
- Triage — every ticket that is not finished, whether or not it has been mapped or assigned. Deliberately broad: a ticket that has been assigned to a colleague and moved onto a real project still shows here, so nothing can quietly become one person's private problem. When it is empty you see "Nothing needs triage right now."
- My Queue — tickets where you are the assigned (responsible) person. This is your personal worklist once triage has handed things out.
A ticket leaves Triage when it reaches a terminal state — which, on the support workflow, means Closed. Merged tickets also drop out of both queues.
What the columns tell you
| Column | What it shows |
|---|---|
| Ticket | The subject line, as a link that opens the full task. A second line reading ↳ continues "…" appears when this ticket was opened by a reply to a closed one. |
| Priority | Low, Normal, High, or Urgent — set automatically on arrival, editable afterwards. Sorting this column ranks by real severity (Low → Normal → High → Urgent), not alphabetically. |
| Needs Reply | An amber Customer replied badge when the last human message on the thread came from the customer. This is the most useful column in the grid: it is the list of people waiting on you. Automatic acknowledgments are excluded, so a brand-new ticket is never falsely marked as already answered. |
| Account | The client. Reads Unmatched when the sender could not be tied to an account — those are the rows that need mapping. |
| Project | Where the ticket currently sits. Unmapped tickets show the Unsorted Support parking project. |
| Assigned To | The responsible person, or Unassigned. |
| Status | The workflow state, in that state's own colour. |
| Created | When the ticket arrived. |
You can search the grid by ticket name and description, and filter or sort on account, project, assignee, status, priority, tags, and created date.
The right-click menu
Right-click any ticket row:
| Menu item | What it does |
|---|---|
| Open Chat | Opens the ticket's message thread — the customer's original email, every reply, and the box you type your answer into. This is where you actually work a ticket. |
| Map… | Assigns the ticket to a client, a project, and a person. See below. |
| Change Status… | Moves the ticket through its workflow. |
| Merge… | Folds this ticket into another one. |
Everything except Open Chat requires the tasks update permission. Without it, the menu offers Open Chat alone and the New Ticket button is hidden.
Mapping a ticket
Mapping is the core triage move: taking a ticket that arrived from a stranger, or landed in Unsorted Support, and putting it where it belongs. Right-click the ticket and choose Map….
The dialog opens pre-filled with wherever the ticket currently sits, so you are correcting a position rather than starting from a blank form. It has four parts:
| Field | What it does |
|---|---|
| Client Account | Search your accounts and pick the customer. If they are not a customer yet, click New Client — the standard account dialog opens, so a client created here is identical to one created from the Accounts page. After saving, search for the new name in this field to select it. |
| Project | Optional. Leave it blank to use the account's Support project, or choose a specific project to place the ticket exactly — for example on the live job the customer is actually asking about. |
| Assign To | Tick Assign this ticket to me to take it yourself, or search for a colleague. Assigning is what moves a ticket into someone's My Queue, and the person you pick is notified. |
| Request Type and Module | Optional categorisation — what kind of request it is, and which part of the business it concerns. Both feed Support Reporting. |
You must choose either an account or a project; the dialog will not submit with both blank ("Choose a client account or a project"). You may send both — the project wins, because it is the more specific target, and the client is taken from that project.
When you map to an account without naming a project, include GO finds or creates that account's Support project and puts the ticket there. Mapping does not change the ticket's status: it keeps the Support Ticket Workflow, so its status dropdown goes on offering support states rather than ordinary task states.
Two details worth knowing:
- Picking a person overrides "Assign this ticket to me." They are alternatives, not additions.
- Creating a new client needs a known sender. The new account's contact is built from the email address the ticket arrived from, so a ticket with no sender email on record cannot use New Client — map it to an existing account instead.
Creating a ticket by hand
Not every request arrives by email. When a customer phones, or forwards something to your personal inbox, click New Ticket at the top-right of the Inbound view.
| Field | Notes |
|---|---|
| Client Account | Required. The ticket lands on this account's Support project, which is created for you if it does not exist yet. |
| Requester | Optional — the person who asked. Required if you want to email them (below). |
| Subject | Required. Becomes the ticket name. Up to 255 characters. |
| Message | Required. What the customer reported, in your words. Up to 20,000 characters. |
| Email this message to the requester | Off by default. Leave it off and your write-up is filed as an internal note. Tick it and the message is emailed to the requester, opening the conversation from your side. |
A hand-made ticket is otherwise identical to an emailed one — same Support tag, same workflow, same New state — so it triages, merges, and reports exactly the same way. The Create Ticket button stays disabled until account, subject, and message are all filled in.
Merging duplicate tickets
Customers email twice. Someone forwards the same complaint from a second address. Merging cleans that up: right-click the ticket you want to retire and choose Merge…, then search for the ticket you want to keep.
On merge, the retired ticket's replies, thread participants, and CC recipients all move onto the ticket you kept, so the surviving thread holds the whole conversation — with no duplicated people or addresses. The surviving ticket also records a note saying which ticket was merged into it. The retired ticket is pointed at its survivor and disappears from both Inbound queues.
Three things are blocked, each with its own message:
- "A ticket cannot be merged into itself." The ticket you are merging is never offered as its own target.
- "This ticket has already been merged."
- "Cannot merge into a ticket that has itself been merged." Pick the surviving ticket instead.
Merging is one-way and there is no unmerge in the interface, so choose the survivor deliberately — normally the older ticket, or whichever one your customer is actually replying to. If a customer later replies to a merged-away ticket, include GO follows the trail and lands the reply on the surviving ticket automatically.
Working a ticket through its workflow
Tickets run on their own Support Ticket Workflow, separate from the standard task workflow that ordinary tasks use. Right-click a ticket and choose Change Status… to move it.
| State | What it means |
|---|---|
| New | Just arrived, nobody has picked it up. Every ticket starts here. |
| Open | Someone is working it. |
| Waiting on Customer | The ball is in the customer's court — you have asked a question and are waiting for an answer. |
| Solved | You believe it is finished, but the ticket is still alive in case the customer disagrees. |
| Closed | Finished and final. Closed is the only terminal state, and there is no route back out of it. |
The permitted moves are: New → Open or Waiting on Customer; Open ↔ Waiting on Customer; Open or Waiting on Customer → Solved; Solved → Open (when it turns out not to be solved); and Solved → Closed. There is no path out of Closed, and no shortcut into it — closing a ticket means passing through Solved first.
Two transitions happen without you:
- A customer reply reopens a Solved or Waiting on Customer ticket back to Open. "Solved" is a claim, and the customer gets to reject it.
- A reply to a Closed ticket starts a new, linked ticket rather than reopening the old one — see Replies and repeat emails.
That difference is the whole reason both Solved and Closed exist. Use Solved when you are done but the customer has not confirmed; use Closed when you want the record sealed.
Tickets, projects, and tasks
A ticket is a task. There is no separate ticket record to reconcile — which means a ticket carries everything a task carries, and the Inbound grid is simply a specialised lens on a slice of your tasks.
- Click the ticket name in the Inbound grid to open the full Task Detail dialog. From there you can schedule it, assign a team, add resources, and cost it like any other work — useful the moment a "quick question" turns out to need a truck and two hours.
- Every ticket lives on a project. Unmapped tickets sit on Unsorted Support; mapped ones sit on the client's Support project, or on a specific job you chose.
- A client's Support project can also be created ahead of time from the Accounts page, using the Create Support Project right-click action — handy when you are onboarding a client you know will file tickets.
Permissions
| Permission | What it grants |
|---|---|
| tasks view | See the Inbound view and both of its queues. |
| tasks update | Map, change status, and merge tickets, and read the Request Type and Module lists in the Map dialog. Without it, the right-click menu offers Open Chat only. |
| tasks create | Create a ticket by hand with the New Ticket button. |
| settings manage request types | Add, edit, and archive entries on the Request Types list. |
| settings manage ticket modules | Add, edit, and archive entries on the Ticket Modules list. |
| settings manage email | Configure inbound mailboxes, inbound notifications, and auto-reply templates. |
Note that ticket permissions are not scoped by account or assignee: anyone with tasks update can map or merge any ticket, not only the ones in their own queue. Permissions are assigned per role on the Roles & Permissions page in Settings.
The settings that feed tickets
Five Settings pages plug into this subsystem, each with its own entry in the Settings sidebar:
- Email Settings → Inbound Mailboxes — the support and sales addresses customers write to. Nothing arrives until one is set.
- Inbound Notifications — who is told when a new ticket arrives. Set a role, or list specific users; a role takes priority if both are filled in, and only active users are notified. If neither is configured, no notifications are sent at all. This tab also carries the project-routing control that decides how hard include GO tries to pick the right project for a ticket.
- Auto-Reply Templates — the wording of the acknowledgment the customer receives. Edit the subject and body; anything you leave alone keeps the built-in default.
- Request Types — the list behind the Request Type field in the Map dialog: your own vocabulary for what customers ask for. Ships with a starter list (General Question, Defect, Error Message, How-To, Access Request, Feature Request, and more) that you can rename, reorder, or archive.
- Ticket Modules — the list behind the Module field: which part of the business the request concerns. Also ships with a starter list.
Support Reporting, also in the Settings sidebar, is where that categorisation pays off. Over a date range you choose, it shows tickets created, open versus resolved, how many were merged, median time to first reply, open tickets per agent, breakdowns by request type and module, and customer-satisfaction ratings.
Good to know
- Work the Needs Reply column first. It is the only column that answers "who is waiting on us right now?" Priority tells you how loud a ticket is; Needs Reply tells you whether the ball is in your court.
- Unmatched is not a failure. A first-time customer is always unmatched, because matching is by email address. Mapping them — with New Client if needed — is the normal first step, not a repair job.
- Triage is intentionally noisy. It shows assigned, mapped, in-progress tickets too. That is on purpose: a ticket that fell off someone's plate stays visible to the whole team instead of vanishing into a private queue.
- Priority is a first guess, not a verdict. It is read from the customer's own words on arrival and falls back to Normal whenever include GO is unsure. Override it whenever you know better — nothing downstream depends on the original guess.
- Fill in Request Type and Module while you are already in the Map dialog. They take two seconds during triage and are what make Support Reporting worth reading. Retrofitting them across a quarter's worth of tickets is a bad afternoon.
- Closed means closed. Prefer Solved unless you specifically want a later reply to start a fresh ticket rather than continue this one.
Frequently asked questions
A customer says they emailed us, but no ticket appeared. Where do I look?
Check three things, in order. First, that the address they wrote to is the one configured in Email Settings → Inbound Mailboxes. Second, whether they replied to an existing open ticket, or emailed the same subject within 14 days — in which case their message was appended to that ticket's thread instead of creating a new one, and no acknowledgment was sent. Third, whether the message was an automatic reply or a bounce, which are discarded on purpose.
Why is this ticket on "Unsorted Support" instead of my customer's project?
Because include GO could not confidently pick a project. Either the sender's email address is not on any account, the address is linked to more than one account, or the account has no single project tagged Support. All three are resolved the same way — right-click and Map….
I mapped a ticket to an account but it did not go to the project I expected.
If you left Project blank, it went to the account's Support project. To place a ticket on a specific job, name that project in the Map dialog — when you supply both, the project wins.
A ticket disappeared from Triage. Where did it go?
It was either moved to Closed — the only terminal state — or merged into another ticket. Merged tickets leave both queues; their conversation lives on the surviving ticket.
The customer replied to a ticket we closed. Why is there a new ticket?
By design: Closed is permanent. The reply opens a new ticket linked to the closed one, shown as ↳ continues "…" under the ticket name, with its first message naming the ticket it continues. If you would rather a reply reopened the original, leave tickets in Solved instead of closing them.
Why does the Needs Reply badge not appear on a ticket we have not answered yet?
The badge tracks whether the last human message came from the customer. The automatic acknowledgment does not count, so a brand-new, untouched ticket shows the badge correctly rather than looking answered.
Can I turn off the automatic acknowledgment?
You can rewrite its subject and body under Auto-Reply Templates. It is only ever sent once — on ticket creation, never on follow-up messages folded into an existing ticket.
Can I undo a merge?
Not from the Inbound view. Merge deliberately, choosing the ticket you want to keep as the target.
An email came in to our sales address. Why isn't it in Inbound?
The Inbound view holds support tickets only. Sales-inbound mail becomes a task in the sales pipeline and appears on the Sales view instead.
Why don't tickets show up in the All view on the Tasks page?
They are kept out on purpose, so inbound email does not dilute your task list. Inbound is their home; the ticket name in that grid links to the full task whenever you need it.
Related topics
- Tasks — a ticket is a task; this covers the Task Detail dialog you reach from the ticket name.
- Accounts — client records, the Create Support Project action, and the New Client dialog used during mapping.
- Projects — where tickets live, including the Support and Unsorted Support projects.
- Email Settings — the Inbound Mailboxes card that lets tickets arrive at all.
- Workflows — how workflow states and transitions are configured.