The moment a deal is marked won is the moment most businesses lose the context that made it winnable in the first place. Here is what actually leaks in that handover, and the specific mechanics — trigger, template, dependencies, idempotency — that stop it leaking.
A deal gets marked won. Somebody is happy about it for approximately four minutes. Then somebody else opens a project management tool that has nothing to do with the CRM, creates a new project, and starts retyping the scope from memory: what was promised, what the client actually said on the call, what the discount was contingent on, who the technical contact is. None of that context survives the handover intact, because the handover is a human retelling a story in a different room.
This is the single most reliable place for small and mid-size service businesses to lose money on an already-won deal. Not because delivery teams are careless, but because the tool boundary forces a re-entry step, and re-entry steps are where detail quietly evaporates. The fix is not "communicate better." The fix is removing the re-entry step entirely — which means the deal record and the project record have to live in the same system, and the transition between them has to be a rule, not a memory.
Why the handover leaks
Three things go wrong in a typical won-deal handover, and they compound.
- The scope gets retyped, not transferred. Whoever creates the project in the separate tool is working from notes, an email thread, or a Slack message, not from the deal record itself. Anything that lived only in a call summary or a custom field on the deal has to be actively remembered and copied across.
- The deal context disappears. Why was this discounted? What did the client push back on? Who on their side actually signs off? That context sat in deal notes and activity history, and unless someone deliberately copies it forward, delivery starts the project blind to the negotiation that produced it.
- Timing depends on someone remembering to do it. If creating the project is a manual step performed "when someone gets around to it," the gap between won and kicked-off is elastic, and it grows exactly when the business is busiest — which is also when the client is most attentive and most likely to notice the silence.
The structural answer is to make the deal and the project artifacts of the same platform, and to make the transition automatic, conditional, and impossible to duplicate. That is what the rest of this post walks through.
The automation: deal won to project created
In Stillpoint, automations are trigger, conditions, action. For this workflow the trigger is deal won — the deal moving into a stage flagged as a won stage on its pipeline. You can leave it unconditional, or add conditions so it only fires for the deals where a full project actually makes sense: deal value above a threshold, or restricted to a specific pipeline (so, for instance, small one-off WooCommerce orders on the Orders pipeline don't spin up a delivery project, but service-pipeline deals do).
The action is create project from template. When it fires, the new project is linked back to the originating deal, which is what actually solves the context problem: the project isn't a fresh blank object that happens to be about the same client, it's a continuation of the same record, so anyone on delivery can open the project and see the deal it came from — the value, the notes, the activity history, the contact — without a separate lookup.
The five templates
A template is a pre-built set of tasks with relative timing, not absolute dates. Each task carries a day offset from a chosen anchor — typically the project's start date — so a task defined as "day 3" lands three days after whatever day the project actually starts, whether that's the day the deal closed or a scheduled kickoff a week later. That's what makes a template reusable across deals that close on different days: the structure is fixed, the calendar is not.
Stillpoint ships five project templates covering the shapes of work that recur across service and delivery businesses — onboarding, a standard delivery/implementation project, a smaller fixed-scope engagement, an internal or ops project, and a retainer-style recurring work project. Each defines its own tasks, day offsets, milestones and dependencies, and each is editable: templates are a starting structure, not a constraint, so you can adjust one to match how your team actually works and it applies to every project created from it going forward.
Dependencies, without the footguns
Templates and projects both support task dependencies with the four standard relationship types: finish-to-start (FS) — the classic "B can't start until A finishes"; start-to-start (SS) — B can't start until A starts; finish-to-finish (FF) — B can't finish until A finishes; and start-to-finish (SF), the rarer case where B can't finish until A starts. Real project structures need more than the default FS relationship — a review task that must finish alongside the task it's reviewing, or two tasks that need to kick off together — and modelling only FS forces you to fake the others with workarounds.
Two things make dependencies safe to actually use rather than a source of quiet corruption. First, cycle detection: when you add a dependency, Stillpoint checks whether it would create a loop — A depends on B depends on C depends on A — and refuses it, because a cyclic dependency graph has no valid schedule and would otherwise fail silently later. Second, opt-in rescheduling: moving a task's date does not automatically cascade through everything downstream unless you choose to let it. When you do opt in, the reschedule preserves each dependent task's original duration — a five-day task stays five days long, it just shifts — rather than silently stretching or compressing it to fill whatever gap the cascade produces.
Milestones, assignees, and time
Templates and projects both support milestones as distinct markers separate from ordinary tasks — client sign-off, go-live, final invoice — so the project's shape is visible at a glance instead of buried in a flat task list. Tasks support a single owner or multiple assignees, which matters for anything genuinely collaborative: a task that needs a designer and a copywriter both accountable for it shouldn't have to be artificially split into two tasks just because the data model only allowed one owner.
Time tracking runs at the task level, with a billable flag per entry. That flag doesn't compute margin or profitability on its own — more on that caveat shortly — but it's the distinction that separates client-chargeable hours from internal overhead in every downstream report, which is the piece most generic task tools skip entirely.
Project health, and why the reasoning is visible
Each project shows a suggested health status, and the reasoning behind it is shown, not hidden — you can see which signals pushed it towards on-track, at-risk, or behind, such as overdue tasks relative to the schedule or a stalled milestone. Suggested rather than authoritative is a deliberate choice: a health indicator that silently overrides a project manager's own judgement erodes trust in the tool fast, whereas a transparent suggestion you can agree with, override, or investigate stays useful. Overall progress rolls up from the project's boards — the proportion of tasks completed across the board views feeding the percentage you see at the project level, so it reflects actual task completion rather than a manually-typed guess.
What the reporting actually tells you
Because deal and project data live in the same platform, reporting can answer questions that a bolted-together stack usually can't. Time-in-stage and stage-to-stage conversion are computed from the recorded stage history of deals moving through a pipeline — how long deals typically sit in each stage, and what proportion move forward versus stall or drop — which tells you where your sales process is actually slow, not where you assume it is. On the delivery side, the report builder can pull time entries against targets, so you can compare tracked hours on a project or task type against a budget you set.
Closing the loop: Customer 360
The payoff of keeping the deal and the project in one system shows up on the customer's own record. Open a customer in Stillpoint and you see the deal that was won, the project it became, the tasks and milestones in flight, tracked time against them, and — for a WooCommerce customer — the order history alongside all of it. That single view is only possible because nothing had to be re-typed to get there: the same underlying record carries the relationship from first contact through delivery, which is the actual point of not splitting your CRM and your project tool across two products in the first place.
None of this requires a bigger team or a bigger bill. It's one flat price with unlimited users, which matters specifically here: a won-deal-to-project handover that requires per-seat licensing to include the whole delivery team is a handover that will quietly exclude someone.