Map How Sales Actually Happens

Task

Map the current founder-led/referral sales process from lead source to close.

Summary

Make the founder-led and referral-driven sales process visible from source through handoff.

Map the Sales Process Before You Try to Scale It

Task ID: S1-04

Founder-led and referral sales can produce real revenue while hiding how the sale actually happens. This article explains how to reconstruct the current process from lead source through qualification, proposal, close, and delivery handoff; measure sales-cycle length honestly; and separate repeatable sales work from founder judgment, relationship capital, and undocumented exceptions.

Executive summary

A founder often remembers a sale as a simple sequence: someone made an introduction, a few conversations happened, a proposal went out, and the customer agreed. The underlying process is usually more complicated. The founder may have known the referrer for years, diagnosed the customer’s problem before creating a formal opportunity, changed the offer during the conversation, approved unusual terms, and carried important commitments into delivery without recording them.

That process may work while the founder personally owns every deal. It becomes a problem when the company tries to forecast revenue, compare customer types, hire a salesperson, standardize an offer, or hand a new customer to somebody else. The immediate task is therefore not to design an ideal sales system. It is to map the sales system that exists now: where opportunities come from, what the founder does to decide whether to pursue them, how scope and price are formed, what constitutes a closed sale, and how the agreement reaches the delivery team.

The map should be reconstructed from evidence rather than memory alone. Useful evidence includes email and calendar histories, customer relationship management records, proposals, contracts, invoices, call notes, project-management records, and interviews with the people who receive the work after the sale. A current-state map should show normal paths, common variations, rework, waiting periods, founder-only decisions, and places where information is lost.

The primary measure is sales-cycle length, but one number is not enough. A credible baseline distinguishes the time from first substantive sales contact to close, the time from qualification to close, and the time spent in each stage. It also reports differences by lead source, offer, customer type, and outcome. The median is generally more informative than the average when a small number of long-running opportunities distort the result.

“Baseline captured” is not an industry performance target. It means the company can explain how its recent deals moved, show the supporting dates, state the sample and definitions used, and identify the largest sources of delay and variation. Only then can it decide what should be standardized, delegated, supported by software, or left to founder judgment.

The real problem in founder-led sales

Founder-led sales is often effective precisely because it is flexible. The founder understands the product, can make commercial decisions immediately, can reshape the offer during a call, and can draw on personal credibility. An early-stage company may reasonably recruit prospects one at a time, begin with former colleagues or other people in its network, and ask those contacts for introductions. Stripe’s public guidance for early business-to-business sales describes this direct, manual approach as a practical way to win initial customers and learn before formalizing the process.

Flexibility, however, can make the process difficult to see.

Consider a typical referral sale. A customer tells a former colleague about the company. The colleague sends the founder a message. The founder takes an exploratory call, decides the prospect is credible, and spends several hours thinking through a possible solution. A second call becomes part discovery, part consulting, and part product demonstration. The founder then creates a proposal with custom scope and price. After several revisions, the customer says yes. Work begins before the contract is fully signed because the founder trusts the buyer.

The company may record only two dates: when the opportunity was entered into a customer relationship management system and when it was marked won. If the founder created the record after several conversations, the reported sales cycle excludes the earliest and sometimes most important work. If the founder marks the opportunity won after delivery begins, the reported cycle includes post-sale activity. Both errors make later comparisons unreliable.

Commercial software reflects this problem in its definitions. HubSpot, for example, calculates “days to close” from the deal’s creation date to its close date, and separately maintains dates for entering and exiting stages. Those fields can be useful, but they measure the process accurately only when records and stage changes are entered consistently.

The hidden issue is not simply missing administration. It is that founder-led selling often combines several different kinds of work:

If these activities are treated as one informal conversation, the company cannot tell which part is repeatable. It also cannot determine whether faster sales came from a better offer, a stronger relationship, a smaller customer, a lower price, fewer approvals, or the founder’s personal intervention.

The map solves that problem by turning the sale into observable events and decisions without pretending that every deal follows a perfectly straight line.

The principle: map actual work and decisions

The central operating principle is simple:

Map what people actually do, including exceptions and waiting, before designing what they should do.

