Local Business Growth Audit
Produces a BOOKED Score (0–100) plus a letter grade and a prioritized fix list for a single local service business, then renders it as a self-contained HTML report.
This skill exists because local service businesses lose revenue at six specific points between "someone searches" and "someone shows up." It scores those six, and nothing else.
The one rule that matters
Never invent a signal you did not observe. Every score line is either observed
(you fetched it), reported (the user told you), or unknown. An unknown is scored as
zero and shown as unknown in the report — it is never quietly averaged away or guessed.
A fabricated audit is worse than no audit: the owner acts on it, the fix doesn't work, and the report is the reason they stop trusting the sender. If you cannot observe something and the user cannot tell you, say so in the report.
Process
1. Establish the subject
Get the business name plus a city, or a Google Maps URL, or a website. If you have only a name, ask for the city — local audits are meaningless without a location.
Ask which vertical it is. If it is a dental practice, stop and use the
dental-practice-audit skill instead, which extends this one with recall, treatment
acceptance, and insurance-specific checks.
2. Collect evidence
Follow references/evidence-collection.md. It lists, per dimension, exactly what is
observable from outside the business and what has to be asked. Work through it in order.
Do not spend more than a few fetches per dimension. Breadth across all six beats depth on one — an audit that scores findability perfectly and leaves the other five unknown is not an audit.
3. Score
Apply references/scoring-rubric.md. It is the authority for point values. Do not
improvise weights, do not add dimensions, and do not round scores upward to be kind.
The six dimensions and their weights:
| # | Dimension | Points | What it measures |
|---|---|---|---|
| 1 | Findability | 25 | Can a searcher with money in hand find them at all |
| 2 | Proof | 20 | Once found, do they look worth calling |
| 3 | Speed to lead | 20 | How fast an inbound enquiry gets a response |
| 4 | Booking friction | 15 | Clicks and minutes between intent and a held slot |
| 5 | Follow-up | 10 | What happens to enquiries that didn't book |
| 6 | Reactivation | 10 | What happens to customers who stopped coming |
Grades: A 90–100 · B 80–89 · C 70–79 · D 60–69 · F below 60.
Speed to lead is weighted at 20 on purpose. It is usually the cheapest thing to fix and the one owners most consistently underestimate.
4. Build the fix list
Rank every failed check by (points recoverable) ÷ (effort). Effort is low (under an
hour, no new tooling), medium (a day, or one new tool), or high (structural).
Report the top 5 only. A 30-item list does not get actioned; five do.
For each: what is wrong, what to do, points recoverable, effort, and — where it applies — the specific number it should move (calls answered, reviews per month, minutes to first response).
5. Render the report
python3 "${CLAUDE_SKILL_DIR}/scripts/render_report.py" scorecard.json -o report.html
Write the scorecard JSON first; the schema is documented at the top of that script and in
references/report-template.md. The script is stdlib-only and emits one self-contained
HTML file with print CSS — the user opens it and prints to PDF. It does not phone home and
does not require a browser engine.
Then tell the user the file path and that Print → Save as PDF produces the shareable copy.
Scope
In scope: one business, six dimensions, observable evidence, a graded report.
Out of scope: rank tracking over time, backlink analysis, paid ad account access,
writing the actual review responses (use review-response-writer), and building the
automations that fix what this finds. This skill diagnoses. It does not treat.
References
references/scoring-rubric.md— every check, its point value, and its pass conditionreferences/evidence-collection.md— what is observable vs. what must be askedreferences/report-template.md— scorecard JSON schema and report structure