Practitioner Reference Library: Templates, Checklists, and Artifacts

Practitioner Reference Library: Templates, Checklists, and Artifacts

Deal Desk Playbook: Executive-ready deal summary showing concessions, economics, key risks, approval options, conditions, and expiration for faster decisions.

A deal desk scales when the work is reusable. Most slowdowns are not caused by hard decisions; they are caused by missing inputs, unclear packaging, and forgotten conditions. The toolkit in this chapter is meant to be operational: copy it into your knowledge base, embed it in CRM/CPQ/CLM, and use it to reduce rework while tightening audit readiness. Each artifact is designed to make “the right way” the easiest way—submit clean inputs, route in parallel, decide once, and record what was decided so you do not re-litigate it at renewal, quarter-end, or in an audit.

16.1 Master Template Library: What to Standardize vs. Tailor by Segment

The fastest desks do not have the most documents; they have the smallest set of documents that everyone trusts. Start by deciding what is globally standard and what is variable by segment or region. If everything varies, you get inconsistency and precedent drift. If nothing varies, you get workarounds because real market requirements differ. The pragmatic approach is to standardize the “container” (the template structure and decision fields) and tailor the “content” (the numbers and approved variants) through versioned modules.

Standardize enterprise-wide: these artifacts should look the same everywhere because they protect speed, comparability, and auditability. If you want reliable reporting and consistent delegated authority, these are non-negotiable.

  • Intake structure: base fields, conditional questions, required attachments, completeness rules, bounce-back reason codes.
  • Deal snapshot: the one-page internal brief used for cross-functional alignment and escalations.
  • Exception request formats: pricing, payment terms, services inclusion, and risk exceptions packaged the same way.
  • Decision memo: the one-page executive summary that presents options as complete packages.
  • Approval record fields: approver, tier, decision, conditions, expiration, re-approval triggers.
  • Reason codes: exception categories, pause reasons, rework reasons, leakage classifications.
  • Governance artifacts: approval matrix structure, RACI structure, meeting agendas, decision log format.

Tailor as controlled variants: tailor only what is truly different, and do it as modules with explicit ownership, effective dates, and clear eligibility rules. Tailoring should never happen by rewriting the core template.

  • Pricing: discount corridors, floors, renewal uplift policy, and approved stacking rules by segment/channel.
  • Coverage: size thresholds and trigger rules where volume or risk differs (enterprise vs. SMB, direct vs. partner).
  • Packaging: bundles, services tiers, SLA tiers, and support tiers aligned to cost-to-serve.
  • Contract modules: statutory clauses, vertical addenda, and security/privacy variants where required.
  • Credit/cash standards: payment-term limits and credit-review triggers that reflect local practice.

Deciding what belongs where: use a simple test. If a field is required to route work, measure performance, or enforce delegated authority, it belongs in the global core. If a value changes because the market or regulation is different, it belongs in a module. If you cannot explain the reason for variance in one sentence, do not allow variance; you will create complexity without benefit.

How to organize the library: build “global cores” plus “segment modules.” A global core is the template skeleton and required fields. A module supplies segment-specific values (corridors, thresholds, approved addenda) and is referenced via links so updates propagate everywhere. Avoid copying a global template into a region folder and editing it; that creates shadow standards and inconsistent decisions. Instead, keep one global template page and add a module section that is selected by segment/region.

Minimum viable library: publish these first. They remove the biggest drivers of rework and escalation and allow you to run the desk with credibility.

  • Charter + coverage triggers: what the desk does, when it is required, and SLAs by lane.
  • Intake package: intake form + completeness gate + attachment list + bounce-back message.
  • Deal snapshot: one-page internal brief.
  • Commercial exceptions: discount exception request, payment terms exception request, and competitive match request.
  • Governance: approval matrix, RACI, and daily/weekly/monthly agenda templates.
  • Decision memo: escalation packaging template that executives will read.
  • Close verification: “quote matches approval” and “contract matches approval” checklist.
  • Monthly exceptions pack: Pareto of exceptions, cycle-time tail drivers, leakage sample, action list.

