Archives: Documents

Guide: Framing a Design Problem from a Business Brief

Purpose

To help designers systematically interpret a business-oriented request (e.g., “We need a landing page”) into a clear design problem statement that guides execution and avoids misalignment.

Why This Matters

  • Business briefs often focus on what they want (output), not why they need it (problem).
  • A structured reframing ensures the design effort directly addresses user needs, business outcomes, and measurable success.
  • Prevents jumping into UI before understanding context.

Step-by-Step Guide

1. Extract the Core Business Ask

  • Identify the request in the brief.
  • Example: “We need a new SaaS product landing page.”

2. Probe for the Business Problem

Ask:

  • “What’s driving this request?”
  • “What business risk or opportunity is at stake?”
  • Translate into a problem statement.
  • Example: “Demo bookings from current page are too low, affecting pipeline.”

3. Define the User Problem

  • Who is the user? (Use Persona Lite Sheet – EPIC 1.6)
  • What blockers do they face?
  • Example: “Visitors cannot quickly understand value; page is too text-heavy.”

4. Frame the Design Challenge

Convert business + user problem into a design challenge statement:

“How might we design a landing page that clearly communicates product value within 30 seconds and increases demo sign-ups by 20%?”

5. Classify Problem Type

Use Design Problem Typology Matrix (EPIC 1.5) to categorize:

  • Conversion Issue (e.g., low sign-ups, unclear CTAs)
  • MVP/Feature Launch (new flows/screens for product)
  • UI Consistency Fix (spacing, tokens, alignment)
  • Campaign Creative (marketing-driven visuals)
  • Accessibility Gap (inclusivity, compliance)

6. Define Success Criteria

Use Design Goals & Success Criteria Sheet (EPIC 1.7) to clarify:

  • Business Metric (e.g., demo bookings +20%)
  • User Metric (e.g., <40% bounce rate)
  • Team Metric (handoff-ready Figma by deadline)

Framing Template (Quick Reference)

StepQuestion to AskExample Output
Business AskWhat is being requested?“Landing Page Redesign”
Business ProblemWhy is this needed?“Low demo bookings”
User ProblemWhat’s blocking the user?“Clarity of value prop”
Design ChallengeHow might we…?“Communicate value in <30 sec”
Problem TypeWhat bucket does this fit?“Conversion Issue”
Success CriteriaHow will we measure?“+20% demo sign-ups”

Usage Notes

  • Always document the reframed problem inside the Discovery Summary Presentation (EPIC 1.10).
  • Share it in the Discovery Alignment Call (EPIC 1.9) to validate with stakeholders.
  • Store alongside the original brief + interview notes for traceability.

Template: Stakeholder Interview Notes

Purpose

To capture stakeholder insights, expectations, and constraints during the discovery phase of a design project. This ensures decisions are based on real business/user context, not assumptions.

Table – Stakeholder Interview Notes Template

SectionPrompt / QuestionNotes (Designer/PM fills)Sample Entry
Stakeholder InfoName & RoleWho is providing inputs?“Sarah – Growth Manager, ABC Corp”
 Project InvolvementTheir influence/decision power“Approves final design”
Business ContextWhat is the main business goal for this design?Capture their wording, not assumptions“Increase trial-to-paid conversions”
 What’s the biggest risk if this design fails?Reveals priority & pressure points“Lost credibility with investors, delayed launch”
Audience & UsersWho are the primary users/customers?“SaaS product managers, age 30–45” 
 What do they care about most?“Clarity, speed of setup, reliability” 
 What frustrates them today?“Too many manual steps in PRD creation” 
Design NeedsWhat kind of design deliverables are expected?“Landing page, onboarding flow, dashboard UI” 
 Any mandatory brand or compliance rules?“Follow existing brand guide; must meet WCAG AA accessibility” 
 Any inspirations or references you’d like us to consider?“Stripe dashboard, Notion landing page” 
Success & MetricsWhat does success look like in your eyes?“10% conversion uplift, reduced support tickets” 
 Who signs off on success?“CEO + Design Lead” 
ConstraintsTimeline constraints?“Launch in 3 weeks (before demo day)” 
 Budget constraints?“Fixed – part of existing retainer” 
 Tech constraints?“Front-end in React, backend APIs locked” 
Wrap-UpKey open questionsTo be clarified in alignment call“Is mobile version required for MVP?”
 Next steps agreedAction points from the discussion“Designer to prepare intake summary deck”

