# From One Account to the Person Who Owns the Problem

*You can turn one named account into a single confirmed, current name plus the right first point of contact, with the searches and checks that got you there.*

- Canonical URL: https://www.refolk.ai/guides/account-to-problem-owner
- Pillar: Sales and go-to-market
- Format: Teardown
- Published: 2026-08-04
- Last reviewed: 2026-08-04
- Reading time: 18 min
- Keywords: find the right person to contact at a company, identify who owns the problem at an account, confirm a contact still works there, find the entry point at a target account, who to email at a target account

## Key takeaways

- The owner is defined by function, not by a title that sounds right; write the function statement before you search for any name.
- In Refolk's index there are only 449 US Revenue Operations problem-owners, clustered in Austin and New York, which is why location is the disambiguator, not an optional filter.
- The owner is titled 'Head of Revenue Operations' 60% of the time in the US and 72% in the UK, so a search for only 'VP' silently drops most of the real pool.
- A name confirmed today is meaningfully likely wrong within two quarters, because contact data decays about 2.1% per month and roughly 30% of professionals change jobs annually, which is why the flag sits at six months.
- Second-sourcing a name is worth a 10 to 15 percentage point accuracy jump; it is where a profile that went stale ten months ago gets caught.
- Deals multi-threaded across four or more committee members close at roughly twice the rate of single-threaded deals, so the initiator, not the budget owner, is often the correct first touch.

You have one named target account and a product that solves a specific problem. This guide is for founders selling their own product, account executives, SDR leads, and partnerships teams who need to turn that company name into a single verified, current person: the one who owns the problem, plus the right first point of contact. I carry one real account all the way through, showing the searches, the wrong turns, and the tenure check that catches a name that went stale.

Most pages ranking for this job conflate two separate tasks: deciding who to reach, and finding a way to reach them. They stop at title heuristics before doing any real disambiguation. The result is a name that sounds right and turns out to have left the company months ago. This teardown separates the two jobs and does the second one properly.

## The two jobs, and why conflating them wastes your best account

There are two distinct jobs here: deciding *who* owns the problem, and finding *how* to reach a specific person. Do them in that order or you will spend your effort confirming the wrong person.

When a founder is Googling email addresses, they usually know who they want to talk to by virtue of a title that sounds right, not a function that actually has ownership of the problem. Inverting this - defining the role first, then searching for the person - yields far better contacts. The mapping is product-specific: for a sales tool the owner could be the VP of Revenue or Head of Sales Ops; the CISO is almost never the first call for a security product; for a developer tool a CTO could be all wrong and an engineering manager better.

So before any name, you write a function statement: a one-line description of who owns the problem. For this teardown, I am selling a pipeline-reporting product. My function statement is:

> Owner of pipeline reporting = Head of Revenue Operations.

That is the whole first job. It costs about ten minutes and it decides everything downstream.

> **Rule:** Function before name
>
> Write the function statement first. If you cannot name the function that owns the problem in one sentence, you are not ready to search for a person, and any name you find will be a title guess.

## Who actually owns the problem, by company size

The owner is defined by function, but the *shape* of ownership changes with company size. At an SMB the owner is often the founder or a single functional lead; at mid-market it is a functional head backed by a small committee; at enterprise it is a cross-functional group.

Saber's worked example shows the mid-market pattern cleanly. A 500-employee B2B SaaS company selecting marketing automation forms a five-person committee: Head of Marketing as budget owner, a Demand Gen Manager as the user, a Sales Ops Manager, an IT Manager, and the CFO for approval on contracts over $50K. That is five distinct functions, only one of which is the economic buyer.

Committee size itself is contested, so do not anchor on a number. A Gartner view puts the typical buying group at six to ten decision makers; a newer Gartner survey ranges from five to sixteen people across as many as four functions; Forrester reports an average of thirteen stakeholders, with 89% of purchasing decisions involving two or more departments. The band, not a fixed count, is what you carry forward.