Template control header: put this at the top of every artifact so it is governable and searchable. The control header is also what allows safe delegation, because approvers can trust they are using the current standard.

  • Owner: accountable role for accuracy and upkeep.
  • Approver: role that signs off changes (Finance for pricing, Legal for clauses, Delivery for SLAs).
  • Version + effective date: and how in-flight deals are handled.
  • Where used: link to the CRM form/CPQ object/CLM library/report.
  • Change log: what changed and what behavior should change.

Lifecycle discipline: treat templates like software. Draft: create and test with a small pilot. Publish: move to the knowledge base and embed links in tools. Adopt: train and enforce through completeness gates and quote/contract controls. Retire: archive old versions so they cannot be used accidentally. Template sprawl happens when “retire” is missing.

Set naming conventions to eliminate ambiguity (for example, “DD-INTAKE-001,” “DD-PRICE-EXC-002,” “DD-GOV-LOG-003”). When sellers can find the current standard in seconds, they stop hoarding old attachments, and the desk stops re-teaching basics.

16.2 Deal Intake Package: Intake Form, Deal Snapshot, Required Attachments

Intake is the single highest-leverage place to improve speed. The purpose is not to collect “nice to have” details; it is to capture the few inputs that enable parallel routing, reduce late discovery, and prevent rework. Design intake around triggers: a short base form plus conditional questions that appear only when a non-standard flag is selected.

Minimum deal record: these fields should exist on every covered opportunity, even if the desk is not engaged yet. They are the foundation for automation and analytics.

  • Account and opportunity identifiers: account hierarchy, opportunity ID, owner, manager.
  • Segmentation: segment, region, channel, vertical (if applicable).
  • Deal type: new, expansion, renewal, save, or migration.
  • Commercial basics: products, term, expected close date, customer deadline.
  • Quote linkage: quote ID/version and whether a proposal has been sent.

Intake form base fields: keep these consistent across all deals. The base form should take only a few minutes to complete.

  • Deal identity: account, opportunity ID, seller, manager, segment, region, channel.
  • Offer: products/SKUs, quantities, deal type, term, start date assumption.
  • Timeline: customer decision date, proposal deadline, internal close date.
  • Non-standard flags: pricing, cash terms, services, contract terms, security/privacy, delivery commitments.
  • Economics quick view: list/standard price, proposed price, services price (if any).
  • Context: competitive situation and a one-to-two sentence value summary.

Conditional questions by trigger: these should be numeric, specific, and easy to validate. If a question cannot be answered without a meeting, it is too complex for intake.

  • Pricing exception: requested net price/discount, category, evidence type, proposed give-get.
  • Payment terms exception: requested net days, billing cadence, invoice trigger, proposed compensation.
  • Free/discounted services: scope, estimated hours, requested timeline, delivery feasibility owner.
  • Customer paper/terms: redline upload, clause families impacted, customer “must-haves,” any deadlines from procurement.
  • Security/privacy: data type, DPA required, questionnaire status, residency requirement, specific deviations requested.
  • Delivery commitments: requested go-live date, SLA changes, penalties/credits requested, dependency risks.

Definition of complete: make this a hard gate. The SLA clock starts only when complete, and incomplete requests are returned within hours with a missing-items list. This is how you raise first-pass yield and shrink the cycle-time tail.

  • Core fields present: segment, deal type, term, and deadlines are filled in.
  • Triggered fields present: every selected flag has the required details.
  • Ask is explicit: price, net days, hours, or clause change is clearly stated.
  • Attachments included: required documents are uploaded and readable.
  • Trade proposed: beyond-guardrail asks include at least one give-get.

