Oops! Something went wrong while submitting the form.
Sai researches what a job title actually owns, is measured on, and complains about publicly, then delivers a one-page persona where every claim links back to the post, job description, or report it came from.
The recording is a real session. The sheet on the right is what it produced.
Sai opens each profile, pulls the signal, and writes the row, live, in a real browser.
Eight columns, sorted by score, with a source link behind every claim.
A job title and a company type. Nothing else — no CRM connection, no contact list, no existing persona doc
A one-page persona covering what the role owns, what it is measured on, its daily tool stack, where it posts publicly, what it complains about, and who else sits in the buying committee — with a source link on each claim. Plus five messaging angles derived from those findings, and an explicit list of claims that could not be sourced.
Re-run quarterly per target title. Role scope, tooling, and public complaints shift with hiring cycles and tool adoption — the AI-adoption figures cited in a persona built last year are usually the first thing to go stale.
Buyer persona research is the process of establishing what a specific job title is responsible for, what that person is evaluated on, which tools they use, and what they say publicly about their own work — so that messaging aimed at them is based on observed behavior rather than assumption.
The term is often used interchangeably with two things it is not. It is not ICP definition, which operates at the company level and asks which organizations are worth approaching. It is not contact enrichment, which operates at the record level and appends fields like title, email, and company size to a row in a list. Persona research operates at the role level, between the two: it asks what the human in that seat is actually dealing with.
The distinction matters because the three are researched differently. Company fit can be scored from firmographic data. Contact fields can be looked up in a database. Role reality can only be read out of primary sources — job descriptions written by employers, posts written by people in the role, and reports published about the function.
A persona document is used in one place: when someone writes an email, a call script, or an ad, and needs to know what will land. It fails at that moment for a predictable reason — it contains nothing specific enough to write from.
This happens when the persona is assembled from a template rather than from evidence. Template fields ask for "goals," "pain points," and "motivations," and those fields get filled with statements that are true of almost any senior role: wants to be more efficient, frustrated by manual work, concerned about cost. Nothing in that is wrong, and nothing in it tells a writer what to say.
Evidence-based fields behave differently because they carry a source. "Chief of Staff roles are poorly defined" is a template statement. A dated LinkedIn post reading "I have read more than two hundred Chief of Staff job descriptions. No two describe the same job" is a writable fact — it supplies a specific number, a named author whose post can be read, and a phrasing the reader may have already seen in their own feed.
Founders writing their own outbound. Selling into a title they have never held, with no research team, and needing to know what that person is measured on before writing the first sequence.
Product marketers entering a new segment. Extending an existing product into a new buyer role and needing evidence of what changes about the pitch, not a restatement of the current persona with the title swapped.
Sales leaders building enablement. Producing a one-pager reps will actually open, where objection handling references what buyers in that role have said publicly rather than what the team assumes they will say.
Agencies onboarding a new client. Needing defensible research output early in an engagement, where "we assumed" is not an acceptable answer to "where did this come from."
Each method is genuinely better at something. Buyer interviews remain the strongest method for understanding why a decision was made — no research process that reads public material can replace asking someone directly.
The "Partly" is accurate and worth reading closely. Public posts show what people in a role complain about; they do not show why a particular buyer signed a particular contract. That answer comes from interviews, and this task does not substitute for them.
Sai reads live sources rather than recalling training data. For a persona covering Chief of Staff at a fintech, the run pulled from a current Ramp job description, a published Chief of Staff Network AI report, and dated LinkedIn posts from people in the role — each attached to the claim it supports, as a link the reader can open.
The output separates what the role formally owns from what it is informally judged on. In the fintech Chief of Staff run, the formal measures were board materials delivered on time and OKR completion; the informal one was whether the CEO believes a thing is handled. The buying committee section made the same separation: the Chief of Staff champions the purchase, the CEO signs, and CFO and Compliance are the parties who can stop it.
The five messaging angles are derived from the findings rather than written alongside them. Each traces back to a specific piece of evidence in the persona — which also means a reader can reject an angle by rejecting the evidence under it.
Claims that could not be verified are listed rather than dropped. A persona that quietly omits its gaps reads as more complete than it is.
It does not replace buyer interviews. The Buyer Persona Institute's interview method exists because the reasoning behind a purchase is not usually posted publicly. This task narrows what you need to ask about; it does not answer it.
It does not return contact data. No emails, no phone numbers, no company lists. Apollo, ZoomInfo, and Clay do that, at a scale and field coverage this task does not attempt. If your need is a list of people rather than an understanding of a role, start with lead enrichment for an existing contact list instead.
Community sources are not guaranteed. In the run shown here, Reddit was unreachable from the machine, so community sourcing came from LinkedIn and published reports only. Coverage of a role that discusses its work primarily in forums or private communities will be correspondingly thinner, and the output says so rather than compensating with invention.
It covers a role, not an individual. For research on one named person before a specific call, that is a different task with a different output.
Public visibility varies by seniority and function. Roles that post publicly — most go-to-market, engineering leadership, and operations functions — produce richer output than roles that do not, such as many finance and legal titles at large enterprises.