| Size band | Owner shape | First-contact shape |
|---|---|---|
| SMB | Founder or single functional lead | Same person |
| Mid-market | Functional head plus small committee | Initiator or product user |
| Enterprise | Cross-functional group, four or more functions | Champion who feels the pain |

My target account is a 500-person SaaS company, so I am in the mid-market band. My owner title is Head of Revenue Operations. My entry-point title, the person who feels the pipeline-reporting pain daily, is a Sales Operations Manager or RevOps lead.

## Why title-only search fails: the pool is small and clustered

Here is the fact that reframes the whole task. The pool of real problem-owners is small and geographically concentrated, so a generic title search does not return your person - it returns hundreds of namesakes.

**449 - US people whose title includes VP or Head of Revenue Operations, in Refolk's index**

The entire US owner pool for this problem is smaller than a single day's search results for the raw title.

In Refolk's index of professional profiles, there are 449 US people carrying this owner title, and they concentrate hard: the top US hubs are Austin and New York, and the UK pool is overwhelmingly London. Top US current employers for this owner include ZocDoc, Medallion, Informa, and 40Seas; top UK employers include Checkout.com, Moss, and 9fin. That concentration is why location filtering is not optional. It is the disambiguator.

**Table A - Problem-owner supply, US vs UK.** Title includes "VP Revenue Operations" or "Head of Revenue Operations".

| Market | Matching people | Multiple vs UK |
|---|---|---|
| United States | 449 | 3.16x |
| United Kingdom | 142 | 1.0x (base) |

The US pool is about 3.16 times the UK pool. In a market of 142 people, every stale record is proportionally costlier, which changes how often you re-verify. I will come back to that.

There is a second structural trap in the title itself. Search only for "VP" and you drop most of the real pool.

**Table B - Owner title composition within the pool** (sample of 25 per market).

| Title band | US share of sample | UK share of sample |
|---|---|---|
| Head of Revenue Operations | 15/25 (60%) | 18/25 (72%) |
| VP Revenue Operations | 7/25 (28%) | 5/25 (20%) |

Read this plainly: the owner is more often a "Head of" than a "VP", and more so in the UK, where 72% of the sampled owners were "Head of". A search that assumes "VP" is a structural miss, not a coverage gap. Your Boolean must carry both labels.

> A generic title search returns hundreds of namesakes nationwide; location is not a filter, it is the disambiguator.

## The disambiguation sequence, run on the real account

Disambiguation is Boolean first, then a three-point profile check on each survivor. The goal is to get from a shortlist to exactly one profile that could plausibly be your person.

Start with an X-ray search that carries both title labels, the company, and the city. For my mid-market account I ran a Google operator search of the form `site:linkedin.com ("Head of Revenue Operations" OR "VP Revenue Operations") "[company]" "New York"`, then mirrored it with a title-plus-company filter in a sales prospecting view. That returned three candidate profiles. Two were current employees; one had the title but at a lookalike company page with a near-identical name.

Then the three-point check on each candidate. Open the profile and check three things: the current role, its start date, and whether the listed company matches the official page. Guard against the stale profile: confirm the company name links to the real page not a lookalike, check the start date and that no newer role sits stacked above it, match location and title against the company's footprint, and when the stakes are high verify against a second source.

My first wrong turn happened here. Candidate one had a clean "Head of Revenue Operations" title and the right city. But a second, newer role was stacked above it on the profile: she had moved to a "VP Strategy" title internally four months earlier. Her *current* role no longer owned pipeline reporting. The title that matched my search was her *previous* role. Without checking for a stacked newer role, I would have targeted the wrong function inside the right company.

Candidate three was the namesake collision. The title was exact, but the company link resolved to a lookalike page, not the official one. One source in the field describes exactly this trap. Confirming the company link resolves to the official page, not a lookalike, is a thirty-second check that saves an embarrassing send.

That left candidate two: current Head of Revenue Operations, start date fourteen months ago, company link resolving to the official page, location matching the account's New York hub.

#### One account to one name

| Stage | Figure | Note |
| --- | --- | --- |
| Raw title search | 449 | US pool for the owner title |
| Filtered to account + city | 3 | X-ray shortlist at this company |
| Survives three-point check | 1 | One current profile |
| Second-sourced | 1 | Confirmed, current name |

