Handle customer support requests with assignments, notifications and full history. Run your own help desk inside the CRM so no request goes unanswered.
Run your own customer support desk with assignments, notifications and full history.
The ticketing module is an internal help desk for your own customers, living next to their lead record. A ticket has a subject, a linked contact, an owner, a priority (low, normal, high, urgent) and a status (open, pending, resolved, closed) with timestamps for when it was resolved and closed. Under it runs a conversation thread in which replies and internal notes sit side by side, and a reply can change the status in the same action. Assignment fires an in-app notification and, if enabled, an e-mail. It is deliberately not a customer portal: your team records the request, the customer keeps talking to you on WhatsApp or the phone. Available from the Growth plan.
The moment a business has more than a handful of customers, "someone called about a problem" starts falling through the cracks. It goes into a WhatsApp group, a sticky note, an e-mail to whoever seemed responsible, and three days later the customer calls again, angrier, and speaks to someone who has never heard of it.
Dedicated help-desk products solve that for support departments. Most small sales-led companies do not have a support department; the same five people sell, deliver and fix. For them a separate tool is one more login that nobody opens, and — worse — a place where the customer's history is split from the record the salesperson actually uses.
So the ticket lives on the contact. When the salesperson opens the lead to upsell, the open ticket is right there; when the support colleague opens the ticket, the deal value and the owner are right there. The two conversations that most often go wrong — "you are asking me to buy more while my last order is still broken" — stop being a surprise.
| Status | Means | Who acts next | Timestamp |
|---|---|---|---|
| Open | Logged, not yet handled or being worked on | Your team | created_at |
| Pending | Waiting on the customer, a supplier or a part | Someone else | — |
| Resolved | You believe it is fixed; awaiting confirmation or the cooling-off period | Customer, implicitly | resolved_at, first time only |
| Closed | Finished; no further action expected | Nobody | closed_at, first time only |
The distinction between open and pending is the one teams most often skip and most often regret. A queue of forty "open" tickets where twenty-five are actually waiting on a supplier looks like a crisis and hides the fifteen that are genuinely yours. Move them to pending and the queue tells the truth.
Resolved and closed are separate on purpose. Resolution time — created to resolved — measures your team. Closure is administrative and can happen days later; it should not distort the metric.
Every ticket has a conversation thread. Two kinds of entries live in it:
The reply form carries a status selector: "send and set to pending", "send and set to resolved". A support interaction almost always changes the state of the ticket, and asking for that as a second click is how tickets end up permanently open. One action, both effects, one log entry.
On the right of the thread is the management card: status, priority, assignee and linked contact, each editable inline, plus a timeline of created / resolved / closed with the people involved.
The ticket list is built to be read in two seconds by someone who has forty other things to do.
A new ticket is a modal on the same page — subject, description, contact, assignee, priority — so logging a call takes the time of the call, not a page load.
Tickets are a first-class entity in the permission model. A role can be given view, create, edit and delete on tickets independently of everything else, so a technician can work the queue without seeing the deal pipeline, and a salesperson can log a ticket without being able to close one.
Department scope applies as it does across the system: a manager sees their department's tickets, a team member their own and unassigned ones, an administrator everything. Creating or reassigning a ticket sends the new owner an in-app notification, and an e-mail if the ticket assigned event is enabled in mail settings.
It is worth being precise, because the word "ticketing" carries expectations.
This is not a customer-facing portal. Customers do not log in, do not see ticket numbers and do not receive automatic e-mails from the ticket. There is no e-mail-to-ticket ingestion, no SLA clock with escalation, and no public knowledge base. Requests arrive the way they already do — WhatsApp, phone, in person — and your team records them.
What it is: a shared, permissioned, historied record of every customer problem, attached to the customer. For a team of five to fifty that is the part that was missing; the portal and the SLA engine are usually the parts that were never going to be used.
Separately, SaleInline has its own support desk for you as a customer — inside the panel under Help → Support, with attachments and categories. That is a different system from the ticketing module described here.
| Symptom | Most likely cause | Fix |
|---|---|---|
| Everything is "open" | Team never uses pending | Agree the rule: waiting on someone else = pending; use "send and set pending" |
| Resolution time looks terrible | Tickets are closed directly, skipping resolved, days after the fix | Set resolved when fixed; close later. The first resolved stamp is what counts |
| Nobody was notified of an assignment | Ticket e-mail event disabled, or the assigner assigned it to themselves | Enable the event; the actor is skipped by design |
| A colleague cannot see the ticket | No view permission on tickets, or outside their department scope | Adjust the role or reassign within scope |
| Customer history is missing the ticket | Created without a linked contact | Set the contact on the management card; it is editable after creation |
| Internal note was read out to the customer | Human error — notes are amber and labelled | Training; notes are never sent anywhere by the system |
| Plan | Customer ticketing module | Per-entity roles for tickets | Department scope |
|---|---|---|---|
| Starter | — | — | — |
| Growth | Included | Included | Included |
| Business | Included | Included | Included |
| Enterprise | Included | Included | Included |
The ticketing module, full per-entity roles and department scope all arrive together with the Growth plan. Starter workspaces can record customer problems as tasks on the contact, which is a reasonable stopgap for a very small team. See the pricing page for the full comparison and roles and permissions for how ticket visibility is controlled.
Set up your workspace in under a minute — free for 14 days.
Create your workspace