> ## Documentation Index
> Fetch the complete documentation index at: https://docs.snowdoughnut.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Customer Profiles (B2B) 

> A fill-in workbook for defining the type of company most likely to buy, stay, and grow with you. Fill in each section to produce one Customer Profile, then save it to the customer profile library under a consistent name so the whole team works from the same picture.

*Fill in the workbook for each section below. Every section has a concept review dropdown that explains the thinking behind it, so you can understand why a field exists before you commit to an answer. You can complete the whole page top to bottom without opening a single dropdown.*

*The greyed `E.g.` text shows what a filled-in answer looks like. It follows Doughnut Labs, a SaaS company that sells Doughnut Technology. Delete it and replace it with your own.*

<Note>
  A Customer Profile describes the kind of **company** most likely to buy your product, stay a customer, and grow over time. It is not a description of one person; the individuals you talk to inside that company are buyer personas, which are a separate document. Fill in the core sections first. The optional sections only matter for some businesses, so skip any that don't apply to you rather than forcing an answer.
</Note>

<Steps>
  <Step title="Build it from real customers, not a wish list">
    Before you fill anything in, pull up your best current customers and a few that churned or were a bad fit. The strongest profiles come from patterns in accounts you already have, not from who you wish would buy.
  </Step>

  <Step title="Fill in the core sections">
    Work through company fit, the problem you solve, buying triggers, the buying committee, and what success looks like. These five apply to almost every business.
  </Step>

  <Step title="Add the optional sections that fit">
    Technology, budget and deal size, and disqualifiers help some businesses and not others. Fill in the ones that sharpen your picture.
  </Step>

  <Step title="Name it and save it">
    Give the finished profile a name using the convention at the bottom of this page, then save it to the customer profile library.
  </Step>
</Steps>

## Profile summary

One or two sentences naming the ideal customer in plain language. This is the line someone reads first, and it should be specific enough that a person could look at a company and say yes or no.

**In a sentence or two, who is this Customer Profile for?**

*E.g. Mid-market e-commerce companies with 50 to 300 employees that run their own fulfillment and are losing margin to slow, manual order processing.*

<Accordion title="Concept review: Profile summary">
  This is the one line that does the most work, because it is the part people actually remember and repeat. A profile can have twenty fields filled in perfectly and still fail if no one can summarize it, because the version that travels between teams is the sentence, not the spreadsheet.

  The tension here is breadth against usefulness. A summary broad enough to include everyone ("businesses that want to grow") tells a salesperson nothing about who to call. The narrowest profiles are often the strongest, because focus is what lets you build the product, the messaging, and the pricing around one kind of buyer instead of splitting the difference between three. Some of the most effective early profiles named a single role at a single size of company, and that narrowness was the point rather than a limitation.
</Accordion>

## Company fit

The company-level traits that describe the account. These are the stable facts about a company that stay the same from week to week, and they are the first filter for whether an account is worth pursuing.

| Attribute                | Fill in                                                                 |
| :----------------------- | :---------------------------------------------------------------------- |
| Industry or vertical     | *E.g. Direct-to-consumer e-commerce, especially apparel and home goods* |
| Company size (employees) | *E.g. 50 to 300 employees*                                              |
| Revenue range            |                                                                         |
| Geography                | *E.g. North America and English-speaking Europe*                        |
| Business model           | *E.g. Sells physical goods online, handles its own fulfillment*         |
| Growth stage             | *E.g. Past product-market fit, scaling order volume fast*               |
| \[add attribute]         |                                                                         |

<Accordion title="Concept review: Company fit">
  These attributes are the baseline definition of who fits, and they are worth getting right first because every other section builds on them. They are also the easiest to verify from the outside: you can usually tell a company's industry, rough size, and location before anyone talks to them, which is what makes this section the practical starting point for building a target list.

  Fit here answers a structural question, not a timing one. A company can match every attribute in this table perfectly and still not be ready to buy this quarter; that readiness lives in the buying triggers section, not this one. Keeping the two separate is what stops a profile from confusing "this is the right kind of company" with "this company is in-market right now," which are different claims that call for different actions.
</Accordion>

## The problem you solve

The specific pain that makes this customer go looking for a product like yours. This is the reason the account exists as a customer at all, and it is often the part that most separates a real profile from a generic one.

**What problem does this customer have that your product solves? What are they doing about it today?**

*E.g. Their team processes orders by hand across three disconnected tools, which caps how many orders they can ship a day and introduces errors that cost them refunds and repeat customers. Today they hire more people to keep up, which stops working as volume grows.*

