Skip to content

Look up a person with People Search

View as markdown

People Search identifies one named person and builds a brief from public sources: their current role, career history, published work, public accounts, and — when your team allows it — a way to reach them. Every claim carries the sources behind it and a date.

It runs in an ordinary chat on the web, desktop, iOS, and Android. On a lower plan the upgrade prompt appears in the chat instead of a search. It cannot run in a chat you are viewing read-only.

The cited brief works on one person at a time. For a list you already have, the separate Lead enrichment action can return structured professional profile data for up to ten leads at once.

Use Lead enrichment when you already know who or what role you want and need consistent profile fields across a short list. A batch can mix any of these inputs:

  • a public LinkedIn or X profile link, or a Facebook vanity profile link such as facebook.com/jane.doe
  • a work or personal email address
  • a first name and employer name or domain, with an optional last name, title, and location
  • a role and company, such as CTO at Acme

Type /lead-enrichment, choose Lead enrichment, and paste or describe the rows. Bearly accepts one to ten leads in each batch. It refuses an eleventh row and does not split or continue a larger list on its own.

Before the lookup starts, review the number of leads and the maximum cost estimate, then select Allow. Successful rows return the public professional profile link, name, headline, location, summary, work history, and education that were available. Failed rows stay in the result with a plain reason, so one miss does not discard the rest of the batch.

Lead enrichment is not the cited brief: it does not read wider web sources, provide citations, or return personal email addresses or phone numbers. Use /people-search when you want Bearly to identify and confirm one person before building sourced research. It also does not search a broad prospect database from open-ended filters; each row must identify a person or one role at one company.

  1. Start the search

    Type /people-search, choose People Search, and give the name plus at least one detail that separates this person from everyone else with the same name: a company, a city, a school, a role, or a profile link. Asking for it in ordinary language works too.

    /people-search Sarah Chen, product lead at Plaid in San Francisco

    Given only a name, Bearly asks for one detail before it searches. Given a profile link, an email address, or a handle, it may resolve to a single person and take you straight to the confirmation in step 4.

  2. Read the candidates

    A People Search card appears with up to five people. Looking for restates what Bearly understood as chips, so you can see it read your request correctly. Checked n sources counts the public sources read so far.

    Each row carries a photo, a headline and location, distinguishing facts, a one-line reason the person was included, and a result for each detail you gave, such as MATCHES ROLE or NO DATA: SCHOOL. Match strength is a word — Strong match, Likely match, or Possible match — never a percentage. If you searched on a name with no other detail, no row reads stronger than Possible match and the card says why.

    Compare puts candidates side by side. Columns are numbered in the card’s order so you can tell namesakes apart, and they wrap to fit the space. Long values clamp, with the full text on hover. A column with nothing to show says only that nothing beyond the name came back. Comparing is free and does not spend a search.

  3. Narrow the list if none of them are right

    Add a detail opens a panel: type the detail, check Kind, and select Add detail. None of these clears the list and searches again.

    Both re-run the search, and both spend one of the card’s searches. The footer counter — n of n searches used — is the whole budget for this card. When it is spent, the card explains that it will not run again; pick someone from the list, or start a new search with a profile link, email, or handle in it, which narrows far better than another detail would.

    Cancel stops a search that is still running. Searches already spent stay counted.

  4. Confirm the person

    Select This is them. A panel opens naming that person and the estimated cost of the lookups; Build brief starts them.

    This step is what the card is for. Building a brief is the expensive part of People Search, and it researches exactly one person — the one you confirm. Nothing is looked up about a candidate you passed over.

The card then collapses to a single confirmed row, and the brief assembles below it.

While it builds, a row of chips shows each lookup — Web presence, Writing & talks, X history, GitHub, Contact route — with its state and a plain sentence about what it found, skipped, or could not finish. Mid-run, empty tiles read Gathering… and unwritten sections say what is still coming; chips like Corroborated appear only after the run finishes. One lookup coming up empty does not stop the rest, and once the brief is up, whatever was blocked or did not finish is folded into one plain sentence near its top — a lookup that simply found nothing is an answer, not a failure, and is not listed there.

The finished brief opens with a photo, name, headline, location, an Updated date, and Refresh, over four tabs:

  • Overview — four fast facts (Current role, Employer, Location, Last active), each with its source and date; a short written summary with numbered citations; and a Career timeline of dated roles and schooling.
  • Work & ideas — a cited account of the person’s work, Recurring themes, and the dated record grouped under Shipped, Talks & panels, and Writing, each entry with its venue and date; anything else lands under Other work or Other dated work. Long lists collapse behind See n more.
  • Public presence — an Accounts card per platform with the dates that platform publishes and a follower range rather than a follower count, a dated Activity list, and a section headed From their public writing: how the person writes in public, not a conclusion about who they are.
  • Sources & confidence — every claim beside its sources. A chip row grades how well each area is covered, from the same claims listed under it. Every claim is a row; expand it for the verbatim quote behind each source. The full source list sits below, each entry with its domain and date.

Citation numbers throughout the brief jump to Sources & confidence and highlight the matching source row; the row itself opens the page.

Reach out sits under the sections when your team allows contact routes. The best route is on top, with the value masked until you select Reveal and a chip saying in plain language what was and was not checked — Accepts mail means a verifier confirmed the inbox accepts mail, and nothing more. Revealing is free; the value is already in the brief. Alternates and an Also on row of public profiles follow.

Bearly never guesses an X handle or a GitHub login from a name. If no account was found on the record, that lookup is skipped and says so.

