<aside> 📋 Frequency: Trigger-Based | Time: 30 min | Trigger: 30 days after engagement kickoff

</aside>

Most onboarding problems become invisible by the time you're 60 days in — you've adapted, the client has adapted, and the friction just gets absorbed into the engagement. Running a structured retrospective at 30 days captures the signal while it's still fresh and gives you the data to improve the next onboarding.

Prerequisites

Procedure

  1. Open your project management system and pull all session notes, the stakeholder map, the sprint log, and the alignment check output from the first 30 days.
  2. Run the Session Recap Writer skill with the first 30 days of session notes as input. Review the output for patterns — recurring themes, repeated questions, any structural gaps in how the onboarding unfolded.
  3. Using the Session Recap output as your raw material, run the retrospective procedure directly: assess what worked (kept without change), what didn't work (documented and flagged), and what was missing (added to the onboarding SOP backlog).
  4. Identify 1-3 specific process improvements for your next client onboarding. Document them with enough specificity to act on — not "improve intake" but "add a dedicated SOW review step before sending the questionnaire."
  5. Update your project management system with the retrospective summary and any changes flagged for future onboarding cycles.
  6. If the retrospective surfaces systemic patterns — issues that have appeared across multiple engagements — queue the Quarterly Practice Health Check SOP for a broader review.

Expected Outcome

A 30-day retrospective summary in your project system, 1-3 documented process improvements with specific action steps, and any systemic issues flagged for the Quarterly Practice Health Check SOP.

<aside> ⚠️ Common mistakes:

Running the retrospective too late — at 60 days, the onboarding experience has faded. The 30-day trigger exists because that's when the memory is still specific enough to be useful.

Treating the retrospective as self-criticism — it's a process audit, not a performance review. Focus on what the system should do differently, not what you should have done better.

</aside>