<Accordion title="Concept review: The problem you solve">
  A profile that lists only company attributes can describe a company perfectly and still not explain why it would ever buy. The problem is what turns a description into a reason. It is the difference between "companies that look like this" and "companies that look like this and hurt in a way we fix."

  The most reliable way to get this right is to look backward at real deals rather than forward at hypotheticals. Asking "what problems do our customers have" tends to surface beliefs; looking at the last several deals you closed and naming the exact problem each customer described in their first call tends to surface facts. Describing the workaround they use today matters as much as the pain itself, because the workaround is your real competition. Often you are not replacing another product, you are replacing a spreadsheet, a manual process, or doing nothing at all.
</Accordion>

## Buying triggers

The events that move a company from "fits the profile" to "fits the profile and is looking now." A trigger is a discrete event with a shelf life, and it is what tells you timing rather than fit.

| Trigger                         | What it looks like                                                  |
| :------------------------------ | :------------------------------------------------------------------ |
| *E.g. New funding*              | *E.g. Raised a Series A or B and needs to scale operations fast*    |
| Rapid headcount growth          | Hiring quickly, existing manual processes starting to break         |
| Leadership change               | New VP of Operations or Ops lead brought in to fix scaling problems |
| Compliance or deadline pressure | A peak season or new requirement forcing a fix by a date            |
| \[add trigger]                  |                                                                     |

<Accordion title="Concept review: Buying triggers">
  A company can be a perfect fit on every other attribute and still have no reason to act, because nothing has changed for them recently. Triggers are what separate the accounts worth calling this week from the accounts worth keeping on a list. At any given moment only a small share of the companies that fit your profile are actually ready to buy, and triggers are the closest thing to a signal of which ones.

  What makes a trigger different from a permanent attribute is that it fades. A funding round matters most in the months right after it happens; a new leader is most open to change in their first few months. This is why a trigger is worth acting on quickly or not at all: by the time it is stale, the window it opened has usually closed. Listing your triggers here does not mean you can see them automatically, but naming them tells the team what to watch for.
</Accordion>

## Buying committee

The roles inside the company that shape the decision. B2B purchases are rarely made by one person, so this section names who you need to reach, not just the company you are reaching into.

| Role           | Who they are and what they care about                                                |
| :------------- | :----------------------------------------------------------------------------------- |
| Economic buyer | *E.g. VP of Operations, owns the budget, cares about cost per order and error rates* |
| Champion       | *E.g. Operations manager who feels the pain daily and pushes for a fix*              |
| End users      | *E.g. The fulfillment team who will use the product every day*                       |
| Blockers       | *E.g. IT or finance, who ask about security and whether it integrates*               |
| \[add role]    |                                                                                      |

<Accordion title="Concept review: Buying committee">
  This section exists because the account and the people inside it are two different things. The company fits or it doesn't; but the deal is won or lost with specific humans who each want different things. The person who feels the pain is rarely the same person who signs the contract, and missing either one stalls the deal.

  Naming the roles here is not the same as writing full buyer personas, and it is not meant to be. A persona goes deep on one individual's goals, objections, and day; this table just maps the shape of the committee so no one is surprised late in a deal by a security review or a finance gate they never planned for. The number of people involved in a typical purchase has grown over time, which is why knowing the cast in advance matters more than it used to.
</Accordion>

## What success looks like

The signs that a customer is a good fit after they buy, not just before. A customer who buys and churns is not an ideal customer, so this section defines the outcome the whole profile is aiming at.

**What does a successful, retained customer look like? How do you know this account was a good fit?**

*E.g. They roll the product out across their whole fulfillment team within the first month, ship measurably more orders per day, and expand to a second warehouse within a year. Their support tickets are about doing more, not about basic setup.*

<Accordion title="Concept review: What success looks like">
  It is easy to build a profile around who will buy and forget to ask who will stay. The two are not the same, and a profile tuned only for the sale will happily bring in customers who sign, struggle, and leave. Defining success closes that gap by pointing the whole profile at retention and growth rather than just the close.

  This section is also how the profile improves over time. When you compare the customers who match your success criteria against the ones who churned, the differences tell you what to add or tighten in the sections above. A profile is not a document you write once; it is a picture you correct every time a customer turns out better or worse than expected, and the success criteria are the yardstick you correct it against.
</Accordion>

## Technology

<Tip>
  Optional: fill this in if your product integrates with, replaces, or depends on specific tools the customer already runs.
</Tip>

The tools and platforms the customer already uses. For some products the existing stack is a strong signal of fit; for others it barely matters.

| Attribute                    | Fill in                                                                 |
| :--------------------------- | :---------------------------------------------------------------------- |
| Tools that signal a good fit | *E.g. Already running Shopify and a major 3PL, which we integrate with* |
| Tools that signal a bad fit  | *E.g. Built a fully custom in-house order system they won't replace*    |
| \[add attribute]             |                                                                         |