Usage Notes

  • Interview should be 30–45 mins max, focused on clarity.
  • Notes must be captured live in this template (not post-facto).
  • After interview:
    1. Convert findings → Problem Typology Matrix (EPIC 1.5).
    2. Validate via Discovery Alignment Call SOP (EPIC 1.9).
  • Store final notes in MIC → Project Folder → Discovery/Intake Docs.

Template: Design Brief (Web/Product/Marketing)

Purpose

To collect structured context at the start of any design request. This ensures alignment on business goals, user needs, constraints, and success criteria before the design process begins.

Table – Design Brief Template

SectionFieldDescriptionSample Entry
Basic DetailsProject NameTitle of the design project“Product Landing Page – SaaS AI Tool”
 RequesterWho raised the request (client/PM/internal team)“Client – Growth Manager, ABC Corp”
 DateDate of request submission“26 Aug 2025”
Business ContextBusiness Goal(s)What is the business trying to achieve?“Increase demo bookings by 20%”
 Target AudienceWho is this design meant for?“SaaS founders & product managers, 30–45 yrs”
 Key MessageThe core message/USP to communicate“Cut PRD creation time by 40% with AI-powered templates”
Design ScopeDesign TypeCategory of design needed“Web Page (Landing)”
 DeliverablesExpected outputs“Homepage hero, product section, CTA banners”
 ConstraintsKnown limitations“Must align with existing brand colors & typography”
User UnderstandingUser NeedsWhat the user wants from this design“Clarity on product benefits in <2 mins”
 User Pain PointsFrustrations this design should address“Overwhelmed by text-heavy PRDs”
Success CriteriaSuccess MetricsHow success will be measured“Bounce rate < 40%, demo sign-ups > 50 per week”
 PriorityCriticality level“High”
LogisticsTimelineDelivery deadline“10 working days”
 DependenciesInputs required to proceed“Product screenshots, brand guideline PDF”
 Approval OwnerWho signs off“Design Lead + Client PM”

Usage Notes

  • Mandatory Fields: Project Name, Business Goal(s), Deliverables, Success Metrics.
  • To be filled by Requester (Client/PM/Account Manager).
  • Reviewed and validated by Design Lead before intake is marked complete.
  • Cross-reference with EPIC 1.1 SOP: End-to-End Design Intake Process.

SOP: End-to-End Design Intake Process

1. Purpose

To establish a consistent, structured, and execution-ready process for receiving, qualifying, and accepting design requests.

This ensures that no requirement is missed, stakeholders are aligned, and design begins only after clarity and validation.

2. Scope

  • Applies to all design requests — client projects, marketing collaterals, internal initiatives.
  • Covers intake through readiness validation (before UX planning begins).
  • Used by Design Team, Project Managers (PMs), and Client-facing roles (Sales/Account Managers).

3. Definitions

  • Design Intake: The structured process of capturing, reviewing, and validating a new design request.
  • Stakeholder Interview: A short, structured discussion with client/PM/SMEs to clarify context and constraints.
  • Discovery Alignment Call: A validation session where designers and stakeholders confirm the intake findings.

4. Step-by-Step Process

Stage A – Request Intake

  1. Request Logging
    • All requests must come through a standardized channel (ClickUp/Jira/MIC form).
    • Requester fills initial Design Brief Template (Doc Ref: EPIC 1.2).
  2. Categorization
    • Design Lead/PM classifies request: Web/App/Marketing/Product.
    • Assign priority: Critical / Standard / Low.
  3. Preliminary Screening
    • Check feasibility, deadlines, and alignment with available resources.

Stage B – Stakeholder Context Gathering

  1. Stakeholder Interview
    • Conduct structured interview using Stakeholder Interview Notes Template (Doc Ref: EPIC 1.3).
    • Capture: audience, goals, blockers, constraints, success expectations.
  2. Problem Framing
    • Translate inputs into structured Problem Types using Design Problem Typology Matrix (Doc Ref: EPIC 1.5).
    • Identify: Conversion / MVP / Redesign / Visual Fix / Campaign Design.

