Connect CRM and project management by handing over an agreed scope, a responsible delivery owner and the evidence that the work is ready to begin. A won opportunity should lead to a deliberate delivery acceptance, with open questions preserved. Creating a project record alone does not confirm that the delivery team understands or accepts the commitment.
The handoff needs to answer what was agreed, what is excluded, who supplies the inputs and how changes will be handled. Keep the sales conversation available, but do not make a project manager reconstruct the scope from a long sequence of messages. Produce a compact accepted-work brief linked to the underlying records.
This guide uses ERPNext documentation for specific project and order examples. Its original handoff envelope is a practical worksheet for moving a fictional won job into delivery without confusing a sales-stage change with permission to start every task.
What must be agreed before delivery accepts the work?
Separate commercial confirmation from delivery readiness. An ERPNext Sales Order records the customer’s confirmed request. The Sales Order documentation provides a concrete confirmed-record example. ERPNext distinguishes saving a Sales Order draft from submitting it. Identify which record your process treats as the agreed commitment and preserve its reference in the delivery brief.
List the promised outputs in terms that the delivery owner can check. “Set up reporting” needs a clearer result, such as a named report, its intended users and its acceptance evidence. State the inputs still required and the owner of each input. A missing input should remain visible rather than being hidden behind a generic project-open status.
Include boundaries and assumptions. If a proposal excluded data clean-up or an external integration, carry that exclusion into the brief. An assumption that has not been confirmed is a question for the handoff meeting, not a task silently assigned to the delivery team.
Name who accepts the brief and who can approve a changed commitment. Those responsibilities may belong to different people. Record acceptance as a decision with its evidence, then identify the tasks that are ready and those that depend on unresolved inputs.
How should the project represent the agreed scope?
ERPNext describes its project management as task-driven. ERPNext allows a Project to be divided into multiple Tasks. The Project guide makes tasks the working structure. Convert the accepted outputs into tasks with clear completion evidence. Avoid treating a copied sales note as an adequate task description when it leaves the next person to decide what completion means.
ERPNext can create a Project from an existing Project Template. A template can provide a starting structure, but review it against the won job. Remove irrelevant work and identify missing steps. Record which tasks come from the standard template and which were added for this scope so later review can explain the differences.
ERPNext Projects can link to a Sales Order. Use the link to preserve traceability between the commitment and execution. Check that the project points to the intended order and customer. A correctly named project attached to the wrong customer is still a defective handoff.
ERPNext documents Project as a possible downstream action from a Sales Order in v17. ERPNext says downstream Sales Order actions depend on modules, settings and permissions. Ask the demonstrator to show the available action in the proposed installation. If it is absent, investigate the documented conditions rather than assuming the menu is identical across versions. Record the actual creation route used for the exercise.
| Handoff element | What to put in the delivery brief | Acceptance question |
|---|---|---|
| Agreed outputs | Specific deliverables and source reference | Can delivery explain what completion means? |
| Inputs | Required material, owner and status | Which tasks can begin now? |
| Exclusions | Explicit work outside this commitment | Is any excluded work hidden in a task? |
| Acceptance | Reviewer and required evidence | Who can accept each output? |
| Changes | Request owner and approval route | How does a changed promise reach the plan? |
| Access | Intended participants and visibility | Does each person see only the agreed material? |
Who should see the project and its attachments?
ERPNext Projects can grant access to Website Users. ERPNext Projects include per-user attachment-viewing permissions. Access therefore belongs in the handoff discussion, especially when the delivery record will be shared outside the internal team. Decide which participants need progress information and which attachments they should be able to inspect.
Use fictional files in the first access test. Prepare one intended for the customer-facing view and one for internal planning. Record the expected visibility for each role, then test with the appropriate non-administrative account. The creator’s view is not evidence of what a different participant can see.
Keep access approval distinct from adding a name to the project. The business owner should identify the intended participants and their purpose; the system owner should implement and demonstrate the corresponding configuration. Preserve the evidence in the handoff envelope so later staff changes can be reviewed deliberately.
Original won-work handoff envelope
Consider a hypothetical job to create a small enquiry-tracking dashboard. The agreed outputs are a reviewed field list, a dashboard preview and a handover note. The customer has supplied a sample file but has not confirmed who should view the final dashboard. These are exercise assumptions, not a description of a customer engagement.
Commitment cover: Record the fictional opportunity, order and project references. Summarise the agreed outputs and exclusions. Link each summary item to its source in the approved brief. Ask the delivery owner to explain the scope back in their own words and record any disagreement before accepting the handoff.
Readiness sheet: Give each output an input, owner and readiness status. Field-list review can begin with the sample, while final access acceptance remains dependent on the customer’s participant list. Keep that dependency visible and avoid presenting the entire job as ready merely because some work can start.
Task translation: Create proposed tasks for field review, dashboard preparation and handover. Define the evidence for each: an accepted field list, an inspected preview and an acknowledged handover note. Compare the task list with the output list to catch both missing work and accidental additions.
Access card: List the internal delivery owner, customer reviewer and any other participant. Record the agreed file visibility and test it with fictional attachments. If an intended participant cannot see the preview, assign the correction before inviting them to review it.
Change exercise: Introduce a request to add another data source after handoff. Record it as a proposed change, identify its effect on inputs and tasks, and route it to the agreed approver. The exercise should show how a changed promise becomes an accepted revision rather than a casual comment buried in CRM.
How do you know the handoff is complete?
The handoff is complete when the delivery owner accepts a specific brief, the required records link correctly and unresolved inputs have named owners. Retain the task translation and access evidence with that decision. A project can then show what is ready, what is waiting and who must act.
Review the envelope again when scope changes or responsibility moves to another person. The point is continuity: the next colleague should be able to understand the commitment without repeating the sales discovery process or asking the customer for material already supplied.
For broader systems planning, see business systems and web development. To discuss a CRM-to-delivery workflow, get started with your proposed handoff envelope and a fictional example of the exceptions the current process struggles to carry forward.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.