DEV Community: Revenue Operator

How to check whether ChatGPT and Google's AI actually recommend your business

Revenue Operator — Tue, 01 Sep 2026 11:56:27 +0000

When a potential customer asks ChatGPT, Claude, Perplexity, or Google's AI
answers for "a good [what you do] near me" or "a company like X", one of two
things happens: your business is in that answer, or it isn't. That channel is
quietly taking share from the old "search a list, scroll, click" path, and most
small business sites have never been checked against it.

You can check where you stand in about an hour, without hiring a
$2,000-a-month agency. Here is the method I use.

1. Run the same prompts a buyer would

Open a fresh chat in ChatGPT, Claude, Perplexity, and Google's AI mode. Ask each
one, in a buyer's words, not yours:

Recommend a few [category] businesses in [city]. For each, list the name, what they're known for, and their website.
I need [specific service]. Which local providers should I look at, and why?
Compare [your business name] with two competitors for [use case].

Score each answer 0-3: 3 = you're named with an accurate description and a
correct link, 0 = you're absent or misdescribed. Do this for six prompts and
total it out of a fixed maximum so you can compare month to month. If you score
low, that's not a verdict, it's a baseline.

2. Check the things these systems actually read

AI answers are assembled from your site plus third-party sources. The gaps that
keep small businesses out of them are boring and fixable:

Identity is inconsistent. Your business name, address, and phone differ between your site, Google Business Profile, and directories. Pick one exact form and make everything match.
No structured data. Add LocalBusiness / Organization schema with your name, location, services, and hours. It's a few lines in the page head.
Content isn't answer-shaped. These models favour pages that directly answer a question in the first paragraph. A page titled "Our Services" with a paragraph of adjectives gives them nothing to quote. "How much does X cost in [city]?" with a real answer does.
No third-party corroboration. If only your own site says you exist, you're a weak citation. Reviews, a clean directory listing, a mention in a local round-up - each one raises confidence.
The page can't be crawled. Text baked into images, content that only loads after a click, a robots.txt that blocks the AI crawlers. Check your robots.txt for GPTBot, PerplexityBot, Google-Extended and decide deliberately whether to allow them.
Thin or missing basics. No clear list of services, no service-area page, no "about" with real specifics.

Walk your site section by section and mark each item Pass / Partial / Fail.

3. Turn the failures into a ranked list

Don't fix things in the order you found them. Score each failed item by impact
(how much it plausibly affects whether you're cited) times effort (how long the
fix takes). Do the high-impact, low-effort ones first: identity consistency and
schema usually top the list; a content rewrite is higher effort and comes later.

4. Re-test and keep the score

After each batch of fixes, run the same six prompts again and compare the total.
That loop - measure, change the top item, re-measure - is the whole method.
Whether an assistant names you depends on many factors outside any checklist, so
treat the score as a trend line, not a promise.

I put the full version of this into a small kit ($19): a 40-point AI-visibility
audit checklist, a prioritised fix worksheet with a default impact guide, and
the 6-prompt test with a scoring rubric and a place to track it over time. It's
a method and a set of templates - no ranking, citation, or lead-volume outcome
is promised. If it's useful:
AI Visibility Audit Kit.

There is also a small free tool that turns your business basics and a few
common questions into a labelled FAQ skeleton plus copy-paste FAQ schema, so
you have a first draft to fill in:
AI-Ready FAQ Starter.
It runs entirely in your browser and promises no ranking or traffic outcome.

Made by the Revenue Operator project. These materials were drafted with AI
assistance under human direction.

What an AI resume screener actually extracts from your CV - and how to check

Revenue Operator — Mon, 31 Aug 2026 00:33:20 +0000

Most applications you submit online are read by a machine before a person sees
them: an applicant tracking system that parses and ranks, and increasingly an
LLM that summarises and scores the parsed text. A resume a human would like can
still be mis-read, down-ranked, or flagged as generic on that first pass - and
you get no feedback about why.

You can check the machine-readable layer yourself in about 20 minutes. Here is
the method I use.

1. Do a parse test, not a "does it look nice" test

