# How to find buying signals for a target account

_By Nakul Kelkar, September 28, 2026_

A company hiring a data engineer might be building a new pipeline, replacing someone who left or maintaining an existing system. The job listing becomes useful for sales when you can connect its actual requirements to a question your team can answer.

This workflow produces a dated account review: observed changes, source links and a reason to investigate each one. You choose which hypotheses deserve a conversation.

## Define what would change your decision

Before connecting the agent, write down the product you sell and the change that would make it relevant. For a migration service, a job post describing an active platform migration is more useful than a generic technology keyword. For a recruiting service, the location and seniority of open roles may matter more than a funding headline.

Follow the [Vaaya setup guide](https://vaaya.ai/install), then provide a small list of company domains, a date range and a spend ceiling.

```text
Use Vaaya to review [domains] for changes relevant to [product/problem]
between [start date] and [end date]. Consult first and quote the sources.
Budget: [amount]. Collect hiring and company news where relevant.
For each finding, separate the observed event from our buying hypothesis.
Include source URLs, event dates, uncertainty and one question to test it.
Deduplicate stories. Do not enrich contacts or send messages.
```

## 1. Set a rule for a useful finding

Give the agent an inclusion rule before it searches. Require a named account, dated evidence and a link to your product's use case. Exclude stories that repeat an earlier announcement without a new development.

Choose a few signal types that fit your business. Expansion, hiring and a new product launch are possible categories, but collecting every category adds review work. Record what you chose so a later review uses the same scope.

## 2. Collect account changes from current routes

Ask consult to select the sources for the account and quote the requests. Vaaya's [catalog](https://vaaya.ai/api/catalog) includes `akta/news` and `akta/job-posts`. For news, supply at least one of `company`, `industry` or `query`; use `start_date` in `YYYY-MM-DD` form and an explicit `limit`. Check the upper date boundary in returned results yourself.

For a hiring review, `akta/job-posts` requires `company`, accepting a domain or Akta UUID. Optional `limit` and `offset` bound the page. Inspect job titles, descriptions and available dates before describing an initiative.

There is also `theirstack/buying-intents`. Supply a company identifier such as `company_domain`; its filters include `confidence_or`, `last_date_found_gte` and `limit`. Treat a provider's topic and confidence as a derived signal. They do not prove a purchase decision. The [GTM reference](https://vaaya.ai/docs/reference/gtm) documents these data routes.

## 3. Check the underlying evidence

Open the source announcement or job listing for the findings you intend to use. Capture the passage that supports your interpretation and preserve its URL. A title mentioning a tool is weaker evidence of a migration than a description explicitly assigning migration work.

Separate three dates where available: when the event happened, when the source was published and when you retrieved it. Mark absent dates as unknown. Reposted roles and syndicated news can otherwise look like fresh activity on every run.

Deduplicate by underlying event, not merely by URL. Keep multiple independent sources attached to one event when they add confirmation. A copied press release on several domains remains one announcement.

## 4. Rank by relevance you can explain

Use a small review table. The schema below is illustrative and contains no measured account results.

| Column | Review rule |
| --- | --- |
| Account and event | Name the resolved domain and observed change |
| Evidence and date | Link the original source and preserve its timing |
| Buying hypothesis | Explain the possible need in one sentence |
| Counter-explanation | Record another plausible reason for the event |
| Next question | State what a conversation would need to establish |
| Decision | Investigate, watch or discard |

Do not turn every field into a numerical score. A clear reason for discarding a weak match is more useful than a precise-looking number with no definition.

## Keep the next run comparable

Save the selected sources, queries and date window alongside the table. On the next review, check for new evidence and changed events before buying the same enrichment again. Your application or scheduler owns that repeat process.

If a source fails, log the error and coverage gap. If a search returns nothing, say that no matching evidence was found in that search. Avoid concluding that the company has stopped hiring or has no budget.

For the first outreach draft, choose one approved finding and its next question. The prospect should be able to recognize the event and correct your hypothesis without having to undo a claim you presented as fact.

## Questions

**Does a buying signal prove a company wants my product?**

No. Hiring, funding and technology mentions are observable changes or provider interpretations. You still need a plausible connection to the problem your product solves.

**How should I handle an old event in a new article?**

Store both the article publication date and the event date. Use the event date when judging whether the account change falls inside your research window.

**Can this run every week?**

You can repeat the same bounded research from your application or scheduler. Preserve prior evidence and compare new events; this tutorial does not create an automatic monitoring schedule.