Lane routing cues: include these as a quick self-check for sellers and managers. You can also use them as rules in workflow automation.

  • Fast lane: standard terms, within target band, standard payment terms, no included custom services.
  • Complex lane: multiple levers in play but within playbooks (for example, discount within approved flex with a standard give-get).
  • Exception lane: below-floor economics, customer paper with outside-playbook clauses, novel security commitments, or non-standard SLAs/penalties.

Deal snapshot one-pager: this is the internal alignment tool. It should be updated as assumptions change, and it should be the single summary used for escalation and cross-functional reviews.

  • What we’re selling: offer, structure, term, and any ramps/commits.
  • What’s non-standard: deviations by lever (price, cash, services, terms, security, delivery).
  • Economics: list vs proposed and the effective concession summary (including free services).
  • Risks: top risks and mitigations (caps, fallbacks, feasibility checks).
  • Decision needed: what approval is required, by when, and the recommended option.
  • Customer-ready options: two to three packages the seller can propose.

Required attachments by request type: keep this short and enforce it consistently. If you enforce it sometimes, you will train the field to gamble on incomplete submissions.

  • Pricing/competitive: customer requirement or competitor quote, plus scope comparability note.
  • Customer paper: redlined contract/addendum; editable format when possible.
  • Security/privacy: questionnaire or link, DPA/security addendum, residency requirement statement.
  • Services: SOW draft or scope bullets with assumptions, success criteria, and timeline.
  • Cash/credit: requested billing schedule, PO process notes, payment history if relevant.

Return-for-completeness message: use a standard response so sellers experience fairness and learn quickly. Returning incomplete requests is one of the best “enablement” tools you have.

  • Status: “Returned – incomplete (SLA not started).”
  • Missing items: list the exact fields/attachments needed.
  • Why: one sentence explaining routing/approval impact.
  • Next step: where to update and expect SLA once complete.
  • Reason code: select one bounce-back reason for analytics.

Two add-ons prevent late surprises. Early trigger questions: five discovery prompts (customer paper, regulated data, required go-live date, SLA penalties, non-standard invoicing). Scope boundaries: for any included services, require “not included” items and a change-order reference. These habits reduce late discovery and shorten the 90th percentile tail without adding desk headcount.

16.3 Pricing and Exception Requests: Discount Request, Competitive Match, Approvals

Standardizing exception requests is one of the fastest ways to increase delegation. Approvers say “no” slowly when they do not trust the inputs or cannot see the trade. Approvers say “yes” quickly when the request is packaged the same way every time: numeric ask, evidence, give-get, economics delta, and expiration. Use the templates below as forms in CRM, not as emails, so the approval record is automatically linked to the quote and contract.

Discount exception request: use this any time the quote is outside the self-serve band or changes the renewal base.

  • Ask: requested net price/discount, including free months, waived fees, credits, or price holds.
  • Baseline: list price, target band, and floor for the segment; quote version and configuration.
  • Category: competitive displacement, strategic logo, volume/scale, term/commit, scope trade, renewal save.
  • Evidence: what proof exists and what is comparable (scope/term/support); include date.
  • Give-get: term, prepay, minimums, scope limits, standard terms, reference rights.
  • Economics delta: margin/contribution band impact and any cost-to-serve changes (services/support).
  • Precedent control: expiration date, scope limits, and renewal base statement if relevant.
  • Fallback: what will be offered if denied.

Payment terms exception request: this is where value often leaks because it feels “less visible” than discount. Treat it as an economic lever with give-get requirements.

  • Ask: requested net days and billing cadence (annual/quarterly/monthly).
  • Invoice trigger: signature, go-live, acceptance, or milestone; include customer rationale.
  • Cash impact: estimated cash delay versus standard terms (simple band: low/medium/high).
  • Give-get: price protection (less discount), longer term, partial upfront, or enforceable milestones.
  • Credit trigger: whether credit review is required (based on your policy threshold).
  • Expiration: whether this is a one-time exception or a standard term for the account.