Stage C – Design Criteria Definition

  1. Persona Lite Creation
    • Build quick personas with Persona Lite Sheet (Discovery-Level) (Doc Ref: EPIC 1.6).
    • Capture goals, blockers, digital maturity, environment.
  2. Design Goals & Success Criteria
    • Define business outcomes (e.g., improve conversion by 15%), user outcomes (reduce clicks, better flow), team outcomes (handoff-ready Figma).
    • Use Design Goals & Success Criteria Sheet (Doc Ref: EPIC 1.7).

Stage D – Readiness Validation

  1. Completeness Check
    • Use Design Intake Completeness Checklist (Doc Ref: EPIC 1.8) before moving to UX.
    • Ensure: Brief filled, interview logged, goals defined, problem framed, persona + criteria done.
  2. Discovery Alignment Call
    • Run structured call with PM + stakeholders using SOP: Discovery Alignment Call (Doc Ref: EPIC 1.9).
    • Validate findings, close open questions, and align scope.
  3. Summary Presentation
  • Wrap findings in Discovery Summary Presentation Template (Doc Ref: EPIC 1.10).
  • Share internally for approval before UX planning.

5. Roles & Responsibilities

  • Design Lead: Owns the intake process, validates completeness, runs alignment call.
  • Designer Assigned: Fills templates, frames problem, drafts goals/persona.
  • PM/Account Manager: Provides client/business context, ensures timelines are realistic.
  • Stakeholders (Client/SMEs): Provide accurate requirements, confirm alignment in call.

6. Governance, Violations & Consequences

  • Any design project skipping intake cannot progress to UX mapping.
  • Violations (e.g., starting design with incomplete brief) will be flagged in project review and sent back to intake stage.
  • Repeated non-compliance → escalated to Delivery Head.

7. Review & Ownership

  • Owner: Design Lead.
  • Review Cycle: Quarterly (align with evolving project needs and template improvements).
  • Audit: Monthly sampling of intake requests for compliance.

8. Cross-References

  • EPIC 1.2 – Design Brief Template
  • EPIC 1.3 – Stakeholder Interview Notes Template
  • EPIC 1.5 – Design Problem Typology Matrix
  • EPIC 1.6 – Persona Lite Sheet
  • EPIC 1.7 – Design Goals & Success Criteria Sheet
  • EPIC 1.8 – Intake Completeness Checklist
  • EPIC 1.9 – Discovery Alignment Call SOP
  • EPIC 1.10 – Discovery Summary Presentation Template

SOP: CRM → Project Tool Migration

1. Purpose

The purpose of this SOP is to define the standardized process for transferring opportunity data from the CRM system into the chosen Project Management Tool. This ensures seamless continuity between Sales and Delivery, eliminates data gaps, and establishes the project workspace as the single source of truth for execution.

2. Scope

This SOP applies to:

  • All opportunities marked Closed Won in CRM.
  • Delivery Managers, Project Managers, Sales Ops, and Client Success Managers.
  • Migration into tools such as Jira, Asana, ClickUp, Trello, or MS Project depending on organizational setup.

3. Definitions

  • CRM: Sales system of record (HubSpot, Zoho, Salesforce, etc.).
  • Project Tool: Execution environment for Delivery team (Jira, Asana, etc.).
  • Migration: Process of transferring approved scope, deliverables, milestones, and contacts from CRM to the project tool.
  • Single Source of Truth (SSOT): The Project Tool becomes the authoritative record for delivery after migration.

4. Step-by-Step Process

A. Trigger for Migration

  • Client scope confirmed (see Scope Confirmation SOP).
  • Delivery Manager initiates migration within 2 working days.

B. Data Extraction from CRM

  1. Export relevant CRM data:
    • Opportunity details (name, value, close date).
    • Client contacts (primary, secondary, champion, economic buyer).
    • Signed proposal & contract documents.
    • MEDDPICC notes (if applicable).
    • Scope confirmation document.
    • Risks & dependencies from Sales handoff.

C. Project Tool Setup

  1. Create new project workspace with naming convention:
    • ClientName – ProjectName – StartMonthYear.
    • Example: “ABC Fintech – Cloud Migration – Sep2025”.
  2. Set project metadata:
    • Start date, end date.
    • Delivery Manager & Project Manager assignments.
    • Tags (industry, region, service line).

D. Task & Milestone Migration

  1. Import/enter milestones from scope confirmation:
    • Discovery, Build, UAT, Go-Live, Optimization.
  2. Break milestones into tasks with owners and deadlines.
  3. Assign resources (mapped from Kickoff Pack).
  4. Attach signed documents and repository links.

