Skip to main content
Published: 2026-09-12 · Last reviewed: 2026-09-12 · Reading edit: 2026-09-12 Two customers look similar in your spreadsheet, yet one buys after a short trial and the other needs months of approvals. It may help to treat them as different groups. Segmentation is simply the work of finding differences that should change your offer, your explanation, or the way you sell.

Choose what segmentation must support

Use strategic segmentation when deciding whom to serve and how. Use a campaign audience filter when deciding who receives a particular message. They can share fields, but a filter such as “visited pricing” is not automatically a durable market segment. Start with one decision: allocating sales coverage, designing a package, prioritizing a use case, or choosing an onboarding model. Name the owner who can act differently for each resulting group.

Construct and test the segments

  1. List plausible differences in customer circumstances: workflow complexity, buying unit, urgency, deployment constraints, existing alternatives and value at stake. Add firmographics only where they help identify those differences reliably.
  2. Write observable membership rules. “Enterprise mindset” cannot be consistently assigned. “Requires a customer-managed deployment and central security approval” can be investigated. Include an unknown category rather than guessing.
  3. Assign a sample of won, lost and non-buying accounts. Keep the assignment date and original evidence. Do not build the rules solely around your favorite customers.
  4. Compare behavior and economics: time to first value, sales effort, adoption, retention and service cost. Define the observation window and show small sample sizes. Historical differences may reflect how you served the groups, not inherent market differences.
  5. Design the different action. State the offer, proof, distribution and service implications. If the team cannot support that difference, postpone the segment-specific program.
  6. Test the rule on new accounts and disagreements between reviewers. Resolve ambiguous boundaries before loading the classification into automation.

Worked example

A fictional reporting product initially divides customers at 500 employees. Yet smaller regulated firms require security reviews while larger agencies use the standard cloud service. The team instead distinguishes customer-managed deployment from standard cloud deployment, with a separate “requirement unknown” state. That distinction changes evaluation materials and implementation ownership. Employee count remains useful for estimating account value but stops determining the sales route by itself. This does not prove deployment is the right segmentation for every product; it earns a limited test because a different operational need was observed.

Segment decision sheet

Watch for false precision

Do not create dozens of cells that each contain one customer. Do not mix user personas, company segments and buying situations in a single mutually exclusive field. Keep overlapping analytical tags separate from a primary operating segment. Revisit a segment when the offer or delivery model changes, not merely because a new campaign needs a name.

Try it with your own work

Compare two recent customers. Note what each needed before buying. If the same offer and process served both well, you may not need another segment yet.

Sources and scope

The example is fictional; any numbers illustrate the method rather than a benchmark. Adapt the worksheet to your own situation. Define jobs to be done, then choose an ICP inside the market you can serve. Chapter guide · All playbooks
Copyright © 2026 Ivan Xu. All rights reserved. See the copyright and reuse terms. Canonical source: github.com/weilun88313/B2B-Playbook