“Operations manager at a growing company” leaves most of the work to the person sending the email. It does not say which operation, what changes the manager can authorize, or why this company should be contacted this month.

A useful persona makes those decisions explicit enough that two people checking the same account reach the same conclusion, including when that conclusion is “we need more information.”

The goal is not a detailed biography. It is a usable description of a person, paired with evidence-based rules for deciding whether their company belongs in your outreach.

Separate the persona, the ICP, and the buying role

These describe different things:

• Client persona: The person who evaluates or uses your product. Describe their responsibilities, workflow, difficulties, evaluation questions, and limits.

• Ideal customer profile, or ICP: The account characteristics that make your product relevant. Describe the operating model, supported workflow, requirements, and exclusions.

• Buying role: The part someone plays in a particular purchase, such as user, evaluator, sponsor, budget holder, or final approver.

One person can occupy several buying roles. Several people can share one role. A job title does not establish either arrangement.

For example, an operations manager might evaluate scheduling software but need a regional director to authorize a purchase. At another company, a location manager might own scheduling while central operations sets policy.

Keep the persona about the person. Add account qualification alongside it rather than turning the persona into a company description.

For broader pipeline design, see the B2B lead generation guide. Here, the task is narrower: create a worksheet that makes a specific account and contact decision repeatable.

Copy this blank client persona worksheet

Complete one version for each materially different workflow and evaluator. “Unknown” is a valid entry. An empty field can otherwise conceal an unsupported assumption.

Person and workflow

• Persona name: [Functional description, not an invented biography.]

• Workflow: [Task they perform or oversee; include frequency and handoffs.]

• Desired result: [What successful work looks like.]

• Relevant difficulty: [Problem your product can address; label untested assumptions.]

• Ownership evidence: [What shows this person owns or influences the workflow.]

• Buying role and authority: [Known responsibilities, approval limits, or unknown.]

• Evaluation questions: [What they need to understand before proceeding.]

Account fit

• Required account characteristics: [Observable conditions that make the workflow relevant.]

• Required product compatibility: [Capabilities or operating requirements that must match.]

• Disqualifiers: [Specific conditions that make the account unsuitable.]

• Unknowns: [Missing facts that could change the decision.]

Evidence and timing

• Evidence record: [Claim; source URL or document; observed date; source date if available; what it supports.]

• Timing evidence: [Current event connected to the workflow, or unknown.]

• Evidence limits: [What the source does not establish.]

• Next question: [The most consequential unresolved question.]

• Next check: [Where or how to answer it.]

Decision

• Qualify for outreach when: [Conditions supported by evidence.]

• Research more when: [Missing information prevents a defensible decision.]

• Exclude when: [A documented disqualifier applies.]

• Current decision and reason: [Qualify, research more, or exclude, with supporting evidence.]

• Review trigger: [Event or new information that should reopen the decision.]

Write disqualifiers before evaluating accounts. Otherwise, an attractive company name or promising contact can tempt you to relax the rules.

Completed fictional example: multi-site shift scheduling

Everything in this example is fictional: the vendor, account, people, capabilities, documents, and evidence dates. This illustrates the worksheet, not a Coldreach customer or product capability.

The invented vendor, ShiftHarbor, provides software for location-based shift teams. For this illustration, assume it supports shared schedule visibility, shift-swap requests, and location-manager approvals. Assume it does not support project staffing for salaried engineering teams.

The account under review is the fictional Northline Community Fitness.

Person and workflow

• Persona name: Multi-site operations manager.

• Workflow: Coordinates location managers responsible for weekly staffing schedules and coverage changes.

• Desired result: Each location has appropriate shift coverage, with a clear approval process for changes.

• Relevant difficulty: Coverage changes may require coordination across locations. Whether Northline experiences this difficulty is unknown.

• Ownership evidence: A fictional careers page assigns schedule preparation to location managers. A fictional team page lists Morgan Ellis as operations manager. Neither establishes Morgan’s ownership of scheduling software.

• Buying role and authority: Possible evaluator or internal routing contact. Purchasing authority and budget ownership are unknown.

• Evaluation questions: Can location managers retain approval control? Can central operations see coverage? What existing system would need to connect or change?

Account fit

• Required account characteristics: Multiple operating locations with employees assigned to scheduled shifts.

• Required product compatibility: Location-level approvals and cross-location visibility must match how the account manages schedules.

• Disqualifiers: No shift-based workforce; only salaried project staffing; or a mandatory operating requirement the fictional product cannot support.

• Unknowns: Current scheduling system, actual coordination difficulties, integration requirements, Morgan’s ownership, and purchasing process.

Evidence and timing

• Evidence record A: Fictional Northline locations page, observed September 8, 2026; page date unavailable. Lists several operating fitness centers. Supports multi-site operations, not scheduling difficulty.

• Evidence record B: Fictional location-manager vacancy, dated September 3, 2026 and observed September 8, 2026. Includes preparing staff rotas and arranging shift coverage. Supports the existence of the relevant workflow.

• Evidence record C: Fictional careers page, observed September 8, 2026; page date unavailable. Shows current hiring for location-based roles. Supports current recruiting activity, not software demand.

• Evidence record D: Fictional team page, observed September 8, 2026; page date unavailable. Lists Morgan’s title. Does not establish software ownership or authority.

• Timing evidence: Current location hiring could make staffing coordination worth asking about. A scheduling change or purchase window remains unknown.

• Evidence limits: Hiring does not prove pain, budget, dissatisfaction, or urgency.

• Next question: Who owns scheduling tools across locations?

