PRACTICAL GUIDE
Connect CRM and project management without losing the customer agreement
Design the handover from an opportunity to actual delivery. Give project staff the customer context, responsible people and next action while keeping commercial and operational records understandable.
The handover is more than changing a status
A salesperson can mark an opportunity as won while the delivery team still lacks a usable brief. The missing information is often not a new feature: it is the agreed scope, the reason for a decision or who should clarify an uncertainty. Define that information before connecting records, and ask the receiving role what it needs to start work.
Define what sales must hand over
Create a short handover specification containing the customer, relevant contacts, agreed scope, open questions and responsible people. Distinguish a promised outcome from an internal task list. Keep references to the authoritative quotation or agreement accessible. Tsumira connects CRM, quotations, projects and communication, but the team still needs to decide which information is current and who maintains the commercial record.
- Include unresolved questions rather than hiding them.
- Separate customer contact from internal project ownership.
Agree how changes travel after work begins
The original handover will not remain complete forever. Decide who records a changed request, updates the agreed scope and informs delivery. Test the process with different permissions rather than only an administrator. AI can help prepare a summary, but in Tsumira proposed actions are reviewed before execution. A clear summary does not replace the source agreement or the responsible person’s judgment.
- Name the owner of scope changes.
- Keep restricted commercial information appropriately controlled.
A concrete workflow
Prepare the customer brief
Collect the relevant contact, agreed service, open questions and reference documents. Let the receiving team confirm what is missing.
Perform the handover
Create or organize the delivery work deliberately and verify the customer reference. Assign the next task and its owner.
Introduce a changed request
Ask another role to update the case and continue working. Review whether the team can identify the latest agreement without guesswork.
An illustrative working example
Illustrative scenario: two projects for one customer
A consultancy has a research engagement and a separate workshop for the same company. The project leads need different scopes, while both use the same customer contacts. The test checks that each person finds the correct agreement and conversation. A later workshop change must not silently alter the research project’s context. This is a more useful acceptance case than a single simplified won deal.
Questions about this topic
Must sales and delivery use the same record?
They can need different records with clear relationships. A customer, opportunity and project represent different responsibilities. The useful result is understandable context, not forcing every activity into one object.
What belongs in a practical handover?
The customer, relevant contact, agreed scope, responsible people, open questions and authoritative references. Include the next action so the receiver can begin rather than merely reading a historical summary.
Does linking records replace a handover conversation?
No. Links make information accessible, but the people responsible still need shared meaning. Use the conversation to resolve ambiguity and record the resulting decision in the agreed place.
How should success be checked?
Let the receiving person continue a real engagement, including a change after the start. Verify access, the correct agreement and the next action without coaching from the original salesperson.
Explore connections around this workflow.
Ideas for intended connections. Check the actual availability, permissions and supported data for each app before using a scenario.