<Accordion title="Concept review: Technology">
  For products that plug into an existing stack, what a company already runs can predict fit better than its size or industry. An account already using the tools you integrate with faces less friction adopting you, which usually means a faster path to value and a lower chance of a stalled rollout. The same stack read the other way can be a disqualifier: a company committed to a competing tool, or to a custom system they built and love, is a harder and often worse fit.

  This section is optional because the stack only matters for some products. If yours works the same regardless of what else a company runs, forcing an answer here adds noise without adding signal. Where it does apply, the value is only as good as its consistency: a tool named one way in one profile and another way in the next won't group or filter together later.
</Accordion>

## Budget and deal size

<Tip>
  Optional: fill this in if deal size varies enough that it changes who is worth pursuing.
</Tip>

The economics of the account: what a typical deal is worth and whether the customer can afford it. Useful when some accounts are worth far more than others.

**What is a typical deal worth, and what tells you an account has the budget and the will to spend it?**

*E.g. Annual contracts run* $15K to $*60K depending on order volume. A good sign is that they're already paying for temp staff or overtime to keep up, which means the money and the pain both exist.*

<Accordion title="Concept review: Budget and deal size">
  Two accounts can look identical on every other attribute and be worth very different amounts to you, and pursuing them as if they were equal wastes effort on the smaller one or under-serves the larger. Naming the economics here lets the team spend its time where the return is highest, which matters most when the range of possible deal sizes is wide.

  Budget is also where fit and reality meet. A company can have the exact problem you solve and no money to solve it, and that account will absorb a lot of sales effort without closing. The useful signals are usually indirect: what a company already spends on the problem, whether it is paying for a workaround, and whether a budget owner exists at all. This section is optional because for some businesses every deal is roughly the same size, and in that case the distinction it draws isn't worth tracking.
</Accordion>

## Disqualifiers

<Tip>
  Optional but recommended: fill this in once you can see the patterns in accounts that looked right and turned out wrong.
</Tip>

The red flags that rule an account out even when it matches everything else. This is the profile in reverse: not who to chase, but who to walk away from.

| Disqualifier                 | Why it rules them out                                             |
| :--------------------------- | :---------------------------------------------------------------- |
| *E.g. Under 20 employees*    | *E.g. Too small to have the order volume our product pays off at* |
| Fully custom in-house system | Won't replace a system they built and maintain themselves         |
| No single operations owner   | Nobody owns the problem, so the deal never finds a champion       |
| \[add disqualifier]          |                                                                   |

<Accordion title="Concept review: Disqualifiers">
  Most profiles describe who to pursue and stop there, which quietly assumes that anyone who doesn't match is simply neutral. In practice some accounts are worse than neutral: they match on the surface, pull a rep through a long cycle, and then don't close or don't stay. Naming those patterns is what keeps them out of the pipeline before someone sinks time into them.

  This section tends to be the last one a team can fill in honestly, because you learn the disqualifiers from experience rather than theory. They usually come from looking at the accounts that looked promising and went wrong, and asking what they had in common. Writing them down turns a hard-won lesson into a filter, so the same mistake doesn't get made twice by someone who wasn't there the first time.
</Accordion>

## Name and save the profile

Once the profile is filled in, give it a consistent name and save it to the [customer profile library](/campaign-library-overview). A shared naming pattern is what lets anyone find a profile later without guessing, and what keeps two people from saving the same thing under two different names.

A Customer Profile name is built from four parts, joined by underscores, in this fixed order:

`CP_descriptor_date_version`

| Part         | What it is                                               | Rule                                                      |
| :----------- | :------------------------------------------------------- | :-------------------------------------------------------- |
| `CP`         | Marks the file as a Customer Profile                     | Always `CP`, so every profile groups together             |
| `descriptor` | A short, human-readable label for who the profile is for | Lowercase, hyphens between words, no spaces               |
| `date`       | When this version was written, as `YYYY-MM-DD`           | This format sorts by date on its own                      |
| `version`    | Which iteration this is, as `v` plus two digits          | Start at `v01`; two digits keep `v10` sorting after `v09` |

Add the file extension last. Some worked examples:

`CP_midmarket-ecommerce_2027-09-15_v01.md`

`CP_enterprise-retail_2027-09-15_v02.md`

`CP_dtc-apparel_2027-10-01_v01.md`

<Accordion title="Concept review: Name and save the profile">
  A naming pattern exists so that a profile is findable and recognizable months after whoever wrote it has moved on. The four parts each answer one question: what kind of file this is, who it's about, when it was written, and which version it is. Put in a fixed order with consistent formatting, those four turn a folder of profiles into something you can sort and scan instead of open one by one.

  Two small rules carry most of the weight. Writing the date as `YYYY-MM-DD` means a plain alphabetical sort also sorts by date, so the newest profile is easy to find without any special setup. Padding the version to two digits (`v01`, not `v1`) keeps versions in order once you pass nine, because in a plain text sort `v10` would otherwise land next to `v01`. The pattern only works if everyone writes it the same way every time: a search for `CP` won't find a file someone saved as `cp` or `Customer-Profile`, so a convention that drifts is worse than a plain one that holds.
</Accordion>