• Next check: Look for an explicit responsibility statement. If none exists, keep ownership unknown and use a routing question rather than an authority claim.

Decision

• Qualify for outreach when: Evidence establishes multiple locations and shift scheduling, with no known disqualifier. Outreach must acknowledge that ownership and purchase timing remain unknown.

• Research more when: Locations are visible but shift work is not, or a potentially incompatible requirement needs checking.

• Exclude when: Evidence establishes salaried-only engineering project teams, no relevant shift workflow, or an unsupported mandatory requirement.

• Current decision and reason: Qualify for a cautious exploratory contact. The fictional locations page and vacancy establish account-level relevance. Morgan is a possible contact, not a confirmed buyer.

• Review trigger: New evidence about the current system, centralized ownership, mandatory requirements, or removal of the relevant workflow.

The account can be suitable for an exploratory conversation without being purchase-ready. Unknown authority is not a failed qualification test unless confirmed authority is necessary for the specific outreach you intend to send.

Three false positives to catch

1. The right title, without authority

A director of operations looks promising, but their remit may cover facilities rather than workforce scheduling.

Check: Find evidence of responsibilities, not just seniority. If ownership remains unknown, ask who handles the workflow. Do not imply the person controls the purchase.

2. Growth, without the relevant workflow

A company is hiring rapidly, but all open positions are salaried engineering roles. For the fictional scheduling vendor, headcount growth does not establish shift-scheduling fit.

Check: Connect the growth signal to the supported task. Confirmed salaried-only project staffing is an exclusion. Missing workforce detail calls for more research.

3. News, without a buying reason

An expansion announcement gives you something recent to mention. It does not explain why the company would change software.

Check: State the connection explicitly: does the event introduce the workflow, change its requirements, or identify an owner? If not, it is background information, not timing evidence.

Validate the worksheet without turning guesses into facts

Use interviews, CRM observations, and assumptions differently. The following are validation methods, not claims about any actual customer conversations or CRM records.

Interview evidence explains responsibilities

Ask people who perform or oversee the workflow to describe a recent instance: what happened, who handled exceptions, which tools were involved, and who could authorize a change.

Record the interview date, participant’s role, operating context, and the distinction between their direct experience and their interpretation. A description of one company’s approval process should not become a universal buying rule.

Change the persona when interviews reveal a different workflow owner, evaluation concern, or approval boundary.

CRM observations expose patterns worth investigating

If you have CRM history, review relevant opportunities alongside disqualified accounts and stalled conversations. Look for documented reasons, not just outcome labels.

Record the underlying note, date, account context, and missing fields. A closed opportunity without a recorded reason cannot explain which persona assumption was wrong.

Change an account rule when the evidence supports a meaningful distinction, not merely because one recognizable account converted.

Assumptions remain provisional

Label untested beliefs directly: “We assume central operations evaluates scheduling tools.”

Give each consequential assumption a next check. If it cannot be verified before outreach, preserve the uncertainty in the message and the account record.

Review the worksheet when evidence contradicts a rule, the product’s supported workflow changes, or a recurring unknown prevents useful decisions. Cosmetic persona details do not need the same attention as a mistaken ownership assumption.

Translate the worksheet into checks, then an email

Run the account checks before drafting:

• Workflow: Is the supported activity present?

• Fit: Are required operating conditions supported?

• Exclusion: Does a documented disqualifier apply?

• Person: What is known about responsibility and buying role?

• Timing: Is there a defensible reason to ask now, or is timing unknown?

These are decision questions, not a weighted scorecard. Keep the evidence attached so another operator can inspect the conclusion.

Only then decide what belongs in the message. Research can justify inclusion without appearing in the email.

Fictional first email for the fictional Northline account:

Hi Morgan, Northline’s location-manager opening includes responsibility for staff rotas and shift coverage. ShiftHarbor supports shared schedule visibility and location-manager approvals for multi-site shift teams. Who handles scheduling-tool decisions across your locations?

The message does not claim Northline has a scheduling problem or that Morgan owns the budget. It asks one ownership question instead of combining a process question with a referral request. For more help with message construction, use the cold email templates guide.

Where automated research helps

Automated research can help apply account checks consistently, provided you inspect the reasons for both inclusion and exclusion.

Look for traceable sources, dates, and distinctions between observed facts and inferences. Check whether missing information remains unknown rather than becoming a negative result.

Coldreach uses AI to research each company for a real reason to contact it before email or LinkedIn outreach. Its AI outbound manager tests signals and angles using lessons from 2,000+ real campaigns run in the last six months. Research serves two jobs: deciding who most likely fits and making outreach relevant. Not every finding needs to appear in the message.

To evaluate that process, book a demo and ask to inspect the inclusion evidence for an account you recognize. Compare it with your own rules, including what would exclude the account and what remains unknown.

FAQs

How many client personas do we need?

Create separate personas when responsibilities, evaluation concerns, or buying roles materially differ. Different titles performing the same workflow may belong in one persona. A daily user and a purchasing approver may need separate descriptions even within the same account.

When should we update a persona?

Update it when evidence changes a decision: a different role owns the workflow, an evaluation requirement repeatedly matters, or a supposed disqualifier proves too broad. Record what changed and why so operators do not apply different versions silently.

What if there is no public evidence?

Mark the relevant field unknown. Then decide whether another source can resolve it or whether a restrained discovery question is appropriate. If you cannot establish even the supported workflow, research more rather than inventing relevance.

Is a persona just a job title?

No. A title helps locate someone. A persona explains what they do, what they evaluate, and what remains uncertain about their role. Keep title variants as search aids, but require responsibility evidence before treating a contact as an owner or decision-maker.