Oct 29, 2025·7 min
Sales pipeline schema for B2B founders that stays honest
Sales pipeline schema for B2B founders: the minimum fields, stages, and activity tracking to forecast clearly and keep deals moving without CRM bloat.
Sales pipeline schema for B2B founders: the minimum fields, stages, and activity tracking to forecast clearly and keep deals moving without CRM bloat.
Early on, your pipeline feels clear because there are only a few deals and most of the context lives in your head. Then the list grows, you miss a follow-up, and the pipeline starts telling a nicer story than reality. That’s “pipeline lying”: not on purpose, but because nothing in the system forces the truth.
It shows up in the same patterns:
A common reaction is to overbuild a CRM: more fields, more custom stages, longer notes. Ironically, that usually makes forecasting worse. When updating feels heavy, people update less, and the pipeline quietly rots.
A minimum viable sales pipeline schema does the opposite. It’s just enough structure to make decisions. It doesn’t try to capture everything. It captures the few facts that stop you from kidding yourself.
If you use only one rule, use this: every open deal must have (1) an explicit next action, (2) a date for that action, and (3) a close date tied to a real buyer timeline (a meeting, a legal step, a budget review). If any of those are missing, the deal isn’t active.
Stages should also mean something. A deal moves forward only when something concrete happened, not because it feels good. The goal isn’t a pretty dashboard. The goal is an honest view you can run the business on.
A sales pipeline schema only works if everyone treats it the same way. Before you add fields or argue about stages, decide what a single pipeline item represents.
A clean default for B2B is: one deal equals one buying decision. If the same company might buy twice (two teams, two products, two budgets), that’s two deals, not one messy record.
Keep the objects simple. You can get far with three buckets: a lead (a person you can contact), an account (the company), and a deal (the specific purchase you’re trying to close). If you’re solo, you can even skip formal lead and account records and just make sure every deal clearly names the company and the main contact.
Write down a few operating rules, especially if anyone besides you touches the pipeline:
Example: You talk to Alex at Northwind about a pilot for the finance team. That’s one deal. If a month later product wants a separate contract, create a second deal. Don’t stretch one record to cover two decisions.
A pipeline stays useful when each deal has the few fields you actually check every week. Add fields “just in case,” and they turn into decoration.
Start with a deal name format that prevents duplicates. A simple pattern works: Company - Product/Scope - Quarter/Month. Example: “Acme - Team plan - Mar 2026.” This makes it obvious when “Acme - Demo” and “Acme - Follow-up” are really the same deal.
Each deal also needs clear identity:
Role matters because it changes what you do next. A champion needs enablement. A decision maker needs a business case.
Add accountability fields:
Then add only the money and timing you’ll use:
If you’re unsure about a field, leave it out. You can always add it later. Removing fields after habits form is much harder.
Most “big” pipelines aren’t big. They’re full of deals that are nice to look at but have no clear path to a yes.
Start with one field that forces clarity: Use case (scope). Write what the buyer is trying to accomplish in plain words, plus what “done” looks like. If you can’t describe the outcome in two sentences, you probably don’t understand the deal yet.
Next, capture the decision process in one place. This isn’t a contact dump. It’s the story of how a decision gets made: who signs, who can block it, and what steps they must follow (security review, legal, procurement). If you don’t know the signer, treat the deal as early.
Add a pricing fit signal, even if it’s rough. Ranges (“<$5k”, “$5-25k”, “$25k+”) work fine, or a simple Likely / Unclear / Unlikely based on what you heard. The point is to stop advancing deals that can’t afford you.
Finally, keep a red flags field to one line. If it takes a paragraph, it belongs in notes.
A compact set that works for most B2B founders:
Example: “Wants CRM cleanup before renewal, signer is VP Sales, security review required, budget likely $10-20k, competing with doing nothing, red flag: champion not owning the project.” That single record is harder to fool yourself with.
A pipeline goes bad when it becomes a wish list. The fix isn’t more fields. It’s a few activity signals that force every deal to answer one question: what is happening next?
If you only add one layer to your sales pipeline schema, make it these activity fields:
A practical rule: if a deal has no next step or no due date, it’s not a real deal. Park it or close it out. This does more for forecast accuracy than any scoring model.
Keep “Reason lost” short so you’ll actually use it: price, no budget, no decision, chose competitor, timing, not a fit.
What this looks like: You have a demo with an ops lead on Tuesday. Right after the call you set last activity date = Tuesday, last touch channel = meeting, next step = “Send 2 case studies and confirm who signs,” next step due date = Thursday. If Thursday passes with no reply, the deal goes red without anyone arguing about “pipeline progress.”
A good stage model does one job: it tells the truth about where each deal is, without making you babysit a dozen tiny steps. If you can’t say what must be true for a deal to be in a stage, the stage turns into a feeling.
This six-stage setup works for most B2B founders:
New: You have a name and a reason to reach out. First touch is done or scheduled.
Qualified: Basic fit is confirmed. The problem is real, the customer matches your ICP, and there’s a plausible path to buy.
Discovery done: You’ve had a real conversation. You understand the use case, success criteria, and who’s involved.
Proposal sent: Pricing and scope are in the customer’s hands. A next step is booked or explicitly requested.
Negotiation/Legal: Procurement, security, budget approval, or contract edits are in motion.
Closed won / Closed lost: Outcome is marked and a reason is captured.
Only advance a deal when something happened in the real world (a meeting completed, a proposal sent, legal started). If nothing happened, the stage stays put.
A stage name isn’t a stage definition. If you only label a column “Qualified” or “Negotiation,” you’ll end up with deals that sit there because nobody agrees what “done” looks like.
Write stage rules as simple true/false checks. When every deal in a stage shares the same facts, your pipeline stays trustworthy.
Entry criteria says what must already be true before a deal enters a stage. Exit criteria says what must change before it can move forward. Keep both short and measurable.
Examples:
If you can’t write criteria without words like “good,” “strong,” or “interested,” the stage is too fuzzy.
Set a maximum age for each stage as an early warning, not a punishment. Example: Discovery max 14 days, Proposal max 21 days. When a deal hits the limit, trigger a reset: book a next step, move it back, or close it.
Decide the default action when criteria aren’t met:
This prevents “zombie deals” from inflating your forecast.
You can build a sales pipeline schema in a few hours if you treat it like a small product: rules first, then only what supports those rules.
Start on a blank page, not inside a tool. Write your stages and entry/exit criteria in plain English. If you can’t explain a stage in one sentence, it’s probably two stages (or not a stage at all).
A simple build flow:
Do one realistic test during setup: take a deal you’re actively working and try to move it stage by stage. If you keep guessing, your criteria are too vague.
One rule worth enforcing early: if next activity date is empty, the deal can’t stay in an active stage.
Most CRM bloat starts with good intentions: you want more accuracy, so you add more fields, more stages, and more note-taking. The result is the opposite. People stop updating it, and your pipeline becomes a place where deals go to age.
If two stages feel the same, they’ll be used the same. “Discovery”, “Deep discovery”, and “Discovery follow-up” often mean “we talked,” with no clear next event. Stages should change only when something real changes.
Quick test: if you can’t say what must be true to enter a stage in one sentence, the stage is probably extra.
Close date is only useful if it’s tied to a reason. Treat it as the next decision point date (budget approval, procurement meeting, signature deadline), and move it when that event moves.
Long notes hide the one thing you need: what happened last, and what happens next. Keep notes short, and track activity with last activity date plus next step (with an owner and a due date).
Without a definition, “qualified” becomes “they sounded nice.” Pick 3 to 4 checks that must be true (problem, buyer, timeline, and some form of budget). If one is missing, it isn’t qualified yet.
Pipelines that only grow stop being a pipeline and turn into a graveyard. Close lost fast when the deal is inactive or the fit is wrong, and capture one clear reason so you can learn.
Pick one time each week (30 minutes is enough) and treat it like a meeting with your future self. Pipeline hygiene is less about adding fields and more about making sure every deal still has a real path forward.
A simple review flow:
Concrete example: if a deal is marked “Proposal sent” but there’s no meeting booked to review it, it isn’t a proposal-stage deal. Move it back, set the next step, and stop counting it until the buyer is engaged again.
You sell a B2B analytics tool to a 50-person e-commerce company. After the first call, you create a deal and fill only what you’ll use next week. A simple schema pays off here because it forces clarity, not paperwork.
Right after the call, the record looks like:
The deal starts in Discovery. You move it forward only when the calendar invite is accepted (not when someone “sounds interested”). After the demo, the trigger to move into evaluation is a concrete ask (for example, “Can you connect to Shopify and our warehouse data?”), followed by an agreed technical check.
Now the stall: the CFO goes quiet after pricing. Your log shows two follow-ups, no reply, and the next step date passes. The rule is simple: if there’s no agreed next step, the deal can’t stay in Proposal.
So you make an honest move: either move back to evaluation (if you need a new sponsor or missing info) or close lost (if the decision maker won’t engage by a set date). In this example, you move back, update stakeholders (Ops pulls in the finance manager), set a new next step date, and return to Proposal only once the CFO confirms a decision meeting.
A sales pipeline schema only works if you trust it. The fastest way to get there is to start minimal and live with it for 30 days. That shows you what you actually use, not what you think you might need.
For the first month, be strict: if a field doesn’t change a decision, remove it. If a decision keeps coming up and you can’t answer it from the pipeline, add exactly one field to cover that gap.
A simple test before adding any new field: “If this is blank, we can’t decide whether to ___.”
If you want to build a lightweight, custom CRM instead of forcing a generic one, tools like Koder.ai (koder.ai) can help once you’ve written your stages, required fields, and validation rules. It’s much easier to generate and iterate on a simple app when the schema is already clear.
A pipeline “lies” when it shows progress that isn’t backed by real buyer actions. The most common causes are missing next steps, stale last-activity dates, and close dates that get pushed forward without a buyer-confirmed timeline.
Make three fields non-negotiable for every open deal: a concrete next action, a due date for that action, and a close date tied to a real buyer event like a meeting, review, or signature step. If any of those are blank, treat the deal as inactive until they’re filled.
Default to “one deal = one buying decision.” If the same company could purchase twice through different teams, budgets, or contracts, create separate deals so you don’t mash multiple timelines and stakeholders into one confusing record.
Start with a deal name format that prevents duplicates, a company, a primary contact, an owner, expected value, target close date, and a clear source. Then add just enough qualification to explain why it should close: use case, decision process, and pricing fit.
A one-sentence use case plus what “success” looks like forces you to understand the outcome, not just the buyer’s interest. If you can’t describe the result clearly, the deal is usually still too early to forecast.
Write it as a short story of how a decision gets made: who signs, who can block it, and what steps must happen (security, legal, procurement). If you don’t know the signer yet, keep the deal in an early stage and focus your next step on finding that person and process.
Use a rough range or a simple Likely/Unclear/Unlikely based on what you heard. The goal isn’t perfect pricing math; it’s to stop advancing deals where the budget reality doesn’t match your offer.
Track last activity date, next step, next step due date, and a close reason when it ends. Notes can exist, but these activity fields are what keep deals from drifting and force you to decide what happens next.
Move stages only when something real happened, like a discovery call completed, a proposal actually sent, or legal introduced. If a stage change can happen just because you “feel good,” the stage definitions are too fuzzy and your forecast will drift.
Set a max number of days for each stage as an early warning, then trigger a reset when the limit hits. The default action is simple: either book a real next step, move the deal back to the last stage that matches the facts, or close it as no decision after clear follow-up attempts.