Free/discounted services request: services are one of the most common “hidden concessions.” Capture them with the same discipline as pricing.

  • Ask: included hours or discounted rate and the specific deliverables.
  • Assumptions: customer responsibilities, dependencies, and what is explicitly excluded.
  • Timeline: requested start/go-live and what must be true to hit it.
  • Feasibility: delivery owner confirms resourcing and risk (yes/no + notes).
  • Give-get: higher product price, longer term, or scope discipline; avoid “free” without trade.
  • Change control: how additional work will be priced and approved.

Give-get menu: embed as picklists so the field proposes trades consistently and the desk can analyze patterns.

  • Cash: annual prepay, partial upfront, shorter net days, milestone billing.
  • Commitment: longer term, non-cancelable period, enforceable ramp/true-up.
  • Scope discipline: standard package, fewer integrations, standard SLA tier.
  • Renewal protection: base on final-year rate, uplifts per policy, expansions at current rates.
  • Customer value capture: reference, logo, case study, joint webinar (time-bound).

Competitive match request: require comparability and time bounds so “match” does not become a permanent precedent.

  • Competitor + evidence: attach competitor quote/requirement with date.
  • Comparability: what is included/excluded versus our offer (scope, services, term, support).
  • Requested response: match price, match structure, or match total package.
  • Trade required: what we must receive to match (term, prepay, scope limits, standard terms).
  • Validity: match offer expiration and quote validity window.
  • Escalation: below-floor or prohibited-term matches route to exception lane.

Approval record: the structured output that makes conditions enforceable in CPQ/CLM and prevents “approved in chat, forgotten in the quote.”

  • Decision: approve / approve with conditions / deny.
  • Approved package: net price, term, billing cadence, payment terms, services inclusions.
  • Conditions: explicit “yes, if” language to write into quote/order form and contract exhibits.
  • Expiration + triggers: when approval expires and what changes require re-approval.
  • Links: quote version, attachments/evidence, decision memo (if applicable).

Pricing exception playbook outline: create one page per top exception category so responses are consistent and coaching is easier.

  • Intent: what customers usually mean when they ask.
  • Standard + fallback: approved bands and what can move without escalation.
  • Trades: preferred give-gets, in priority order.
  • Escalate when: objective triggers for Tier 2/Tier 3 and what must be included.
  • Seller language: customer-ready sentences to frame the trade.

Exception request quality check: before routing an exception for approval, verify five things. First, the CPQ quote version matches the ask (same SKUs, term, billing schedule). Second, the give-get is enforceable in writing, not a vague promise. Third, the conditions can be implemented in tools (fields, order form language, CLM fallbacks). Fourth, the exception is scoped and time-bound (customer, products, volumes, expiration). Fifth, the seller has a denial path—what to propose if the exception is rejected. If any item is missing, return the request for completion rather than debating it. This protects approver time and keeps desk SLAs credible, especially during quarter-end peaks.

Operational rule: for exception-lane economics, require at least two customer-ready options. Options prevent internal all-or-nothing debates and keep negotiations moving if a stretch ask is denied. Over time, the best options become standard packages and exception volume drops.

16.4 Governance Artifacts: Approval Matrix, RACI, Meeting Agendas, Decision Log

Governance artifacts make decision rights explicit and keep work parallel. They should be short enough to use every week, and structured enough to embed into tools. The templates below are intentionally skeletal; your job is to fill in the thresholds and owners once, then enforce them consistently.

Approval matrix skeleton: build as automation-ready rows. If you cannot write a rule as “if X, then Y,” it will not scale.

  • Lever: pricing, cash, services, terms, security/privacy, delivery commitments.
  • Trigger: objective threshold that changes approval tier.
  • Tier + approver: delegated role plus backup coverage.
  • Required inputs: minimum fields/attachments for a valid decision.
  • Bundling rule: how multiple concessions escalate (highest-tier wins or multi-lever escalation).
  • Non-delegables: prohibited items and items requiring senior approval.