Value-stream mapping uses the same current-state-first logic: identify the process, map the actual flow of work and information, diagnose delay and waste, and only then define a future state. Although the method originated in manufacturing, the underlying distinction between current and future states applies to information-heavy processes such as sales.

A sales-process map should therefore record more than stage names. Each stage needs six elements:

1. An entry condition: What observable event places a deal in the stage?
2. The work performed: What conversations, analysis, documents, or approvals occur?
3. A decision: What question is being answered?
4. An owner: Who is responsible for moving the deal or ending it?
5. An exit condition: What evidence permits movement to the next stage?
6. A timestamp: When did the event occur?

The process should begin with the earliest commercially meaningful event that the company can define and record consistently. That might be receipt of an introduction, the prospect’s first direct inquiry, or the first substantive conversation. It should not begin with the date the founder eventually remembers to create a record.

The end of the mapped process should extend slightly beyond the signature. A sale is not operationally complete when the buyer says yes; it is complete when the company has captured the agreement and can begin fulfilling it without relying on unspoken founder knowledge.

A simple current-state structure looks like this:

flowchart LR
    A[Lead enters<br/>source and referrer recorded] --> B{Pursue?}
    B -->|No| C[Disqualify<br/>reason recorded]
    B -->|Yes| D[Discovery and qualification]
    D --> E{Qualified opportunity?}
    E -->|No| C
    E -->|Yes| F[Scope and proposal]
    F --> G[Customer decision and negotiation]
    G -->|No decision or lost| H[Close lost<br/>reason recorded]
    G -->|Agreement| I[Close won<br/>commitment verified]
    I --> J[Sales-to-delivery handoff]
    J --> K[Onboarding or delivery begins]

Text description: A lead enters with a known source, is either disqualified or developed through discovery, receives a proposal only after qualification, closes with a recorded outcome, and moves through an explicit handoff before delivery begins.

This is a starting structure, not a universal pipeline. Microsoft’s standard sales process, for example, uses lead, qualification, development, proposal, close, and fulfillment, while explicitly noting that terminology and stages vary by industry, product, strategy, and customer.

The practical test is whether the map describes recent real deals. If the founder frequently jumps from introduction directly to proposal, the map should show that path. If a paid diagnostic precedes the larger proposal, that should appear. If procurement, security review, legal review, or a pilot creates separate work, those paths should be visible. If the founder starts delivery before signature, the map should show that exception rather than hiding it.

What the evidence says about referrals, systems, and handoffs

Referrals are valuable signals, not proof of a good customer

Referral sales can reduce uncertainty because the referrer supplies context and transfers some trust. Research on approximately 10,000 customers of a German bank found that referred customers had higher initial contribution margins, higher retention, and greater estimated value than non-referred customers in that setting. Later work using the same broad research stream found evidence for two mechanisms: referrals can improve the match between customer and provider, and the referrer’s continuing relationship can strengthen retention.

Those findings do not justify assuming that every referral is better. A 2019 telecommunications replication also found lower churn among referred customers, but the referred customers had lower contribution margins; customers referred by email had lower value than non-referred customers in that study.

More recent entrepreneurship research likewise distinguishes first-customer acquisition through strong personal ties, weaker ties, and no prior ties. These routes have different conditions and can produce different outcomes; the presence of a relationship is therefore a variable to study, not a universal quality guarantee.

For a founder-led company, this means “referral” is too broad to be a useful source field by itself. The record should distinguish at least:

• the person who made the introduction;
• the referrer’s relationship to the founder and prospect;
• whether the referrer is a customer, partner, former colleague, investor, friend, or other contact;
• whether the prospect had already encountered the company elsewhere;
• whether the referrer participated after the introduction;
• whether the introduction was requested, volunteered, or commercially rewarded.

The company should then compare referral types by qualification rate, win rate, sales-cycle length, deal value, delivery cost, retention, and support burden. A fast, friendly sale can still be a poor sale if the customer requires extensive custom work or is a weak fit for the future offer.

A customer relationship management system cannot define the process for you

A customer relationship management system is useful because it can make work visible, preserve history, and provide timestamps. Open research involving 1,227 managers found that firms with stronger customer-relationship initiation and maintenance processes used their technology more effectively, and that technology effectiveness partially explained the connection to sales performance. The direction matters: process capability supports effective technology use, rather than software automatically creating a sound process.