E. Access & Permissions

  1. Add internal team members (Delivery, QA, Design, Dev).
  2. Add client stakeholders with appropriate permissions (view/comment only unless otherwise agreed).
  3. Integrate communication channels (Slack/Teams).

F. Validation & Transition

  1. Delivery Manager verifies completeness of migrated data.
  2. Project Manager confirms task ownership and timelines.
  3. Sales Rep verifies client context accuracy during transition.
  4. Project workspace officially becomes system of record.
  5. CRM opportunity marked “Closed → Migrated.”

5. Roles & Responsibilities

  • Delivery Manager: Owns migration, ensures accuracy, validates completeness.
  • Project Manager: Creates tasks, milestones, and assigns resources.
  • Sales Ops: Provides CRM data exports and supports migration templates.
  • Sales Rep: Confirms client context during initial migration.
  • Client Success Manager: Ensures client-facing access setup.

6. Governance, Violations & Consequences

  • Migration must be completed within 2 working days post-scope confirmation.
  • Missing or incorrect data → flagged in onboarding audit.
  • Delivery cannot begin execution until migration validated.
  • Projects without formal migration → escalated to Head of Delivery.

7. Review & Ownership

  • Document Owner: Head of Delivery.
  • Review Cycle: Quarterly.
  • Version Control: Migration template/checklist maintained by Sales Ops.

SOP: Scope Confirmation

1. Purpose

The purpose of this SOP is to ensure that project scope is explicitly validated and agreed upon by both client and delivery teams after kickoff. This prevents misunderstandings, manages change effectively, and provides a baseline for execution.

2. Scope

This SOP applies to:

  • All projects post-kickoff where execution is about to begin.
  • Delivery Managers, Project Managers, Pre-Sales Consultants, and Client Stakeholders.
  • IT Services & SaaS engagements across SMB, mid-market, and enterprise clients.

3. Definitions

  • Scope of Work (SOW): Document outlining agreed activities, deliverables, assumptions, and exclusions.
  • Scope Confirmation Document: Final validated scope shared post-kickoff, based on SOW and client discussions.
  • Change Control Process: Formal mechanism for managing any deviations from agreed scope.

4. Step-by-Step Process

A. Trigger for Scope Confirmation

  • Client kickoff meeting completed (see Client Onboarding Meeting SOP).
  • All parties aligned on high-level goals, deliverables, and timelines.

B. Review of Scope (Internal)

  1. Delivery Manager reviews signed proposal and SOW.
  2. Project Manager extracts key deliverables and milestones.
  3. Pre-Sales (if involved) validates technical feasibility.
  4. Document potential gaps, dependencies, or risks.

C. Drafting Scope Confirmation Document

  1. Structure must include:
    • Project overview (objectives, context).
    • Final deliverables list.
    • Exclusions (not part of scope).
    • Timeline & milestones (high-level).
    • Roles & responsibilities (client vs. internal).
    • Dependencies/assumptions.
    • Risk register (initial version).
  2. Use standardized template maintained in repository.

D. Client Validation & Sign-Off

  1. Delivery Manager shares draft scope confirmation document with client.
  2. Conduct a short review call to walk through scope line by line.
  3. Address clarifications and update if needed.
  4. Secure formal approval via:
    • Client signature on scope confirmation document, OR
    • Email confirmation attached to repository.

E. Post-Sign-Off Actions

  1. Store signed scope confirmation document in Project Tool folder.
  2. Link approved scope to CRM opportunity and Delivery workspace.
  3. Any changes raised later → handled through Change Control Policy.
  4. Project execution begins based on confirmed scope.

5. Roles & Responsibilities

  • Delivery Manager: Leads scope confirmation process, obtains client approval.
  • Project Manager: Extracts deliverables, timelines, and prepares scope draft.
  • Pre-Sales Consultant: Provides technical validation if scope is complex.
  • Client Stakeholders: Validate and approve scope.
  • Sales Rep: Supports clarification during first month if disputes arise.

6. Governance, Violations & Consequences

  • Project execution cannot begin until scope confirmation is signed.
  • Unapproved changes → automatically escalated to Change Control process.
  • Missing client confirmation → project flagged “On Hold” in Project Tool.

7. Review & Ownership

  • Document Owner: Head of Delivery.
  • Review Cycle: Per project; quarterly for template updates.
  • Version Control: Scope confirmation template maintained in repository.

