A won deal still needs a delivery plan
Sales marks the proposal accepted. The teammate delivering the work then searches through notes for scope, deadline, and the client’s contact person. The CRM records a successful sale. It does not automatically establish that the team can deliver.
Organize information around the decision it supports. The CRM tracks the agreement and commercial relationship. The project register tracks delivery of the agreed work. Both can live in one application if that distinction stays clear. Two phases do not require two applications.
Use the blank field and handover map and completed fictional case.
Decide where each fact is maintained
Copying client and scope information into another tool creates two places that can disagree. Updating an address in the CRM may not change the project. Moving a project deadline may not change the agreement with the client. Identify where each fact is maintained and corrected.
| Fact or question | Primary place | What the other side needs |
|---|---|---|
| Contact and sales communication | CRM | Client link and relevant message |
| Accepted scope and price | Confirmed proposal or agreement linked to the CRM | Specific version and confirmation |
| Tasks, completion, and blockers | Project register | Status for the client-facing person |
| Change to agreed scope | New decision with the client | Confirmed change for delivery planning |
| Invoicing and payment | Billing records | Status and link, not duplicate accounting |
A project may hold a short operating summary of scope. Keep its accepted-version link and update date. If summary and agreement disagree, pause the affected work and resolve which applies.
Choose the smallest tool that keeps responsibility clear
One person delivering a few short projects may use existing tasks and a linked spreadsheet. Separate project tracking becomes useful when someone else takes over, work has dependencies, or several deadlines run in parallel.
Pipedrive distinguishes deals from projects: projects can link to deals and cover work before or after closing. Projects access depends on the plan. Current documentation includes it in Premium and higher plans and offers a paid add-on for Growth and lower plans. Check the actual user cost before choosing. A copy of the sales board alone does not justify the add-on.
If the team already delivers work in another tool, begin with manual links between the deal and project. A two-way connection adds change, recovery, and maintenance rules. First define what needs to travel.
The recipient completes the handover
Fictional example: deal D-042 covers a new page design. Accepted proposal v2 includes two revision rounds and delivery on October 23. Project P-042 links to D-042. Petra takes responsibility for delivery and checks usable inputs, confirmed scope, the date, and a contact person.
Pipedrive’s Projects instructions provide Mark as won and create a project when closing a deal. Set the title, owner, dates, and links. In another tool, create the project manually and add links on both sides. Record acceptance after Petra’s review; project creation does not perform that review.
Do not copy every sales note into delivery by default. Transfer what the work needs and limit access by role. A missing input needs a named person and next action; a green sales status cannot supply it.
In your existing work tool, create one project card or one row in a shared tracker. Enter project and deal IDs, links to the accepted proposal and client confirmation, a scope summary, delivery owner, first task, due date, and “awaiting acceptance” status. Petra opens the links using her own work account. Only after she confirms usable inputs and capacity for the first task should you record the acceptance date and change the status to “accepted.” If access is missing, keep “awaiting acceptance” and name who will obtain it and by when.
For a long sales thread, the project-handover AI agent can prepare a summary from the specific accepted version and supporting material. Its draft does not replace Petra’s acceptance. Automatic project creation is worth considering only after this manual handover and repeated-input check work.
Handle new work and scope changes explicitly
Another engagement for the same client gets its own identifier. A matching email address does not mean the same work. For a repeated handover attempt, first search for the project already linked to the original deal to avoid creating a duplicate.
When the client changes the brief, record the proposed change, its effect on price and date, and confirmation. Then update the affected delivery work. Keep the earlier accepted proposal traceable. Use the agreement-to-start workflow to check readiness itself.
Try the division with one fictional project: a teammate should find the applicable scope and start the first task without reading the entire sales history. If they cannot, repair the handover. Another application would carry the same gap elsewhere.
Documentation checked October 10, 2026. The field map and example are original design suggestions, not a claim of deployment in a particular team.