# Handoffs and renewals Contracts for every team boundary from first request to renewal, and the renewal cycle model. Required fields per handoff are in [../assets/handoff-packet-checklist.md](../assets/handoff-packet-checklist.md); clocks and targets in [clocks-and-slas.md](clocks-and-slas.md). ## The handoff contract Every handoff states: - Trigger: the field and value that starts it (lifecycle reaches MQL, deal reaches closed won). - Sender packet: the gate fields that must be filled before the handoff counts, and the context fields that should be. - Receiver obligation: an explicit accept or reject with a reason from the controlled list, inside the SLA. - Clock: start field, stop field, calendar, target. - Breach action: who is told at which threshold, and who takes the work. - Evidence: the report or view that shows compliance, including unanswered handoffs. - Owners on both sides, by role. Obligations run both ways. Marketing owns the quality of what it sends: a rejection rate above the agreed level by reason is marketing's problem to fix. Sales owns the disposition: every request gets accepted or rejected with a reason, and silence counts as a breach. ## Marketing to sales - Trigger: MQL, or a hand-raise request, after exclusions. - Packet gate: request class, received_at, source snapshot, fit fields that passed the gate, the hand-raise text or the engagement reasons behind the score. - Receiver: the SDR accepts or rejects with a reason: a custom lead status value such as ACCEPTED, or, on HubSpot lead records, an sdr_decision property, because the default lead stages have no accept step. disposition_at is stamped the first time the decision is set, and the MQL disposition SLA stops there. - Reasons, at most 12, for example: no project, no budget authority, student or job seeker, existing customer, partner, competitor, support request, duplicate, bad contact data, wrong region, other. If "other" exceeds 10% of rejections in a month, rewrite the list. - Recycle: follow-up status BAD_TIMING with recycle_reason and recycle_date. Lifecycle does not move. - SLA proposal: hand-raise first response 15 business minutes; MQL disposition 1 business day. ## SDR to AE - Trigger: the discovery meeting is held (not booked). - Opportunity creation criteria, written: the problem, a timeline, the buying role of the contact, and a next step agreed with the buyer. A booked meeting alone does not create an opportunity. - The buying contact is associated to the deal (Salesforce: added as a contact role). Without it, contact lifecycle never reaches Opportunity or Customer and person-level conversion is undercounted (FM23 in [failure-modes.md](failure-modes.md)). - Lost deals carry closed_lost_reason from a controlled list of at most 12 values; if "other" exceeds 10% of losses in a month, rewrite the list (R06). - Receiver: the AE accepts, which creates the opportunity, or rejects with a reason and sends it back with notes. - In Salesforce, lead conversion is the boundary. Map request-level fields (request ID, source snapshot, hand-raise reason) to the Opportunity, because conversion keeps populated fields on an existing Contact and the latest campaign becomes Primary Campaign Source. - SLA proposal: AE decision within 1 business day after the meeting. ## Sales to customer success - Trigger: deal reaches closed won. - Gate fields (the exception view checks them daily): customer goals and success criteria, stakeholders with roles, commitments made during the sale, technical requirements, contract start, renewal date and notice deadline, billing setup status, the CS owner. - Context fields: competitors evaluated, risks raised, implementation partner. - Receiver: customer success accepts within 2 business days or returns the packet with the missing items. The clock pauses only through a recorded return, never silently. - Kickoff scheduled within 5 business days (proposal). Time to first value is a separate measure with its own definition. - HubSpot documents required stage properties for manual creates and moves in the UI only, so a daily exception view guards the packet. A closed-won deal written by an import, integration, workflow or API call is checked there. ## Customer success to sales (expansion) - Trigger: a recorded expansion signal (seat limit reached, new team request, upgrade question), not a usage spike alone. - Packet: the signal, its observed_at, the account context and the current renewal date. - Receiver: the account owner creates an expansion pipeline opportunity or declines with a reason. - Protect account ownership. Lifecycle stays Customer. A customer's new request routes to the account owner before any rotation. ## Renewal cycle record Track renewal as one record per cycle, never as a single date on the company. Scope: - Cycle records with the 120-day owner rule apply to negotiated or annual contracts, or to contracts above an annual value the spec names. - Self-serve monthly and card-billed plans get no cycle owner. One exception owner and queue handle failed payments, scheduled cancellations and downgrades, and R10 counts exceptions that have no owner. Owned cycles for these plans fill the coverage report with work nobody does. Cycle rules: - One ID per cycle, related to the account, the contract and the billing subscription. A changed date revises the same cycle and bumps its schedule revision. - Keep these dates separate, because each drives different work: commercial decision date, contract notice deadline, service period boundary, billing date, payment due date. - One accountable owner per cycle. Other teams own actions (value review, invoicing, access), not the cycle. - Separate states: commercial (review required, agreed, declined, unresolved), billing (not invoiced, invoiced, paid, past due) and access (active, scheduled to end, ended). An agreed renewal with an unpaid invoice belongs in a different queue from a declined one. - Timeline proposal for a negotiated annual renewal, counted back from the commercial decision date: 120 days, owner and next action set; 90 days, buyer, scope and notice deadline confirmed; 60 days, value review done; 30 days, commercial changes and approvals resolved. If 30 days before the notice deadline falls earlier than the 120-day step, start the timeline there and move every later step earlier by the same number of days. - Billing events are notifications. Read the current subscription state before acting, because webhooks can be duplicated and arrive out of order. - A schedule revision invalidates pending tasks and queued messages built on the old dates. Completed history stays. - The next cycle is created once, after the outcome condition (agreed and reconciled with billing and access), and never from an upcoming invoice event alone. Stripe sends no upcoming-invoice event for send_invoice subscriptions. Renewal coverage report: cycles inside the review window without an owner, a next action or a due date; cycles whose notice deadline arrives before the next scheduled task; decisions recorded after the notice deadline; self-serve exceptions with no owner. ## Owner changes and offboarding - Before a user is deactivated, reassign their open requests, opportunities and renewal cycles by status to named people or queues. Never leave records on an inactive user. - Keep received_at and the original clock fields. Record the reason for reassignment and the effective time. - Check every rotation and assignment rule that names the departing user. ## Partner-sourced requests and existing customers - Partner-sourced: route to the partner manager with the partner ID and the registration date. The SLA is the partner agreement's, written into the register. - Existing customer's new request: keep the account owner or customer success owner. Count it as a request episode for the expansion or support path, never as a new MQL.