SOP: Post-Kickoff Communication

1. Purpose

The purpose of this SOP is to establish clear and consistent communication immediately after the client onboarding meeting (kickoff). Timely and structured follow-up ensures that clients feel supported, expectations are reinforced, and collaboration begins smoothly.

2. Scope

This SOP applies to:

  • All client projects post-kickoff meeting.
  • Delivery Managers, Project Managers, Client Success Managers, and Client Stakeholders.
  • Communication via email, collaboration tools (Slack/Teams), and project dashboards (Jira/Asana).

3. Definitions

  • Kickoff Summary Email: Formal email recap sent to all client stakeholders post-kickoff.
  • Collaboration Tools: Digital platforms for communication and project tracking.
  • Engagement Cadence: Agreed rhythm of communication (status updates, calls, escalations).

4. Step-by-Step Process

A. Immediate Post-Kickoff Actions (Day 0–1)

  1. Delivery Manager circulates Kickoff Summary Email within 24 hours:
    • Recap of meeting agenda and decisions.
    • Final scope highlights and milestone dates.
    • Roles/responsibilities and escalation paths.
    • Agreed communication cadence.
    • Next steps + deadlines.
  2. Attach Kickoff Deck and meeting notes.
  3. Upload email and attachments to Project Tool repository.

B. Collaboration Setup (Day 1–2)

  1. Create client-specific channels (Slack/Teams/Email list).
  2. Share project dashboard access (Jira/Asana/ClickUp).
  3. Provide shared folder link for document exchange (Drive/SharePoint).
  4. Introduce CSM as ongoing point of contact for relationship support.

C. Engagement Cadence

  1. Weekly status updates → Project Manager → via email or dashboard.
  2. Monthly review calls → Delivery Manager + Client stakeholders.
  3. Escalations → Direct to Delivery Manager, with fallback to Head of Delivery.
  4. CSM conducts quarterly business reviews (if applicable).

D. Internal Follow-Up

  1. Delivery team debrief post-kickoff → validate alignment.
  2. Document risks, action items, and assign owners.
  3. Sales Rep remains in loop for first 30 days for relationship continuity.

5. Roles & Responsibilities

  • Delivery Manager: Owns post-kickoff communication, sends summary, ensures cadence.
  • Project Manager: Shares updates, manages project dashboard.
  • Client Success Manager: Manages long-term engagement and periodic reviews.
  • Sales Rep: Supports initial relationship continuity.
  • Client Stakeholders: Engage with updates, raise issues proactively.

6. Governance, Violations & Consequences

  • Kickoff summary email missing → flagged by QA checklist.
  • Collaboration channels not set up within 48 hours → escalated to Head of Delivery.
  • Missed status updates or reviews → non-compliance noted in performance review.

7. Review & Ownership

  • Document Owner: Head of Delivery.
  • Review Cycle: Quarterly.
  • Version Control: Communication templates stored in Repository (email, Slack message formats).

SOP: Client Onboarding Meeting

1. Purpose

The purpose of this SOP is to define a structured approach for conducting the client onboarding (kickoff) meeting. This ensures alignment on objectives, scope, communication norms, and roles between client and delivery teams, building trust and confidence at the project start.

2. Scope

This SOP applies to:

  • All new projects where contracts have been signed and handoff completed.
  • Delivery Managers, Project Managers, Client Success Managers, Sales Reps, and Client Stakeholders.
  • IT Services & SaaS engagements across SMB, mid-market, and enterprise accounts.

3. Definitions

  • Onboarding Meeting / Kickoff: The first formal client-facing meeting post-deal closure.
  • Client Success Manager (CSM): Ongoing relationship owner for client satisfaction beyond project execution.
  • Onboarding Agenda: Structured set of topics ensuring both internal and client teams align.

4. Step-by-Step Process

A. Pre-Meeting Preparation

  1. Delivery Manager finalizes Kickoff Pack (see Kickoff Preparation SOP).
  2. Confirm meeting participants:
    • Internal: Delivery team, Project Manager, Sales Rep (optional), CSM.
    • Client: Key stakeholders, decision makers, project champions.
  3. Share Agenda with client at least 2 working days in advance.

