What you sold and what you are delivering are one thing
Selling work and doing the work are the same relationship at two stages, and almost every stack splits them across two products at exactly the moment continuity matters most — the handover. Cyril keeps the deal and the delivery on one graph, so the project starts from what was actually agreed rather than from a summary of it.
What that means on an ordinary Tuesday
A closed deal can create the project
Automation runs at the graph level rather than between products, so a stage change is a trigger and the resulting project is attached to the deal it came from.
Tasks roll up to a customer, a deal or a ticket
Project context is one click from the account, and account context is one click from the task — the same link read in either direction.
Delivery status is visible where the money is
Financials read from projects as well as deals, so "what is shipped" and "what is invoiced" are answerable together instead of reconciled monthly.
One question crosses sales, delivery and support
"Which accounts are at risk this quarter, and why" needs pipeline, delivery status, tickets and invoices at once. On one graph that is a query; across four products it is a spreadsheet somebody builds after something has gone wrong.
What two separate tools do instead
The handover is where two-tool stacks leak. What was promised lives in the CRM, often in a note; what gets built lives in the project tool, entered by someone who was not in the room. The gap is usually closed by a kickoff meeting whose whole purpose is re-reading the deal aloud. Then the two records drift, and by renewal nobody can say what the original commitment was without archaeology.
Whether this is for you
A good fit if
You deliver what you sell — services, implementation, retained work — and the handover between the two is a meeting rather than a link. The closer delivery sits to the commitment, the more one graph is worth to you.
A poor fit if
Your project work is unrelated to your pipeline — internal engineering on a product roadmap, say — and your project tool is doing a specialist job well. Sharing a customer graph buys you little when the work has no customer attached.
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.
- Resource levelling and capacity planning across a portfolio are not something to plan around today.
- Gantt dependencies exist, but critical-path scheduling and baselining are thinner than a dedicated PPM tool.
- Fully autonomous agentic project management is coming soon rather than shipped — what exists today plans, shows the plan, and acts where you can watch.
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
Is this a full project tool, or a light add-on?
Lists, boards and timelines over the same records, with tasks, dependencies and automation. What it deliberately is not is a standalone project product with its own copy of the customer — that is the thing this page argues against.
We use a project tool the team likes. Is that a problem?
Not a problem, but be honest about the trade. Keeping it means keeping the handover seam and whatever maintains it. That may well be worth it; it is just a cost worth naming rather than assuming away.
Does the AI see project work as well as pipeline?
Yes — that is the point of one graph. The AI layer reads projects, deals, tickets and invoices through the same permission model, so a cross-module question is one query rather than four with a human joining the results.
Sii tra i primi a usare Cyril.
Iscriviti alla lista d’attesa per l’accesso anticipato. Ti scriviamo solo quando c’è qualcosa di concreto da raccontare.