Ticketing

The problem

A support request starts in one place and ends in another. The user emails someone they know. The internal IT lead forwards it. The MSP picks it up, works it, and needs to say something to their own team that the customer must never read. When it turns out to need a specialist, the whole thread gets copied into a new system and the history stops. Three groups end up holding three partial records of the same job, and nobody can answer how long it actually took.

What Solidlio does about it

One ticket, three audiences, four layers of conversation. Every comment carries a visibility — public, org internal, MSP internal, or escalation — so all four layers live on the same record and each party sees only what is theirs. Queues decide who the work reaches, and can be shared across account boundaries so an MSP gives a client visibility of the queue handling their tickets without giving away the rest. When work outgrows the team holding it, escalation hands it to the servicing MSP or the platform provider network and keeps it attached to the original ticket.

Capabilities

Built for MSPs and their clients

Ticket data and tenant configuration follow deliberately different rules. An MSP reaches its clients’ tickets, because servicing them is the job. It does not inherit their settings — queues, SLA policies, and templates stay with the account that owns them.

How it works

1. The request arrives — raised in the customer portal, opened by staff, sent in by email through a monitored mailbox, or generated from a monitoring alert.
2. It lands in a queue — assigned by round-robin, load balance, least-recent, or left for manual pickup. A restricted queue is invisible to everyone outside it.
3. The SLA clock starts — response and resolution targets come from the policy that applies to the ticket’s priority. Staff pause the clock while waiting on a customer or vendor.
4. The team works it — replies go public or stay internal, time is logged against it, affected assets are linked, and a remote session can be started from the ticket itself.
5. It escalates if it needs to — to the servicing MSP or the provider network. The receiving side accepts, works, and resolves it on the same record, in a thread the end customer never sees.
6. It closes — the customer accepts the resolution or reopens it, and rates the outcome.

Audit and reconstruction

Every change to a ticket is recorded as an immutable entry: status moves, priority changes, assignment and reassignment, queue moves, SLA pauses and resumes, merges, and escalations. Each entry carries who made the change, when, and both the previous and new value — stored as names rather than internal ids, so the record stays readable after a person leaves or a queue is renamed.

Comments are held separately under their own visibility rules and merged into the same timeline, so an internal note never becomes visible through the audit view to someone who could not read the note itself.

Editions

Ticketing is included in every tier. SLA management is the gated capability, on two rungs: policies at Starter, business-hours and holiday clocks at Growth. The gate blocks new writes only — after a downgrade, existing SLA configuration stays visible and removable.

MSP tiers shown. End-customer tiers gate the same capability at Professional and above.

Integrations

• Microsoft 365 — monitored mailboxes turn inbound mail into tickets on a chosen queue
• Zabbix and ConnectWise Automate — monitoring alerts open tickets automatically
• ScreenConnect and ConnectWise Automate — start a remote session from the ticket
• Solidlio Assets — link affected hardware and software to the ticket
• Solidlio Billing — logged billable time feeds invoice generation
• Solidlio Knowledge Base — powers self-service deflection at intake