AEO and listening
Where should SaaS teams invest in third-party AI citations?
For software as a service (SaaS) teams, start with an answer your customer needs and a page that could substantiate it. Then decide whether you have a legitimate contribution to make, who should make it, and what useful result would justify the work even if no assistant cites the page.
Takeaways
- Evaluate specific pages, tests and conversations. A domain's popularity does not establish the value of contributing to a particular page.
- Match the work to the missing evidence: a reproducible example, a factual correction, an independent product test or a current integration reference.
- Give each opportunity an owner and a completion condition. Community support, editorial relations and partner documentation require different workflows.
- Measure the completed contribution, subsequent answer observations and business outcomes independently. An earned mention or a corrected review does not guarantee an AI citation.
A cited page can matter without being an outreach opportunity
A government standard, an independent benchmark and a technical discussion might all appear in answers about your category. You cannot usefully approach all three with the same request to add your product.
A standard may be valuable because it defines the requirement. A benchmark may be valuable because it tests products under disclosed conditions. A discussion may be valuable because someone documented a problem your customers also face. Start by understanding that role.
Google's review-quality guidance[1] asks reviewers to supply evidence of their own experience and explain meaningful differences between alternatives. Its people-first content guidance[2] emphasizes original value and a satisfying reader experience. These principles support asking for inspectable evidence; they do not establish that a particular placement will increase AI citations.
The central question is: What evidence could we responsibly contribute here? If the answer is only “our brand name,” you do not yet have a brief.
Choose the work before choosing the channel
The investment decision has two parts: whether a page matters to your customer, and whether your team has a contribution the owner can reasonably use. A frequently cited domain answers neither question on its own.
| Source situation | Invest in | Avoid |
|---|---|---|
| A relevant review contains a wrong product fact | A precise correction with current evidence | Turning the correction into a demand for higher placement |
| A publisher wants to evaluate your product | Access, a suitable test environment and subject expertise | Requiring positive findings in exchange for access |
| A partner owns an incomplete integration guide | A jointly maintained, tested example | Republishing the same generic article on many sites |
| A community has an unresolved implementation question | A permitted technical answer from someone who knows the problem | Treating the thread as an ad slot |
| A publisher offers paid inclusion | A commercially reviewed placement with clear relationship and link treatment | Counting purchased inclusion as independent validation |
| The source has no relevant information gap | Observation or no action | Spending merely because the domain appears in a tool’s list |
Start with consequential factual errors and existing customer or partner needs. For other opportunities, compare the evidence you can provide, owner responsiveness, production effort and maintenance cost. Preserve those judgments rather than converting unknowns into a precise probability of earning a citation.
Build an opportunity record from an actual question
Choose a customer question and save several relevant engine responses with their dates and sources. This is an investigation sample, not a market-share estimate. A source appearing repeatedly deserves inspection, but repetition alone cannot establish why it was selected.
Imagine a fictional webhook provider whose users ask whether failed events can be replayed without writing a custom recovery script. The team finds three relevant situations:
- A comparison article says the provider has no replay interface, based on an old version.
- A partner tutorial demonstrates retry handling but never explains replay or duplicate processing.
- A community thread asks how to recover missed events and contains an unresolved implementation question.
The first is a possible factual correction. The second may justify a maintained integration example. The third needs a technical response only if the team's knowledge and the community's rules allow one. None calls for a generic promotional placement.
Before acting, record whether the source was cited in your saved sample, independently found through customer research, or merely suggested by a tool. These origins have different meanings. Do not describe a suggested domain as an observed AI source.
Decide which evidence is missing
Review the relevant page against the task, then select the smallest contribution that could help.
| Missing evidence | Appropriate contribution | Evidence needed before work begins |
|---|---|---|
| A documented capability is described incorrectly | A factual correction for the publisher to evaluate | Exact disputed text, current reference, applicable version and plan |
| A comparison omits a consequential tradeoff | An explanation of the criterion, with supporting facts | Why the criterion affects this buyer's decision |
| A technical procedure cannot be completed | A tested example or troubleshooting explanation | Reproduction steps, environment, expected result and limitations |
| A product has never been tested for a relevant use case | Access and technical support for an independent test | A suitable product, agreed test scope and editorial independence |
| Partner documentation conflicts with your reference | A coordinated documentation update | Named owner on each side and a current interface contract |
| Your company is simply absent from a generic list | Further investigation before requesting inclusion | A clear fit with the list's actual criteria |
A useful submission makes verification easier. For a correction, supply the relevant source passage rather than a link to a homepage. For an example, state the version and failure condition rather than only showing a successful screenshot.
If your own documentation is ambiguous, resolve it before asking another publisher to rely on it. Our citation-gap audit explains how to establish the product fact first.
Separate independent evidence from material you control
A company's announcement remains company-authored evidence when another site republishes it. Several copies can expand distribution without adding several independent tests.
Likewise, an affiliate comparison, a paid demonstration and an unsolicited customer review have different relationships to the vendor. Record the relationship when evaluating the source. The purpose is to understand what the material can substantiate, not to assume that one format is automatically trustworthy.
For an independent product test, propose a task and provide access. Let the reviewer choose the conclusions. Make limitations and commercial arrangements clear. Do not promise a positive result, require a recommendation, or describe vendor-reviewed copy as an independent verdict.
For a comparison, a fair correction can make the page less favorable to your product. If replay exists only on a higher plan, correcting “no replay” should also establish that restriction. A technically true feature mention that hides the qualifying plan does not help the buyer choose accurately.
Apply a contribution gate before spending time
We recommend a short decision gate rather than an unsupported numerical citation score. Answer the following questions for the particular opportunity:
- Is the audience relevant? Identify the customer question and the people who need the answer.
- Is there a material information need? Name the missing, incorrect or untested fact.
- Can we substantiate a contribution? Identify the evidence, test or subject expert.
- Are we allowed to participate in this way? Check editorial terms, community policy and commercial disclosure.
- Who can maintain the result? Name an owner and the event that would make the content stale.
If one answer is missing, decide whether to investigate, defer or decline. Unknown information should not become a confident low-effort estimate.
Among opportunities that pass, do consequential corrections first, then contributions with a clear customer or partner need. Compare effort using the actual work: engineering review, test access, writing, relationship management and maintenance. Keep any priority order labeled as a team judgment.
Community participation needs a support standard
A technical thread is a conversation with people who have their own goals. Read the complete discussion. Check whether the question is still open, whether another person already supplied the answer, and whether your proposed steps match the stated environment.
Reddit's Reddiquette[3] asks participants to read the rules of a community before submitting. Local rules still govern the particular contribution. Hacker News's guidelines[4] prohibit generated text in posts and say not to automate posting. A general marketing workflow cannot override those policies.
When participation is appropriate, make the answer useful in the thread: the cause you can substantiate, the steps, the expected result and relevant limits. Disclose your relationship to a recommended product. Link a precise reference when it helps the person complete the task. Do not manufacture a question or recruit accounts to simulate independent agreement.
The useful outcome is a resolved or better-understood technical problem. Indexing and future citations remain separate observations. For the editorial checks, see our guide to replying to developers.
Assign ownership by the kind of work
One queue can record the opportunities, but it should not force every owner into the same action.
| Contribution | Lead owner | Review partner | Completion evidence |
|---|---|---|---|
| Incorrect capability in a review | Product marketing or communications | Product subject expert | Reviewed correction and the publisher's eventual decision |
| A broken integration procedure | Developer relations or partner engineering | Documentation owner | Tested procedure and published version, if accepted |
| An unresolved technical question | Support or developer relations | Engineer when needed | Correct, permitted response or a documented decision not to reply |
| An independent evaluation | Communications or partnerships | Product test owner | Disclosed test scope and independent published findings |
| Original category research | Research or content lead | Method reviewer | Public method, data rights and reproducible calculations |
If a publisher declines a correction, preserve the correspondence and evidence internally. A declined request is not permission to publish the same pitch through unrelated accounts. If a thread is closed or a moderator removes a contribution, follow that community's process.
Use a brief that remains useful after the next model update
Copy this record before contacting anyone. It contains the information needed to decide whether the work deserves an owner's time.
| Field | What to write |
|---|---|
| Opportunity | Exact page, source or thread URL |
| Origin | Saved engine citation, customer research or proposed source |
| Customer task | The decision or procedure the reader needs to complete |
| Evidence gap | Specific missing or incorrect fact and its consequence |
| Proposed contribution | Correction, test, example, expert explanation or no action |
| Supporting material | Current references, reproduction or proposed test method |
| Participation conditions | Community policy, editorial terms and relevant relationship |
| Owner and reviewer | People responsible for accuracy and contact |
| Completion | What would establish that the contribution was made and reviewed |
| Maintenance | Review trigger, product version or changed policy |
| Follow-up observations | Answer sample, referrals and customer outcomes, recorded separately |
Our recommended acceptance condition for the fictional stale review would be: the publisher has the current replay reference and applicable plan restriction, and the requested factual correction is clear. Whether the publisher accepts the change and whether an assistant later cites it are later events.
Worked publisher brief: correct the plan, preserve the limitation
The following example continues the fictional replay audit. It is a draft for review, not a message sent to a real publisher.
| Brief field | Completed example |
|---|---|
| Exact source | delivery-review.example/webhook-tools, RelayDesk section |
| Origin | Displayed source in a saved answer to the self-serve replay question |
| Disputed passage | “Replay requires an Enterprise plan” |
| Supporting evidence | Current replay reference, Team plan reference and role-permission reference; dated copies retained with the brief |
| Requested correction | State that support admins can replay retained events on the self-serve Team plan; preserve the documented retention limit |
| Commercial relationship | Product employee requesting a factual correction; no payment offered in this example |
| Owner and reviewer | Product marketing handles contact; support engineering verifies the procedure and references |
| Completion | The publisher has the exact correction and evidence. Acceptance, refusal or no response is recorded independently |
| Maintenance | Recheck when plan eligibility, roles or retention change; the same owner maintains the publisher record |
The accompanying note could read:
I work on RelayDesk. Your webhook comparison says replay requires Enterprise. Our current replay and plan references document support-admin replay on the self-serve Team plan, subject to the stated retention limit. Here are the exact references and the procedure our support engineer checked. Would you review that qualification? The remaining comparison and recommendation are yours to assess.
This request corrects one claim and discloses the sender’s relationship. If the publisher instead proposes a paid update, record that as a different commercial request before deciding whether to proceed. Do not retroactively describe paid inclusion as the outcome of an independent test.
Budget for the contribution you can verify
Count internal preparation as well as publisher fees: technical verification, writing, access for tests, contact, follow-up and later maintenance. Record actual effort per completed contribution. For a paid placement, separately record the agreed scope, price, acceptance evidence and relationship disclosure. A cost per accepted placement is not a cost per AI citation.
Set a bounded contact plan. A team might send one precise request and one relevant follow-up, then close or defer the record if there is no reply. That is an operational choice, not a community or publisher entitlement. Respect an explicit refusal and avoid moving the same request to unrelated accounts.
Use a portfolio of outcomes to decide whether to continue: corrections accepted, tested material published, relevant referral sessions, useful customer feedback and the total effort. A placement that sends no qualified readers and supplies no meaningful information deserves reconsideration even if an assistant once cited its host.
Where Ears Cite fits
Ears Cite is EarShots' managed citation-outreach offering. Its product workflow takes the prompts you want to appear for, a concise explanation of product fit, and a monthly publisher-payout budget. EarShots identifies relevant AI-cited articles, finds their named authors and manages outreach and replies. Publishers decide whether to include the product.[7]
Use the evidence brief above to make the request specific: which article, which buyer requirement, what supporting product facts, and why an inclusion would help that reader. A fit explanation should preserve plan restrictions and meaningful limitations. The managed service handles the publisher-contact workflow; it does not replace the underlying product evidence.
A publisher payout is a commercial arrangement. Keep it distinct from an independent review or a claim that the publisher tested the product. For links that are paid placements, Google documents the sponsored qualification and accepts nofollow as an alternative.[6] A publisher agreeing to add a product is also different from an assistant later retrieving or citing the updated page.
What should you measure?
Use three records. The first captures work: a corrected reference, a tested example, an accepted contribution or a reasoned decision not to participate. The second captures engine observations for the same saved questions. The third captures measurable audience or customer outcomes, such as qualified visits or support resolution.
Do not multiply completed contributions by an assumed citation rate. Do not count the same syndicated announcement as independent validation by every host. If the source is never cited again but its correction prevents a buyer misunderstanding, that may still justify the work.
Google's spam policies[5] cover manipulative practices including link spam and scaled content abuse. A plan to distribute thin promotional copies primarily to manipulate results is a poor substitute for evidence a reader can inspect.
Bring a specific evidence brief to Ears Cite
Explore Ears Cite with three prompts and a clear explanation of where your product fits. Use the contribution gate to identify the evidence behind a request, and review publisher outcomes separately from subsequent AI-answer observations.
Method and updates
Research checked October 29, 2026. This is an original editorial workflow, not a study of citation uplift. All webhook situations and the publisher brief are hypothetical. The selection and budgeting methods are EarShots editorial recommendations. Product scope is grounded in the first-party description; no campaign, publisher payment or citation-uplift experiment is reported.
Sources
- Write high-quality reviews. Google Search Central. Evidence of first-hand experience and useful product comparisons; no citation-uplift guarantee.
- Creating helpful, reliable, people-first content. Google Search Central. Original reader value and content-quality self-assessment.
- Reddiquette. Reddit. Read and follow the rules of each community.
- Guidelines. Hacker News. Generated-text and automated-posting restrictions.
- Spam policies for Google web search. Google Search Central. Manipulative link and scaled-content policies.
- Qualify your outbound links. Google Search Central. Qualification of advertisements and paid-placement links.
- Ears Cite. EarShots. First-party product description; the workflow was checked against the product source, not a live outreach run.
Download the blank working records for all four guides.