Sales and Finance
The deal and the invoice are the same customer
A CRM whose deal lines become the estimate and the invoice. No export, no re-keying, no second version of the customer to reconcile. Part of the platform, per seat.
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.
The deal becomes the project.
In our demo workspace, Kestrel Freight Systems signs the Advisory Engagement. The project opens from the deal with the scope, the team and the deadline that were agreed, and delivery stays visible from the account.
- 1
What was sold, written once
The deal records the scope, the people proposed and the date Kestrel was promised.
- 2
The project starts from it
A stage change is a trigger on the same graph, so the project opens attached to the deal it came from.
- 3
Delivery is visible where the money is
Phase 2 is marked complete and Finance drafts its invoice. Sales, delivery and support read as one account.
20 Oct 2026Carried from the deal into the project
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 through the project to the customer
A project belongs to the account it is for, so delivery is one click from the customer and the customer one click from the project.
Delivery status is visible where the money is
Projects and invoices belong to the same account, so “what is shipped” and “what is invoiced” are looked up together instead of reconciled monthly.
One question crosses sales, delivery and support
“Which accounts are at risk this quarter, and why” needs pipeline, delivery, tickets and invoices. Ask Cyril answers from your own records across all four, citing what it read; 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 shows its plan and waits for your approval before it acts.
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. Ask Cyril answers from projects, deals, tickets and invoices, citing the records it read and only those your role can open, rather than four tools with a human joining the results.
Two more hand-offs
How it fits togetherSales and Support
The ticket already knows who is writing
A helpdesk that already knows the customer’s account, open project and unpaid invoice — in one query, not six. Same platform, same per-seat price.
See it on your own data.
Cyril is pre-launch and opening early access through a waitlist. No self-serve signup yet, and no published customers — if you want the honest version of where it is, ask.