*Each stage narrows the field, and the disambiguation checks do most of the cutting.*

## Confirming the person still holds the role

Confirming tenure is a separate check from finding the profile, and it is where most stale names get through. A profile can look current and be badly out of date.

The most defensible window is six months. Treat data as perishable: contacts older than six months should be flagged for re-verification *before* entering a sequence, not after a bounce. A newer weekly-decay study argues for monthly as the new baseline, because the traditional quarterly cycle leaves roughly 17% of records inaccurate at any moment, while monthly keeps the bad-record rate below 9%. For a thin market like the 142-person UK pool, monthly is the rational cadence, because you cannot afford to burn a name.

**Table C - Re-verification cadence vs residual error** (published benchmarks).

| Cadence | Residual bad-record rate |
|---|---|
| Quarterly | ~17% |
| Monthly | <9% |
| None (1 year, aggregate) | ~22.5% |

The six-month flag is a direct consequence of the churn rate. Contact data decays about 2.1% per month, reaching 22.5% annually; roughly 30% of professionals change jobs annually, invalidating their details across every database that holds them; and average US tenure has dropped to about 4.1 years, often two to three years in tech. Compound 2.1% a month against a 30% annual job-change rate and a name confirmed today is meaningfully likely wrong within two quarters. That is why the flag sits at six months, not a year.

Public signals that a person still holds a role, and where each one lies:

- **Start date plus no stacked newer role.** Proves the current role is genuinely current. It lies when the profile has not been updated, which is why you pair it with a dated signal.
- **A LinkedIn workplace verification badge.** A workplace verification means a member confirmed their association with the specific company using their work email, Microsoft Entra Verified ID, a LinkedIn Learning license, or an active Recruiter license. It lies because work-email verifications expire after 365 days, so a badge can be nearly a year stale.
- **A recent dated public signal.** A post or comment in the last 90 days proves the person is active in the role now. It lies least, which is why it is the corroborator you want when the stakes are high.

For candidate two, the start date and lack of a stacked role were clean, and she had commented on a pipeline-reporting thread eleven days earlier. That dated activity is worth more than the badge, which I treated as supporting, not proof.

> **Watch out:** The badge is not live proof
>
> A workplace verification badge can be up to a year old, and people on leave or open to work skew the signal. Never treat a badge alone as confirmation. Pair it with a dated post, comment, or company-page listing from the last 90 days.

At this point you have done the hard part: one current profile, corroborated. This is where a plain-English search removes the Boolean grinding you just did by hand.