B. Suggested Agenda Structure

  1. Welcome & Introductions
    • Introduce both teams and their roles.
    • Acknowledge Sales → Delivery transition.
  2. Client Objectives Recap
    • Reiterate client’s goals and success metrics.
    • Confirm shared understanding of challenges.
  3. Scope & Deliverables Review
    • Walk through signed Scope of Work (SOW).
    • Highlight inclusions, exclusions, and assumptions.
  4. Timeline & Milestones
    • Present draft project plan.
    • Align on major milestones and delivery checkpoints.
  5. Collaboration & Communication Norms
    • Confirm preferred tools (Slack, Teams, Jira, Asana).
    • Define reporting cadence (weekly status calls, monthly reviews).
    • Share escalation paths.
  6. Roles & Responsibilities
    • Confirm internal team roles (Delivery Lead, PM, QA, Dev).
    • Map client-side responsibilities.
  7. Risks & Mitigation
    • Share known risks from handoff.
    • Agree on escalation and change control processes.
  8. Next Steps
    • Confirm immediate next actions (scope confirmation, access setup, resource scheduling).

C. Post-Meeting Actions

  1. Delivery Manager circulates Kickoff Summary Email:
    • Meeting notes
    • Finalized scope highlights
    • Updated timeline & milestones
    • Responsibilities matrix
    • Next steps with deadlines
  2. Upload summary + deck to Project Tool repository.
  3. Update CRM opportunity → mark “Onboarding Completed.”

5. Roles & Responsibilities

  • Delivery Manager: Leads meeting, ensures agenda completion, sends summary.
  • Project Manager: Presents timeline, milestones, and execution plan.
  • Client Success Manager: Introduces engagement continuity, manages long-term relationship.
  • Sales Rep: Provides context, attends for relationship continuity (optional).
  • Client Stakeholders: Share objectives, validate expectations, and agree to communication norms.

6. Governance, Violations & Consequences

  • Kickoff must be conducted within 5 working days of contract signing.
  • Missing summary email → flagged in Delivery QA checklist.
  • Failure to clarify scope or communication norms → risks escalated to Head of Delivery.

7. Review & Ownership

  • Document Owner: Head of Delivery.
  • Review Cycle: Quarterly.
  • Version Control: Onboarding Agenda Template maintained in Project Tool repository.

SOP: Kickoff Preparation

1. Purpose

The purpose of this SOP is to ensure structured internal preparation before the client kickoff meeting. Proper preparation enables the Delivery team to enter the client kickoff with clarity, aligned resources, and realistic expectations, setting the foundation for a successful project launch.

2. Scope

This SOP applies to:

  • All projects transitioning from Sales to Delivery post-handoff.
  • Delivery Managers, Pre-Sales Consultants, Project Managers, and Client Success Managers.
  • IT Services & SaaS projects across SMB, mid-market, and enterprise clients.

3. Definitions

  • Kickoff Meeting: The first formal client-facing meeting after deal closure, where project plan, scope, and communication norms are introduced.
  • Kickoff Pack: Internal preparation document containing scope, milestones, risks, and resourcing plan.
  • Resource Plan: Allocation of delivery team members, tools, and timelines required to execute the project.

4. Step-by-Step Process

A. Trigger for Kickoff Preparation

  • Sales → Delivery Handoff completed (see Sales → Delivery Handoff SOP).
  • Delivery Manager officially takes ownership of client.

B. Internal Review of Handoff Pack

  1. Delivery Manager reviews:
    • Signed proposal & contract.
    • Scope of Work (SOW).
    • Client goals, pain points, and success metrics.
    • Risks flagged during sales cycle.
  2. Pre-Sales validates any technical commitments.
  3. Sales Rep remains available for clarification.

C. Kickoff Pack Creation

  1. Delivery Manager prepares Kickoff Pack including:
    • Project charter summary.
    • Scope highlights and exclusions.
    • Timeline & milestone draft.
    • Roles & responsibilities (both client and internal).
    • Communication plan draft (cadence, tools).
    • Risk register (known risks + mitigation).
  2. Store Kickoff Pack in Project Tool folder.

D. Resource Planning

  1. Identify delivery team roles required (e.g., Dev, QA, Design, PM).
  2. Confirm resource availability with HR/Resource Manager.
  3. Assign project team members in Project Tool.
  4. Set up collaboration spaces (Slack/Teams channel, Drive folder, Jira/Asana board).