RACI skeleton: mirror the deal stages so accountability is clear and sellers know who owns movement.

  • Stages: intake, triage, economics, terms, security/privacy, delivery feasibility, approval, close verification.
  • Roles: seller, manager, deal desk case owner, pricing/finance, legal/contract ops, security/privacy, delivery, product, revops.
  • Legend: R: responsible; A: accountable; C: consulted; I: informed.

Meeting agendas: keep them time-boxed and decision-focused, with clear required pre-reads.

  • Daily huddle: new complete intake, at-risk cases (50%/80% SLA), blockers, today’s escalations, one fix.
  • Weekly deal council: Tier 2 decisions with one-page memos, cross-functional feasibility confirmation, top tail drivers.
  • Monthly exceptions review: Pareto of exceptions, leakage sample, playbook updates, policy backlog decisions.

Decision log: the desk’s institutional memory and your audit trail. It should be searchable and link to the final quote and contract.

  • Decision ID: links to opportunity/quote/contract/case.
  • Summary: one sentence of what was approved and under what conditions.
  • Conditions + expiration: including re-approval triggers.
  • Rationale: category and evidence reference.
  • Owner: who ensures execution matches the decision.

Connect the artifacts: the approval matrix links to playbooks; the decision log feeds the exceptions review; the exceptions review produces template and guardrail updates. That loop is what keeps governance light while improving consistency.

16.5 Deal Reviews and Learning Loops: Post-mortem, Leakage Review, Policy Updates

Learning loops are how the desk becomes easier to use over time. The objective is simple: convert repeatable exceptions into standard options and detect leakage early enough to stop it from becoming precedent. Keep the templates short and run them on a cadence; learning that happens “when we have time” will not happen.

Post-mortem template: run for exception-lane deals and meaningful losses. Aim for a 20-minute review and a written output of three actions or fewer.

  • Summary: customer, segment, value, outcome.
  • Timeline: intake, key reviews, approvals, signature (or loss point).
  • Exceptions: what was non-standard and why; include the clause or lever.
  • Trades: what we gave and what we got; did it land in the signed deal?
  • Delay drivers: missing inputs, late discovery, reviewer wait, scope churn.
  • Actions: one to three fixes with owners, due dates, and where they will be implemented (tool, playbook, policy).

Leakage review template: sample closed deals monthly; classify and fix. Sampling beats perfection; consistency beats volume.

  • Price: quote matches approval; no unapproved stacking, free months, or waived fees.
  • Cash: billing and net days match approval; no hidden deferrals.
  • Services: scope/hours match approval; change control present.
  • Terms: deviations match approved fallbacks; tagged in CLM.
  • Record: decision, conditions, expiration, and evidence are stored and linked.
  • Classify: documentation miss vs. process bypass vs. policy breach.
  • Fix: tool gate, playbook update, training prompt, or manager reinforcement.

Policy update tracker: manage improvements like a backlog so changes actually happen, not just get discussed.

  • Issue + evidence: frequency, cycle-time impact, margin/leakage impact.
  • Change: corridor update, new package, fallback clause, new gate, or tightened threshold.
  • Owners: business owner plus system owner.
  • Effective date + comms: who is told, what changes in tools, and where it is documented.
  • Success metric: what should move next month (exception volume down, tail down, leakage down).

Monthly discipline: convert at least one frequent, manageable exception into a standard option (a priced tier, a fallback clause, a CPQ guardrail message, or a revised corridor). That single habit is what turns the desk from an approval queue into a compounding commercial capability.

How to get started

1

arrow-down-blue

Tell us about your project

2

arrow-down-blue

Interview candidates

(We’ll provide bios within 48 hours on average)

3

Select your consultant and start work

Find a Consultant

or email us at: [email protected]