An open case study similarly found that customer relationship management software can strengthen formal and informal sales control by making outcomes more measurable, work more visible, and tasks more programmable.

The practical implication is to define the sales events first and then configure the simplest system that can record them. A spreadsheet may be sufficient for a small sample if it has one row per opportunity, consistent fields, and protected date definitions. A larger or multi-person process may justify a dedicated system. The tool is secondary to disciplined recording.

Stage names matter less than entry and exit evidence

A stage called “proposal” can mean several different things: the founder intends to prepare a proposal, a draft exists, a proposal was sent, the buyer reviewed it, or negotiations are underway. Combining these states makes the pipeline look more advanced than it is.

Public sales documentation from GitLab illustrates the stronger alternative. Its stages specify work, required information, and exit criteria rather than relying only on labels. Its documented process distinguishes discovery, scoping, technical evaluation, proposal, negotiation, signature, won, and lost outcomes. It also requires reasons for disqualification and closed losses, and links the won state to onboarding and customer-success actions.

A small company does not need GitLab’s number of stages or its qualification framework. The useful lesson is that progress should be based on customer evidence. A deal moves because something became true—not because the founder feels optimistic.

The handoff begins before the sale is complete

Many handoff failures originate during sales. Delivery receives a signed proposal but not the reasoning behind it. The customer’s expected result, internal politics, deadlines, dependencies, promised exceptions, or concerns remain in the founder’s memory.

GitLab’s public customer-success process begins documenting desired outcomes and an adoption plan during pre-sale stages and transfers that information into post-sale ownership. Its detailed approach is designed for larger software transactions, but the principle applies more broadly: information needed for customer success should be created while the buyer and seller are still defining the agreement.

For a consulting-led company, the sales-to-delivery handoff is also a diagnostic. If another capable person cannot understand what was sold, why it was bought, and what must happen next, the sale is still founder-dependent even if the contract is complete.

How to build the current-state map

The strongest map is built from completed and active deals, not from a workshop discussion about how sales is supposed to work.

Select a representative set of opportunities

Use all available opportunities from a recent, meaningful period when volume is low. When volume is higher, include a sample covering:

• won, lost, disqualified, and still-open opportunities;
• referrals from different types of sources;
• large and small deals;
• short and long cycles;
• standard and heavily customized proposals;
• smooth and difficult handoffs.

State the period and sample size. A baseline based on eight deals may still be useful, but it should be presented as eight deals rather than disguised as a stable benchmark.

Reconstruct each opportunity as an event history

For every opportunity, build a chronological record from the available evidence. Email sent dates, meeting dates, proposal versions, electronic signatures, purchase orders, payment records, and project kickoff dates are generally stronger evidence than retrospective estimates.

The event history should answer:

• When was the opportunity first introduced or identified?
• Who introduced it?
• When did the prospect first communicate directly with the company?
• When did the founder decide it merited further effort?
• What information supported that decision?
• When were problem, expected result, buyer, decision process, timing, and commercial constraints understood?
• When was scope first discussed?
• When was a proposal first promised, drafted, and sent?
• How many substantive revisions occurred?
• What caused pauses?
• When did the customer make a verbal decision?
• When did the commitment become binding?
• When did delivery receive the information?
• When did onboarding or delivery actually begin?

Process research shows why the transition dates matter. Waiting commonly occurs between activities, and separating processing time from waiting time helps identify whether delays arise from batching, prioritization, resource contention, unavailable participants, or outside causes.

Interview the people on both sides of the sale

The founder’s account is necessary but incomplete. Interview anyone who helps prepare proposals, approves prices, manages contracts, invoices customers, runs onboarding, or performs delivery.

Ask for specific deals rather than opinions about the process. “What happened after the customer agreed?” will usually produce better evidence than “How does the handoff work?”

Where appropriate, ask a small number of recent customers how they experienced the buying process. Their view can reveal steps that the company does not recognize, such as internal approval, vendor setup, security review, budget timing, or confusion caused by proposal revisions.

Define a usable stage model

The stage model should be detailed enough to expose decisions and delays but simple enough that people will maintain it.

