The ticket already knows who is writing
A support request from a customer arrives with everything that customer is: the account, the pipeline, the open project, the unpaid invoice, every previous ticket. In a stack where the CRM and the helpdesk are separate products, an agent assembles that picture by hand, one tab at a time, on every ticket.
What that means on an ordinary Tuesday
Account, pipeline, project and invoice on the ticket
Not linked out to — present. The ticket is a view of the same graph the rest of the business writes to, so there is nothing to fetch and nothing to keep in step.
Support history is customer history
Past tickets sit beside past deals and past invoices rather than in a separate archive, so "have we had this problem before" and "are they a good customer" are the same lookup.
A client portal at no extra seat cost
Customers see their own tickets, documents, invoices and projects in one place, which removes a whole class of ticket: the one asking where something is.
Escalation does not need a second system
A ticket can create a task against the project it concerns, because both are records on the same graph rather than two products connected by a webhook.
What two separate tools do instead
The usual fix is to sync the customer list into the helpdesk, which solves the easy half — the agent now knows the name. What does not travel is the state: which deal is open, what was promised in it, whether delivery is late, whether finance has already made a concession. Each of those lives in a product the helpdesk cannot see, so the agent either asks internally and waits, or answers without knowing. Both are expensive, and only one of them is visible.
Whether this is for you
A good fit if
Your support agents routinely need to know something the helpdesk does not hold — what was sold, what is late, what is unpaid — and they currently get it by asking a colleague. That question is the cost, and it does not appear on any invoice.
A poor fit if
You run high-volume consumer support where the ticket genuinely is the whole context, and the customer relationship beyond it is thin. Then a dedicated helpdesk with deep routing may serve you better than a unified graph.
What this does not do yet
Cyril is pre-launch, so the useful thing to publish is the edge of what exists rather than a roadmap. If one of these is a hard requirement, say so early and we will tell you plainly whether to wait.
- Voice and telephony support are described on this site as coming soon rather than shipped. Treat them as absent when deciding.
- Public-facing community forums are not part of the module. The customer portal is per-customer, not a shared space.
- CSAT and survey tooling is not something to plan around yet.
The modules this uses
Both are part of the platform at one per-seat price — there is no bundle to assemble and no connector to buy. Each page below covers what that module does on its own.
Common questions
Do support agents need a full seat?
Staff seats are per person and cover the whole platform, so a support agent has the CRM context this page describes rather than a cut-down view. Customers using the portal are free and unlimited.
Can we keep our existing helpdesk and just connect it?
You can connect most things, but that is the arrangement this page is arguing against. A connector moves records; it does not give the helpdesk a shared model of the customer, which is where the cost sits.
What about a knowledge base?
The Docs module is the knowledge base. Public articles render in the customer portal, internal ones stay internal, and both are linked to the records they describe.
Be one of the first to use Cyril.
Join the waitlist for early access. We'll only email you when there's something real to share.