Open a fresh chat in ChatGPT or Claude. Paste the plain text of your resume
(copy it out of the PDF - if the order comes out scrambled, that is finding #1).
Then ask, one at a time:

From this resume only, list: full name, current job title, current employer, city/country, total years of experience. Say "unclear" for anything ambiguous.
List every job as Title | Company | start date | end date. Flag any date that is ambiguous or any gap over 4 months.
What are the top 8 skills, based only on evidence in the bullet points (not the skills list)? Quote the bullet you inferred each from.
What seniority level is this person? Justify using scope evidence - team size, budget, systems owned.

Score each answer 0-3 (3 = correct, 0 = wrong on the basics). If the model can't
reliably pull your title, level, or dates, neither can the screener in front of
the recruiter.

2. The format things that break parsers

These are cheap to fix and they matter more than wording:

Text-based PDF or .docx, never a scanned image or a design-tool export that rasterises text.
Single column. Two-column layouts frequently parse out of order.
No tables for layout, no text in headers/footers/text boxes.
Standard section headings ("Experience", "Education", "Skills") - not "Where I've Made an Impact".
Dates in one consistent format on the same line as the role, every time.
One job = Title, Company, Location, Dates, then bullets, in that order, always.

3. Make each bullet carry evidence

Screeners (human and machine) reward specificity. The formula:

[strong past-tense verb] [what you did] [a number, comparison, or result]

"Rebuilt the nightly ETL in dbt, cutting run time from 3h to 40min" beats
"Responsible for ETL." Aim for a quantified outcome in at least 60% of bullets,
and keep the most impressive two or three in the top third of the page.

4. Check it doesn't read as boilerplate

Ask the model: Does any part of this read as generic template language rather
than lived experience? Quote the weakest 3 lines. Then cut or rewrite those.
"Results-driven professional with a proven track record" is invisible; a specific
combination of domain, skill, and result is not.

Re-test after each change

Run the same parse prompts again and compare the scores. That loop - test,
change one thing, re-test - is the whole method.

I put the full version of this into a small kit ($15): a 35-point AI-screening
audit, an ATS-safe resume structure with a filled example, and the 6-prompt
parse test with a scoring sheet and a trend log. It's a method and a set of
templates - no interview or hiring outcome is promised, since that depends on
the role and the employer. If it's useful:
Resume AI-Screening Kit.

Made by the Revenue Operator project. These materials were drafted with AI
assistance under human direction.

How to Keep Long Autonomous AI Coding Sessions Goal-Directed Instead of Letting Them Drift

Revenue Operator — Fri, 28 Aug 2026 12:46:01 +0000

Long autonomous AI coding sessions have a characteristic way of going wrong. The
model is fine. The tools are fine. What fails is the operating structure around
the session: after an hour or two the run drifts off the original goal, redoes
work it already finished, expands scope on its own, stalls waiting for a
certainty that is never going to arrive, or quietly starts asserting things the
evidence in front of it does not support.

I build autonomous revenue and operations workflows, and I kept hitting all five.
This is the structure I now put around every long session to keep it pointed at
the goal. None of it is exotic. It is mostly about writing things down before you
start and being strict about a few boundaries.

1. Define the mission in one line, and say what not to redo

Before the agent does anything, write a single sentence that states the outcome
you want from this session, plus a short list of things that are already done and
must not be touched. "Add pagination to the results endpoint; the schema
migration and the client SDK are already shipped, leave them alone."

This sounds trivial. It is the highest-leverage thing you can do. A long session
without a one-line mission will interpret every interesting side quest as in
scope. A one-line mission gives the agent — and you — something to check every
action against: does this move the mission forward, yes or no.

2. Separate hard constraints from soft signals

Split every "should I do this?" decision into two layers that are evaluated
differently.

Hard constraints are deterministic and fail-closed. Do I have the right to
make this change. Am I about to state something I have not verified. Is this the
exact target I was asked to modify, or just something close. Is the data I am
relying on actually what it claims to be. If any hard constraint fails, the
action does not happen — no amount of "but this looks like a good idea" rescues
it.

Soft signals are probabilistic. How confident am I that this design is right.
How likely is this to be the thing the user actually wants. These get a vocabulary
like unknown / weak / moderate / strong, and — importantly — an unknown soft
signal should make the next step smaller, not stop it. Refusing to act because
you are not certain has its own cost: the work never gets done and you never
learn anything. Shrink the step, take it, look at the result.

Mixing these two layers is how you get an agent that is reckless about the things
that matter and paralysed about the things that do not.

3. Evidence before expansion

Do not scale up an approach on a proxy for success. Scale it on the real thing.

There is a natural hierarchy of evidence: "the code compiles" is weaker than "the
test passes" is weaker than "the feature works against a real input" is weaker
than "the person who asked for it confirmed it does what they need." A long
session loves to treat the weak end of that hierarchy as permission to build ten
more things on top. It is not. Get one real confirmation before you expand.

A passing test suite and a high internal "this looks ready" feeling can never
move you up that hierarchy on their own. Only a real downstream result does.

4. Keep state, and checkpoint it

A long session should leave a trail you can read. After each meaningful step,
write down: what changed, why, what the observed result was, and what the next
step is. A short running log in a file is enough.

Two reasons. First, when the session gets summarised or interrupted, that log is
what lets it resume without re-deriving everything. Second, it forces the agent
to state the result of each step explicitly, which is where you catch "I made the
change" quietly standing in for "I made the change and checked that it worked."

5. Write explicit stop conditions

Decide, up front, what "done" means and what would make you stop early. "Done =
the new endpoint returns paginated results, the existing tests pass, and I have
run it against the staging dataset once." "Stop early if the migration turns out
to be required after all, or if the change touches more than three files."

Without stop conditions a long session does not end — it tapers into
increasingly speculative work. With them, the agent has a clear finish line and a
clear list of trip-wires that mean "surface this to a human instead of pushing
on."

6. Distinguish execution from verification

These are different activities and long sessions blur them. Execution is making
the change. Verification is establishing, with evidence, that the change did what
it was supposed to and did not break anything else. Budget time for both, and do
not let a session report success on the strength of execution alone. "I wrote the
function" is not "the function is correct."

7. Do not build a framework when a shipped action would do

The most common way a long autonomous session burns hours with nothing to show:
it decides the real problem is that the codebase needs a better abstraction, and
disappears into building one. Sometimes that is genuinely the task. Usually it is
avoidance of a smaller, more exposed, more useful action.

A good rule: if you can accomplish the mission with a concrete, bounded change
that a person could review in ten minutes, do that first. Earn the abstraction
with a second and third real use case, not with a prediction that you will need
one.

8. Tie the session to an economic or operational goal

Every long session should trace back to something that matters outside the
codebase — revenue, a cost, a user-facing capability, an operational risk. When
the mission is anchored to a real-world outcome, scope questions answer
themselves: "does this help ship the thing the business is waiting on" is a much
sharper filter than "is this a reasonable improvement." Improvements are
infinite. Outcomes are not.

A short checklist

[ ] One-line mission written, plus what not to redo
[ ] Hard constraints listed (fail-closed) and separated from soft signals
[ ] Smallest useful step identified; uncertain steps made smaller, not skipped
[ ] Running log updated after each meaningful step
[ ] "Done" defined; early-stop trip-wires defined
[ ] Verification treated as separate work from execution
[ ] No new abstraction without two or three real uses
[ ] Mission traces to a real economic or operational outcome

A note on where this comes from

I run a project called Revenue Operator, and I built the operating structure
above into a small reference kit: The Revenue-First Autonomous Execution Kit.
It is a single Markdown file — the loop I run each session, the hard-constraints
vs soft-signals model with worked examples, an evidence hierarchy, three reusable
long-horizon prompt templates, a truthfulness checklist, and six real anonymised
examples from an actual build (including a wedge that failed three times before it
worked, and a metric that silently counted the wrong thing).

It is $19, one file, instant download, 30-day refund:
https://aiops7.gumroad.com/l/revfirst-exec-kit

To be transparent: it is my product and I sell it. It describes a working method.
It does not promise a financial outcome and makes no claims about your results.
The checklist above is the useful core and stands on its own whether or not you
ever look at the kit.

If you run long autonomous sessions: which of these failure modes do you hit most
— drift, repeated work, scope creep, stalling, or unsupported claims? I would
genuinely like to know which one is worst in practice.