Qualification should reflect the company’s real decision, not a fashionable acronym. Microsoft’s current lead-management documentation, for example, supports recording purchasing time frame and budget, converting qualified leads into opportunities, and preserving disqualified leads as an audit trail.

For an early founder-led company, a qualified opportunity will usually have evidence of a problem the company can address, a plausible customer and buyer, a reason to act, an understood next step, and enough commercial potential to justify further effort. Budget may be unknown, particularly when the company is helping define a new category of purchase. Unknown is acceptable when it is recorded as unknown rather than silently treated as confirmed.

Separate the normal path from exceptions

Do not force every opportunity into one clean path. Mark variations such as:

• paid discovery before a larger sale;
• proposal before full qualification;
• free pilot or proof of concept;
• procurement or security review;
• partner involvement;
• custom pricing approval;
• work starting before signature;
• dormant opportunities that later reopen;
• one lead producing several separate opportunities.

The purpose is not to eliminate every variation. It is to determine which variations reflect legitimate customer needs and which arise because the company has not made a clear commercial decision.

Mark founder-only work

For each activity, record whether it requires the founder today and why.

The reason may be product knowledge, authority to price, customer trust, technical judgment, relationship ownership, lack of documentation, or habit. These reasons imply different next actions. Product knowledge can be taught; pricing authority can be bounded; customer trust may require a staged introduction; undocumented work can be recorded; habit may require only a change in ownership.

The map is complete only when founder involvement is visible as work, not treated as background.

Evidence and measurement

A credible result should include four connected artifacts:

1. a visual current-state process map;
2. written stage definitions with entry and exit conditions;
3. an opportunity-level event dataset;
4. a short analysis of sales-cycle length, variation, delay, and founder dependence.

Use more than one sales-cycle clock

The company should choose definitions deliberately and keep them stable.

End-to-end sales cycle

This measures the prospect’s observable journey with the company. It captures early discovery that would disappear if the clock began only when a formal opportunity was created.

Qualified sales cycle

This measures the active opportunity process after the company decides to pursue the sale.

Stage duration

This shows where time accumulates. HubSpot’s current deal model, for example, includes dates entered and exited, current-stage time, cumulative stage time, and days to close, illustrating why both overall duration and stage-level duration are useful.

The close event should be explicit. Depending on the business, it might be receipt of a signed agreement, accepted order form, purchase order, initial payment, or completed online purchase. A verbal yes can be recorded separately but should not automatically become the legal or operational close date.

Report the distribution, not only the average

For each clock, report:

• opportunity count;
• median duration;
• average duration;
• shortest and longest duration;
• relevant percentiles when the sample permits;
• number and age of still-open opportunities.

The median is the middle observation after durations are ordered. It is less affected than the average by one deal that remained open for a year. The average remains useful for capacity and forecasting, so both should usually be shown.

Break the result down by dimensions that could explain variation:

A cycle should not be optimized in isolation. A referral source that closes quickly but produces low-margin custom delivery may be less attractive than a slower source that produces repeatable, retained customers. The mixed findings in referral research reinforce the need to connect source data to downstream economics rather than treating referral volume or speed as sufficient evidence.

Define what “baseline captured” means

A baseline is credible when:

• the start and end events are defined;
• the source and referrer fields are populated consistently;
• stage changes can be supported by dates or documents;
• won, lost, disqualified, dormant, and open opportunities are represented;
• sample size and time period are disclosed;
• known missing data is identified;
• results are segmented where material differences exist;
• at least one person outside the founder has reviewed the map against actual deals;
• the handoff has been tested with the delivery owner.

It is not necessary to have a statistically large sample before learning from the map. It is necessary to state uncertainty honestly. With few deals, the baseline is descriptive: it tells the company what happened in the observed cases. It does not establish a universal target or prove what will happen after the process changes.

Failure modes and readiness decision

Drawing the desired process instead of the current one

A clean diagram can conceal the most important facts. If proposals are often sent before qualification, if pricing is invented deal by deal, or if delivery begins before a contract is complete, those paths belong on the current-state map.

The future-state process can be designed later. Mixing the two prevents the company from knowing which change it is actually making.

