All insights
XINDAR INSIGHT

AI Visibility Monitoring for Multiple Clients: Keep Access, Evidence, and Reporting Separate

An agency analyst copies last month's report, changes the client logo, and refreshes the charts. One competitor alias survives from the old project. A source table still points to the other client's pages. The report looks consistent enough to pass a quick

By Daoyu Guan · October 28, 2026

An agency analyst copies last month's report, changes the client logo, and refreshes the charts. One competitor alias survives from the old project. A source table still points to the other client's pages. The report looks consistent enough to pass a quick review.

This is a data ownership problem before it is a measurement problem. When an agency monitors AI visibility for several B2B brands, each observation needs a clear client, a documented collection context, and an access boundary that survives exports and shared dashboards. A folder named after the client is only the beginning.

The method below is a proposed operating procedure. The two clients in the examples are fictional, and the checks are procurement exercises rather than results from a completed platform security test.

Start with the client boundary

Create a client record before adding prompts. It should identify the contracting organization, the brands being measured, approved domain names, the project owner, and the people permitted to receive results. A parent company with three product brands may want one combined analysis. Three unrelated agency clients usually need separate access and reporting.

Keep brand aliases inside that record. A short name shared by several companies is an ambiguous match, not an automatic mention. Record which product names and domains resolve the ambiguity, and preserve uncertain matches for review. Do not let one client's alias changes silently rewrite another client's historical classifications.

Product terminology varies. OtterlyAI's official documentation describes separate workspaces with client-specific data and access, alongside administrators who manage resources across them. That is a useful distinction to examine in a demonstration; it does not establish how another vendor's “projects” behave. See OtterlyAI's workspace guide.

Reuse a research method without pooling client evidence

Two clients can use the same general buyer question. An industrial marketing agency might ask which suppliers support small production runs for both a machining business and an electronics assembler. The wording can be shared as a template while the observations, brand definitions, permissions, and conclusions remain separate.

Give the template a version and each client's working question its own identifier. If the electronics client adds an inspection requirement, create a new prompt version for that project. Otherwise a later chart may compare different questions under one familiar label.

This separation also prevents a commercial conflict. An agency-wide benchmark may be useful, but permission to provide a private monitoring service does not by itself establish permission to include that client's identifiable results in a public benchmark. Decide what may be aggregated, shared, or retained before promising cross-client intelligence.

AssetSafe reuse to considerKeep specific to the client
Question templateResearch structure and wording patternApproved prompt version and intended market
Classification guideDefinitions of mention and recommendationBrand aliases and disputed matches
Report templateLayout and calculation explanationsAnswers, source URLs, recipients, and commentary
Improvement checklistReview stepsProduct facts and approved page changes

The table is an editorial allocation model. Actual rights and sharing permissions belong in the engagement's written terms.

Test access with two deliberately different projects

Use harmless fictional data for the first demonstration. Create Client A, a component manufacturer, and Client B, a software company. Put a distinctive test label in each project so a misplaced record is easy to spot. Ask the vendor to demonstrate the following sequence:

  1. Give an agency administrator access to both projects.
  2. Invite a client reviewer who should see only Client A.
  3. Open that reviewer's normal navigation and reporting views.
  4. Attempt to open a known Client B report link while signed in as the reviewer.
  5. Export Client A's results and inspect every client and brand field.
  6. Remove the reviewer, then check whether previously shared links still work.

Record the expected result and what actually happens at each step. A hidden sidebar entry is a navigation observation. The direct-link check tests a different route. Neither substitutes for a broader security assessment, but together they expose a common procurement gap.

API credentials need the same attention. Rankscale's help documentation states that a member's API key follows that member's brand access. Its guide also notes that invitations initially allow broad access unless permissions are restricted. The practical lesson is to test the actual invitation and key configuration instead of assuming that every new client starts isolated. See Rankscale's brand access instructions.

Give each evidence row an owner

A client report should be traceable to original observations. For each run, retain the project identifier, exact prompt version, collection time, platform and surface, answer or failure status, and the related sources. If the product cannot export some of those fields, document the missing context in a companion file rather than pretending it was collected.

Separate a cited website from the client being measured. An answer in Client A's project may legitimately cite Client B. That citation is evidence in A's observation; it does not transfer the underlying report to B or authorize disclosure of A's private analysis.

Keep failures in the operational record. If A has twelve successful answers and B has eight successful answers plus four connection failures, a combined report of twenty successful observations conceals a reliability difference. Report each client's scheduled work, completed work, and unresolved collection separately before creating any agency summary.

Shared dashboards deserve their own review

A dashboard link is another access route. Check whether it is public, restricted to named users, protected by a password, or available to anyone holding the URL. Ask what happens when the recipient forwards it and whether access can expire.

Open a scheduled report as its intended recipient before enabling recurring delivery. Inspect the body, attachments, source tables, dashboard links, and date range. A correctly branded cover cannot compensate for evidence from the wrong project.

Also test the permissions of connected reporting tools. A client-limited account in the monitoring platform may feed an agency-wide account elsewhere. The destination's permissions and cached data need their own review; the first platform's controls do not automatically describe the second.

Plan the client's exit while setting up the account

Define an export package that the client can interpret after the engagement ends. Include the prompt panel, original observations, classification definitions, known gaps, and a record of important changes. Agree separately on continued dashboard access, export assistance, and deletion or retention obligations.

Retention and access answer different questions. Keeping records for three years does not necessarily mean every former user can sign in for three years. Ask who can retrieve retained records, how requests work, and what happens when the agency changes its own subscription.

Xindar GeoWatch is one option to assess for the underlying monitoring work. Its product team has confirmed full-answer and citation-URL exports, as well as retention of at least one year with extensions tied to the agreed service term. Client isolation, roles, export fields, and offboarding behavior still require a specific demonstration; those capabilities should not be inferred from the retention statement.

Questions agencies should settle before onboarding

Can several clients share one prompt library? They can share approved templates. Keep the actual client-specific versions, results, and permissions distinguishable. A shared library should not make a prompt edit rewrite the meaning of every historical report.

Is a project the same as a workspace? Only if the product's documented and demonstrated behavior makes it so. Inspect direct links, exports, reporting integrations, and user roles rather than comparing labels.

What is a useful first acceptance result? Two test clients, one restricted reviewer, an export with correct ownership, and a documented removal test provide a concrete starting point. Record unresolved behavior explicitly before moving real client information into the workflow.

An agency can standardize its method while keeping each client's evidence accountable. That becomes especially valuable when the same analyst manages the prompts, writes the recommendations, and prepares the monthly report.

Sources and method

The access examples and acceptance procedure are editorial proposals, not claims of a completed audit. Product descriptions were reviewed on October 27, 2026. The linked OtterlyAI workspace guide and Rankscale permission guide support the attributed examples. GeoWatch statements come from Xindar's product team; no account security or export test is reported here.

Back to insightsMarkdown version