Sales Process and Client Delivery

Build the mental model

A sale is not a single event but a sequence, and skipping steps in that sequence is where most avoidable client problems start. Discovery comes first: understanding what is happening now, what problem exists, what has been tried, its impact, and what outcome and constraints matter. Discovery is information-gathering in service of the prospect's real interest, not a lead-in to pressure tactics.

Discovery

Understand what's happening now, the real problem, what's been tried, its impact, the outcome that matters, and any constraints -- as information-gathering for the prospect's benefit, never as a pressure tactic.

Qualification

Check problem fit, budget context, timing, decision authority, technical feasibility, and ethical fit -- not every lead should become a customer.

Proposal

State the problem, outcome, scope, deliverables, timeline, price, responsibilities, assumptions, support, and a clear next step.

Follow-up

Keep it short, professional, useful, and respectful -- never repeated pressure on someone who has shown disinterest.

Onboarding

Set shared expectations with the newly won client before delivery work begins.

Scope Management

For every new request, check whether it fits the original scope: if yes, implement it; if no, raise a change request or separate quote.

Communication

Keep the client informed of what's done, what's next, any blockers, and any decisions needed from them.

Retention

Keep clients through real ongoing value, support, and relationship -- never through lock-in tricks.

Upsell

Offer more only when it is genuinely useful to the client, never pushing unnecessary products.

Offboarding

Close cleanly with final deliverables, documentation, credentials and access handover, training, invoices, data export, and future support options.

text

SALES-TO-DELIVERY LIFECYCLE
---------------------------
Discovery -> Qualification -> Proposal -> Follow-up -> Client Won
                                                             |
                                                             v
Offboarding <- Retention <- Delivery(Scope+Comms) <- Onboarding

Connect it to a real scenario

Write your original scope down explicitly in every proposal, as a specific list rather than a vague paragraph, because scope disputes almost always trace back to an agreement that was never made concrete in writing. When a client later asks for something new, compare it against that written list before answering.

Use the scope-checking function below as a rough first pass: if a request clearly overlaps with what was agreed, treat it as included work; if it clearly does not, offer a change request or separate quote rather than quietly absorbing the extra work. Communicate either response promptly, in plain language.

Apply the same discipline to communication throughout delivery: tell the client what's done, what's next, any blockers, and any decisions you need from them, on a predictable schedule, even when there is nothing dramatic to report. Silence is what erodes trust fastest, not slow progress that is honestly explained.

A sale moves through discovery, qualification, proposal, and follow-up -- each step in service of the prospect's real interest, never pressure.
Delivery has its own lifecycle -- onboarding, scope management, communication, retention, upsell, and offboarding -- that keeps trust intact after the sale.
Scope disputes are prevented by writing scope down explicitly and checking new requests against it honestly, offering a change request rather than silently absorbing or refusing work.

Try the working example

javascript

function checkScopeRequest(request, originalScope) {
  const requestWords = request.toLowerCase().split(/\W+/).filter(Boolean);
  const scopeText = originalScope.join(" ").toLowerCase();

  const longWords = requestWords.filter((word) => word.length > 3);
  const overlapCount = longWords.filter((word) => scopeText.includes(word)).length;
  const overlapRatio = overlapCount / Math.max(1, longWords.length);

  const inScope = overlapRatio >= 0.5;

  return {
    request,
    overlapRatio: Math.round(overlapRatio * 100) / 100,
    decision: inScope
      ? "in scope -- implement as originally agreed"
      : "outside original scope -- requires a change request or separate quote",
  };
}

const originalScope = [
  "Build a 5-page marketing website",
  "Contact form connected to email",
  "Basic on-page SEO setup",
  "One round of revisions",
];

const inScopeExample = checkScopeRequest(
  "Can we add one more revision round to the contact form before launch?",
  originalScope
);
const outOfScopeExample = checkScopeRequest(
  "Can you also build us a full e-commerce store with inventory management?",
  originalScope
);

console.log(inScopeExample);
console.log(outOfScopeExample);

You should see

checkScopeRequest on the in-scope example ('add one more revision round to the contact form') returns an overlapRatio of 0.57 and decision 'in scope.' The out-of-scope example ('build a full e-commerce store with inventory management') returns an overlapRatio of 0.13 and decision 'outside original scope -- requires a change request.'

5-minute try-it

Take a real or hypothetical original scope list from a past project, then write two new client requests -- one you believe is in scope, one you believe is not -- and run both through checkScopeRequest. Compare the function's decision to your own judgment and note where simple keyword overlap agrees or disagrees with real context.

One important caution

Leaving scope as a vague paragraph instead of a specific written list, which makes every later dispute harder to resolve fairly.

Going silent during delivery when there is nothing exciting to report, which erodes client trust faster than honestly reported slow progress.

Sales process engineering — Wikipedia — Digital Business