Treating the customer relationship management record as ground truth

Records may be incomplete, late, or updated to support forecasting rather than historical accuracy. Reconstruct dates from primary evidence and record disagreements. The system can become the source of truth after definitions and recording behaviour improve.

Recording “referral” without recording the referral

A source field with only “referral” loses the information needed to evaluate the channel. The identity and type of referrer, introduction date, relationship, and later involvement should be captured. First source, immediate introduction source, and final influence may be different.

Allowing stages to describe seller activity rather than buyer evidence

“Proposal being prepared” says what the seller is doing. “Buyer agreed to review a proposal covering the discussed scope” says what changed in the opportunity. The second produces a more reliable pipeline.

Keeping dead opportunities open

Founder relationships can make it uncomfortable to close an opportunity as lost. The result is an overstated pipeline and misleading cycle times. A closed-lost or disqualified record is not a judgment about the person. It is a record of the current commercial decision. Mature public processes such as GitLab’s explicitly preserve unqualified and closed-lost reasons so that opportunities can be analyzed and, when appropriate, revisited later.

Measuring speed without measuring sale quality

A shorter cycle is not automatically better. The company may be removing necessary qualification, discounting heavily, accepting poor-fit work, or making promises that create downstream cost. Cycle length should be reviewed alongside win rate, price, gross margin, customization, onboarding effort, delivery performance, retention, and support requirements.

Declaring the handoff complete when documents were forwarded

A proposal and contract rarely contain all the operating context. The handoff should communicate the customer’s expected result, agreed scope, exclusions, stakeholders, timing, dependencies, risks, unusual commitments, and next action. The receiving owner should confirm that the information is sufficient.

Copying an enterprise sales process too early

A small founder-led company does not need a dozen stages, complicated scoring, or extensive approval workflows merely because a larger company uses them. Public enterprise processes are useful for principles such as entry evidence, exit criteria, loss reasons, and continuity into customer success. The company should retain only the detail that improves decisions or preserves information.

The task is ready to support the next decision when the company can take several recent opportunities and explain, with evidence, how each moved from source to outcome; where time was spent; what the founder contributed; why the customer bought or declined; what was promised; and whether another person could receive the sale without reconstructing it.

At that point, the company can make a more consequential judgment: whether it has a sales process that another person can learn, or only a collection of successful founder-managed relationships. The map does not answer that question by itself. It makes the answer visible.

Sources

Primary and official sources

• S1-04 task record and editorial context.
• National Institute of Standards and Technology, “Value Stream Mapping,” updated May 22, 2024.
• Microsoft Learn, “Understand the sales process,” updated June 18, 2025.
• Microsoft Learn, “Qualify and convert a lead to opportunity,” updated April 30, 2026.
• HubSpot Knowledge Base, “HubSpot’s default deal properties,” updated in 2026.
• GitLab Handbook, “Commercial Sales Opportunity Stages,” updated November 13, 2025.
• GitLab Handbook, “Engage & Educate the Customer.”
• GitLab Handbook, “Customer Success Plan.”
• Stripe Atlas, “Your first 10 customers.”

Open research

• Philipp Schmitt, Bernd Skiera, and Christophe Van den Bulte, “Referral Programs and Customer Value,” Journal of Marketing, 2011.
• Christophe Van den Bulte, Emanuel Bayer, Bernd Skiera, and Philipp Schmitt, “How Customer Referral Programs Turn Social Capital into Economic Capital,” Journal of Marketing Research, 2018.
• Heike M. Wolters and Karen Gedenk, “Referral Programs and Customer Value: Insights from the Telecommunications Services Industry,” Journal of Marketing Behavior, 2019.
• “From Strong Ties to No Ties: Configurations for First-Customer Acquisition in Tech Startups,” Journal of Business Venturing, 2026.
• Vishag Krishnan and colleagues, “Linking Customer Relationship Management Processes to Sales Performance: The Role of CRM Technology Effectiveness,” Marketing Management Journal, 2014.
• Liang Li and Ji-Ye Mao, “The Effect of CRM System on Sales Management Control: A Case Study,” 2010.
• “Unveiling the Causes of Waiting Time in Business Processes from Event Logs,” Information Systems, 2024.