Start with the current agreement
Identify the approved outcome, included and excluded work, key dates and the person who can resolve a scope question. Link each statement to its proposal, client decision or current project record.
Keep confirmed decisions separate from proposals and open questions. If two sources disagree, retain both and name the person who can resolve the conflict. Do not turn an unconfirmed date into a launch commitment.
Show what the next stage depends on
List the inputs or decisions needed before the next stage, the owner of each and how the team will know the dependency is resolved. Describe a risk through its possible project consequence and a practical response.
Include client preferences only when they are useful for this project and supported by a current source. Keep unnecessary personal details out of the packet and link the authorized record instead.
- Link the approved scope and important decisions.
- List unresolved dependencies with owners and triggers.
- Put the next actions in the order the new lead can take them.
A fictional Birch Hollow project
Birch Hollow's fictional client approved a content outline and two review rounds. One product image and its reuse permission are still missing, while a proposed launch date has not been confirmed. The draft is not yet ready for client review.
The incoming lead first checks the approved outline and asks the coordinator to obtain the image and permission. The launch question follows after the asset is resolved. The original packet preserves the sample decisions and next actions.
Walk through the packet together
Ask the incoming lead to locate the key records and explain what remains open. Test access to the current versions and correct missing references while the outgoing lead is available. Record the transfer date and who accepted the project state.
When client expectations still need clarification, name the person who will ask and keep the confirmed response with the project. This packet covers one project; portfolio-wide transfers and temporary leave cover need their own inventories.
Prepare the project packet with Areinum
Ask Areinum Assistant to arrange the supplied scope, decisions and open items into a handoff draft. Both project leads review the source references, agree the state and confirm access.
See the example
Single-Project Successor Handoff Packet
Birch Hollow, its client details, project decisions, dates, roles, and statuses are fictional.
| Project area | Current state | Decision or open question | Evidence location | Next action | Owner role | Due or trigger | Status |
|---|---|---|---|---|---|---|---|
| Approved scope | Client accepted the content outline and two review rounds. | The outline is approved; no extra pages are included in this sample. | Approved proposal, section 2 | Use the approved outline as the drafting boundary. | Project lead | Before drafting | Confirmed |
| Client assets | One product image is still missing. | Confirm whether the client can supply an image with reuse permission. | Asset request in the project folder | Ask the client for the image and permission confirmation. | Client coordinator | Before design review | Open question |
| Schedule | The team proposed a launch date, but the client has not confirmed it. | Do not treat the proposed date as approved. | Latest schedule note | Request confirmation after the missing image is resolved. | Project lead | After asset confirmation | Proposed |
| Review | The first draft is not ready for client review. | The new lead should verify that copy uses the approved outline. | Draft folder and outline | Complete the internal check, then submit for client review. | Content reviewer | After the internal check | Next action |
| Decision history | The outline replaced an earlier structure. | Keep both versions linked and identify the accepted version. | Decision note dated 12 October | Carry forward the accepted outline and its source. | Project lead | At transfer | Recorded |
- Use one project per file and keep each row tied to a current source. Replace the fictional project and dates with confirmed information.
- Separate an approved decision from a proposal or open question, and state the owner and trigger for each next action.
- Review the packet with the incoming lead, test source access, and record who accepted the project state.
Limits of this method
- The Reddit source is one unverified report about sales-to-onboarding handoffs. It is adjacent evidence for a new project lead, not proof of a general market need.
- Google Shared Drives can preserve team-owned files under their access rules, but do not guarantee a complete project packet or successor access.
- The example contains fictional decisions and dates. Confirm project scope, permissions, and client commitments from the actual records.
Questions you may have
What if the outgoing lead and the client remember the scope differently?
Record both accounts and their sources, and assign the question to the person who can resolve it. Do not rewrite the agreement to hide the disagreement.
Should a proposed launch date go in the packet?
Yes, if useful, but label it proposed and state what confirmation or dependency is still needed.
When has the new lead accepted the handoff?
After reviewing the described state and gaining access to the needed records. Record that acceptance and any unresolved items.
Sources and further reading
- Our sales to onboarding handoff currently depends on people remembering stuff
One practitioner describes recovering promises, customer context and next steps during a sales-to-onboarding handoff.
The account concerns an adjacent handoff, not every project-lead transition.
The original poster says onboarding must recover what was promised, what matters to the customer, unusual context, and next steps from notes or by asking the salesperson.
This is one unverified practitioner report from a sales-to-onboarding context. It is adjacent evidence for a single-project handoff, not proof that all project handoffs fail this way; comments are not used as evidence.
2026-10-18 - What are shared drives? | Google Workspace Learning Center
Google describes team-owned files and shared-drive access under organization and administrator settings.
The documentation does not guarantee a complete packet or a particular successor's access.
Google says files in a shared drive belong to the team and remain there when a member leaves, subject to the documented membership, access, and administrator rules.
This documents Google Shared Drives only. It does not assign work, confirm that a successor has access, or guarantee a complete handoff.
2026-10-18
The demo is in English. Access may need to be arranged.
Explore the demo