E. Kickoff Meeting Scheduling

  1. Delivery Manager coordinates with client POC to schedule kickoff within 5 working days of deal closure.
  2. Send calendar invite with draft agenda:
    • Introductions
    • Recap of objectives
    • Scope & milestones
    • Communication norms
    • Next steps

5. Roles & Responsibilities

  • Delivery Manager: Owns kickoff preparation, creates Kickoff Pack, schedules meeting.
  • Pre-Sales Consultant: Validates technical feasibility and commitments.
  • Project Manager (if assigned): Prepares execution milestones and delivery plan.
  • Sales Rep: Supports context clarification, attends kickoff if needed.
  • Client Success Manager: Prepares engagement continuity plan.

6. Governance, Violations & Consequences

  • Kickoff must be scheduled within 5 working days of deal closure.
  • Missing Kickoff Pack → flagged in Delivery QA review.
  • Starting client kickoff without resource plan → escalated to Head of Delivery.

7. Review & Ownership

  • Document Owner: Head of Delivery.
  • Review Cycle: Quarterly or after major project onboarding.
  • Version Control: Kickoff Pack template maintained in Project Tool repository.

SOP: Sales → Delivery Handoff

1. Purpose

The purpose of this SOP is to ensure a smooth and structured transition of client ownership from the Sales team to the Delivery team after contract closure. This minimizes knowledge loss, maintains client confidence, and enables Delivery to start with complete context.

2. Scope

This SOP applies to:

  • All deals marked Closed Won in CRM.
  • Sales Representatives, Sales Managers, Delivery Managers, Pre-Sales Consultants, and Client Success/Account Managers.
  • IT Services & SaaS engagements across SMB, mid-market, and enterprise clients.

3. Definitions

  • Handoff Pack: A standardized bundle of documents capturing discovery notes, proposal, MEDDPICC details, client context, and scope.
  • Internal Handoff Call: A structured meeting between Sales and Delivery before client kickoff.
  • Ownership Transition: Official shift of responsibility from Sales to Delivery, logged in CRM and project tools.

4. Step-by-Step Process

A. Trigger for Handoff

  • Deal status updated to Closed Won in CRM.
  • Sales Rep initiates the handoff process within 48 hours.

B. Prepare Handoff Pack (Sales Rep)

  1. Collect and attach in CRM:
    • Discovery notes + MEDDPICC qualification.
    • Final proposal + signed contract/MSA.
    • Scope of Work (SOW) & assumptions.
    • Client org chart + key stakeholders.
    • Decision criteria & buying drivers.
    • Risks flagged during sales cycle.
  2. Save bundle as ClientName – Handoff Pack – Date.

C. Internal Handoff Call

  1. Schedule call with Delivery Manager, Pre-Sales (if relevant), and Sales Manager.
  2. Agenda:
    • Client context recap (goals, challenges, deal drivers).
    • Walkthrough of signed scope and commitments.
    • Known risks and dependencies.
    • Next steps: kickoff preparation tasks.
  3. Delivery Manager acknowledges ownership of client.

D. Client Communication (Warm Handoff)

  1. Sales Rep sends a Thank You + Next Steps email to client:
    • Acknowledge deal closure.
    • Introduce Delivery Manager as new point of contact.
    • Share timeline for kickoff call scheduling.
  2. Delivery Manager replies/joins email thread to establish rapport.

E. Ownership Transition in Systems

  1. CRM → Opportunity marked “Closed Won.”
  2. Owner field updated from Sales Rep → Delivery Manager / Project Owner.
  3. Project workspace (tool like Jira, Asana, Monday, etc.) created and linked.
  4. Sales Rep remains tagged as “Relationship Support.”

5. Roles & Responsibilities

  • Sales Rep: Prepares Handoff Pack, schedules handoff call, introduces Delivery to client.
  • Delivery Manager: Reviews pack, takes ownership, and leads next phases.
  • Pre-Sales Consultant: Provides technical context (if part of deal).
  • Sales Manager: Ensures compliance and smooth transition.
  • Client Success Manager: Engages post-handoff as ongoing relationship point.

6. Governance, Violations & Consequences

  • Handoff must be completed within 5 working days of deal closure.
  • Missing/incomplete Handoff Pack → flagged by Sales Ops.
  • If Delivery team starts work without formal handoff → escalated to Head of Sales.

7. Review & Ownership

  • Document Owner: Head of Sales.
  • Review Cycle: Quarterly.
  • Version Control: Handoff Pack template maintained by Sales Ops.