Facts are dated individually, not by when the run happened. A tile reads as of the month its source published when the page carried a date, and the date Bearly read the page when it did not. A fact whose newest source is old is tagged past.

In Sources & confidence, each claim carries one of four labels:

Label What it means
Corroborated Two or more independent sources state the same thing.
Partial · inferred One source only, or a value inferred rather than read directly. Check it before you rely on it.
No data Nothing was found either way. This is not a failed lookup.
Conflicting Sources disagree. Both values are kept.

When sources disagree about a fact, the Overview tile shows a Conflicting chip that takes you to Sources & confidence, where both values stay visible with their own dates and sources and a line saying the brief does not choose between them.

Bearly does not choose between them, average them, or drop the older one. A person who changed jobs last month and a directory that has not caught up are both telling the truth about different moments, and which one matters depends on why you are asking. The written summary says the fact is unclear rather than asserting one side.

Refresh re-runs every lookup for the person you confirmed and reports what changed. It costs what the first build cost, so it asks again, with the estimate shown, before it starts.

The previous brief is kept, not overwritten. When the new run finishes, a What changed strip appears above the tabs with up to ten lines marked New, Changed, or No longer reported, each with its own citations. Closing the strip keeps the brief.

Refresh before outreach, or after news you expect to have changed the person’s role. There is no reason to refresh on a schedule — nothing in a brief changes hour to hour, and each refresh is billed.

On the record is a collapsed band at the bottom of the brief, and a separate paid action from the brief itself. It runs one check for US public records about the person you confirmed — criminal and corrections records, plus any court filings or other findings that come back with them. It never runs as part of a build or a refresh, and nothing it finds is written into the brief’s summary.

  1. Expand the band

    It states what the check covers, offers an optional Date of birth field, and carries the informational-use notice below.

  2. Add a date of birth if you have one

    Optional, and used for this check only. It narrows the match, and it is the strongest single detail you can give: a record that matches on name and date of birth is a different thing from one that matches on name alone.

  3. Run the check

    Select Run records check, then Confirm on the estimate the band shows. The check needs a first and last name plus a city, a US state, or a date of birth; when it does not have enough to search against, the band says so instead of running.

Findings come back grouped by the kind of record they are, each with a jurisdiction, a date, and a plain sentence about what was matched:

  • Strong match — the name plus a second identifier lines up with the person you confirmed. When some records tie and others do not, the collapsed band counts both: n records · m unverified.
  • Possible · unverified — kept in its own muted group, Possible matches — unverified. These share a name and nothing else that could be checked; any of them may belong to a different person with the same name. Rows with nothing to show beyond their kind fold into one counted line each rather than stacking.

When not one returned record could be tied to the person you confirmed, the results say so up front, the collapsed band reads None tied to this person · n possible, and the band offers Check again with its own Date of birth field — a date of birth can show whether those rows belong to this person. Checking again is a second paid check with its own confirmation.

A check that finds nothing is still a complete answer: the band reads No public records found · checked date. It is billed the same as a check that returns records.

  • It works best on people with a public professional presence. Someone who publishes, speaks, ships code, or holds a role their employer names in public is well covered. Someone whose professional life appears only in a licensing registry, or barely appears at all, may come back thin, or not at all.
  • It can fail to find the right person. Common names, people who share a name with someone more prominent, and people who keep a small public presence are the hard cases. When nothing matches, the card says so rather than filling the space; add a detail or start again with a profile link.
  • A brief is a reading of public sources, not a verified record. Read the reason on the card and the sources in Sources & confidence before acting on anything consequential. A Partial · inferred claim is one page’s word.
  • It is not for screening people. People Search is built to help you recognize and prepare for someone — a candidate you are about to interview, an author you are about to email, a founder you are about to meet. It is not a background check, and the records band’s limits are not a formality.
  • A shared chat opened read-only can be read, not run. Open your own chat to start a search, refresh a brief, or run a records check.
What you see What to do
/people-search offers nothing Your team’s policy turns People Search off. On a team whose policy disables features by default, an administrator has to switch it on.
Bearly says People Search needs the Analyst plan The upgrade prompt is already in the chat. People Search needs Analyst or higher.
Bearly asks for a detail instead of searching Add a company, city, school, role, or profile link. On a bare name the result would be a guess.
Nobody came back for this name and these details Add a detail, or search again with a profile link, email address, or handle.
Every candidate reads Possible match The search had no detail to work with, or nothing corroborated one. Add one rather than trusting the top row.
The card says its searches are used up It will not search again. Pick someone from the list, or start a new search — with a link, email, or handle if you have one.
A lookup chip reads skipped or did not finish Select the chip for the reason. A missing account, a source that did not answer, or a team policy each read differently. Refresh re-runs them.
Reach out is missing entirely Your team’s policy turns off contact routes.
On the record is missing entirely Your team’s policy turns off public records.
The records band will not run It needs a first and last name plus a city, a US state, or a date of birth. Add a date of birth if the location cannot be placed in the US.
A records check is still Checking public records… long after you closed the tab Reopen the chat and give it a few minutes. A check whose tab went away is released so the band can run it again.
The findings from a completed check are gone The band says when the findings are no longer stored in the chat. Run the check again if you still need them.

Managed-team administrators control availability from Teams → team name → Policies → policy name, under Web & Research: a People Search switch, plus separate People Search contact routes and People Search public records switches beneath it. Turning People Search off hides the other two. A switch nobody has set follows the policy’s own default — Enabled by default or Disabled by default.