I ran this search: `Head of Revenue Operations at Checkout.com, based in the UK, currently in role.` - [see the full result list](https://www.refolk.ai/s/9ywas201v8).

*Returns the current owner-title holders at the named account, already filtered to people whose role reads as current, so you skip straight to the three-point check.*

Refolk runs the size-band mapping and the location filter as one ask across public LinkedIn records and the open web, so the shortlist you inspect is already the survivors of the filters that took me three manual searches. [Refolk](/) is worth reaching for at exactly this step, once you know the function and the account and just need the current people.

## Owner versus entry point: who to approach first

The problem owner and the first point of contact are usually two different people, and the owner is often the wrong first touch. Know the owner of the relevant decision, the influencer, and the effective foot-in-the-door person before you search for an email address.

The economic buyer approves the budget and gives the final yes or no, but the right first contact is often the user or the initiator. The initiator first recognized the problem and kicked off the buying process - often a department head, manager, or senior IC who feels the pain directly - and is often your internal champion. And multi-threading beats a single entry point: deals multi-threaded across four or more committee members close at roughly twice the rate of single-threaded deals.

#### Who to approach first at the account

Horizontal axis runs from Feels the pain (low) to Feels the pain (high). Vertical axis runs from Controls budget (low) to Controls budget (high).

| Quadrant | What it means |
| --- | --- |
| Low pain, low budget | Ignore; not part of this deal |
| High pain, low budget | Initiator or user; your first touch and likely champion |
| Low pain, high budget | Approver; reach through the champion, not cold |
| High pain, high budget | Owner who feels the pain; approach directly if you can confirm it |

*Feels the pain but no budget is your best first touch; budget but no pain is a warm forward, not a cold open.*

For my account, candidate two, the Head of RevOps, is the owner: she controls budget and feels the pain, so she sits top-right. But I also identified a Sales Operations Manager who had posted about pipeline reporting friction recently - high pain, no budget, the initiator. My first touch is the Sales Ops Manager, framed as a peer conversation about the reporting problem, with the owner reached through that thread. Two names, labelled, is the output of this step.

## The procedure, end to end

This is the full sequence, from company name to one confirmed name plus the right first contact. Each step has a clear "done" state so you know when to move on.

#### One account to one verified person

1. **Define the function that owns the problem** - Before any name, write a one-line function statement, for example owner of pipeline reporting equals Head of RevOps. Done means a function on paper, not a title guess.
2. **Map the owner to the account's size band** - Choose one owner title and one entry-point title for SMB, mid-market, or enterprise. The band, not a fixed committee number, is the output.
3. **Run the X-ray and Boolean shortlist** - Search site:linkedin.com with both title labels, the company, and the city in quotes, and mirror it with a title-plus-company filter. Done means a shortlist of candidate profiles.
4. **Disambiguate namesakes** - Run each candidate through the three-point check of current role, start date, and company link resolving to the official page. Done means exactly one profile survives.
5. **Confirm tenure and role-still-held** - Verify a start date, no newer stacked role, and a dated public signal. Flag anything older than six months, or one month in high-velocity sectors.
6. **Separate owner from entry point** - Label the problem owner who controls budget and the first-contact initiator or champion who feels the pain. Done means each name tagged explicitly.
7. **Second-source the surviving name** - Confirm employer and title agree across two independent sources. If not, mark the name unconfirmed rather than send to it.
8. **Record the audit trail** - Log the URL, source, and timestamp for each confirming signal so anyone can see why the name was called current.

The whole run is about an hour of focused work for one account when done by hand, most of it in disambiguation and second-sourcing. For scale, a January 2026 manual test had two researchers enrich 10,000 contacts to 91% accuracy in 143 hours - roughly one confirmed contact per minute at best, which tells you the per-name cost is real and worth compressing.

## How this goes wrong

The failure modes below are where the confirmed name turns out wrong. Each has a check that catches it. This section is the most valuable part of the standard, because a wrong name that passed looks exactly like a right one until the send bounces or lands with the wrong person.

| Failure mode | What it looks like | The check that catches it |
|---|---|---|
| Title heuristic misfires | You target the CISO or CTO when the real owner is a manager | Write the function statement first; confirm scope in the profile summary |
| Stale profile passes as current | A profile reads clean but the person left ten months ago | Start date, no newer stacked role, and a dated public signal |
| Namesake collision | Right title, but at a lookalike company page | Confirm the company link resolves to the official page |
| Badge treated as live proof | A workplace badge up to a year stale, or an open-to-work skew | Pair the badge with a post or comment from the last 90 days |
| Single-source false confidence | High coverage hides low accuracy | Require a second independent source before "confirmed" |
| Single-threading the initiator | The champion leaves or loses budget and the deal collapses | Log at least owner plus entry point; aim for four touches |
| Confusing entry point with approver | The user who replies is not the budget holder | Label each name owner or entry-point explicitly |

Two of these deserve extra weight. The stale profile is the one that cost the field a named embarrassment: one source added a "VP of Sales" who had actually left the company ten months earlier. That is precisely why the start date and a dated signal are non-negotiable, not nice-to-have.

The single-source trap is the other. Coverage and accuracy are different axes, and a single source trades one for the other. A tool with 90% coverage but 70% accuracy delivers fewer usable contacts than one with 75% coverage and 95% accuracy. Waterfall, or multi-source, enrichment leads single-source databases on accuracy by 10 to 15 percentage points in independent testing. The same mechanism applies to you as a manual worker: cross-checking one profile against the company page is where the stale name gets caught. Second-sourcing is not perfectionism, it is a measurable accuracy jump.

> **Tip:** Second-source in one move
>
> When you confirm the surviving profile, open the company's own page or press listing in the next tab. If the person's name and title appear there too, you have your second source in under a minute. If they do not, mark the name unconfirmed and do not sequence it yet.

## Before you call the name confirmed

Run this checklist on the single surviving name. Every item is a specific, checkable statement, not a topic. If any item fails, the name is unconfirmed and does not enter a sequence.

#### Confirmation gate for one name

- [ ] A one-line function statement was written before any name was searched
- [ ] The owner title and the entry-point title were chosen for the account's size band
- [ ] The X-ray search carried both the Head of and VP title labels
- [ ] Exactly one profile survived the three-point check
- [ ] The company link on the profile resolves to the official page, not a lookalike
- [ ] A start date is present and no newer role is stacked above the current one
- [ ] A dated public signal from the last 90 days corroborates the role
- [ ] No confirming signal relies on a workplace badge alone
- [ ] Employer and title agree across two independent sources
- [ ] Both an owner and an entry-point name are labelled, not one name doing both jobs
- [ ] The URL, source, and timestamp are logged for each confirming signal

## Keeping the name current

A confirmed name is a snapshot, not a fact, so the last job is deciding when to re-run the check. The mechanism is data decay, and you re-check against the clock, not against a bounce.

Set the flag at six months for a standard account and at one month for high-velocity sectors or thin markets. In a thin market like the 142-person UK owner pool, each stale record is proportionally costlier, so monthly verification, with its sub-9% residual error rate, is the rational cadence. Do not wait for a bounce to tell you a name went stale; by then you have burned the contact and possibly the account.

When the flag comes due, you do not repeat the whole hour. You re-run steps five and seven: confirm the role is still current with a fresh dated signal, and confirm two sources still agree. If a newer role has stacked above the one you targeted, the person may have moved inside the company, and your owner and entry-point labels need to move with them. That is the whole maintenance loop, and it is cheap because you already did the hard disambiguation once and logged the audit trail that lets you re-verify fast.

## Frequently asked questions

### How do I find the right person to contact at a company when I only have the company name?

Start with the function, not a title. Write a one-line statement of who owns the problem your product solves, for example 'owner of pipeline reporting = Head of RevOps'. Then map that function to the account's size band, run an X-ray search combining title, company, and city, and disambiguate namesakes with a three-point profile check. Only after one profile survives do you look for a contact method.

### How do I confirm a contact still works there before I reach out?

Open the profile and check three things: the current role, its start date, and whether the listed company links to the official page. Confirm no newer role is stacked above the current one, and pair any workplace verification badge with a dated public signal such as a recent post, because work-email verifications expire after 365 days. Flag anything older than six months for re-verification before it enters a sequence.

### Should I contact the person who owns the budget first?

Often no. The economic buyer approves the budget, but the initiator, who first recognized the problem and started the buying process, is usually the better first touch and your internal champion. Deals multi-threaded across four or more committee members close at roughly twice the rate of single-threaded deals, so log both the owner and the entry point and reach the owner through the initiator.

### Is one data source enough to confirm a name?

Not when the stakes are high. Coverage and accuracy are separate axes: a source with 90% coverage but 70% accuracy delivers fewer usable contacts than one with 75% coverage and 95% accuracy. Multi-source, or waterfall, approaches lead single-source databases on accuracy by 10 to 15 percentage points, so treat a name as unconfirmed until a second independent source agrees on employer and title.

### How often does B2B contact data actually go stale?

It decays about 2.1% per month, reaching roughly 22.5% a year at the aggregate level, and higher for specific fields like email. Around 30% of professionals change jobs annually, and average US tenure has dropped to about 4.1 years, often two to three years in tech. Quarterly re-verification leaves roughly 17% of records inaccurate; monthly keeps the bad-record rate below 9%.

---

*From the Refolk guide library. I revise these guides rather than replacing them, so the current version is always at https://www.refolk.ai/guides/account-to-problem-owner*