---
name: classify-and-offer-knowledge-panel
description: "Choose the right next step for your name on Google."
category: Personal Branding
stage: —
definitive_article: /knowledge-panel
status: needs-work
---

# Classify and offer Knowledge Panel

Choose the right next step for your name on Google. This guide checks what is there before your team offers panel work. Start with a fresh search and the current terms your business has approved.

**The path:** Live search + proof → Claim / Build / Contested → Current terms → Offer draft

**Start when:** An accepted prospective engagement needs an evidence-based panel-work recommendation and a matching draft offer.

## Inputs

- The person’s accepted public name, role, home site and existing identity evidence.
- Current search access, the approved service terms and qualification rules, and the actual commercial decision owner.
- [Current owned package page](https://localservicespotlight.com/knowledge-panel-package/) and [Google’s account of how panels work](https://support.google.com/knowledgepanel/answer/9163198?hl=en); reconcile any conflict with the accepted engagement before quoting.

## Steps

1. Run a fresh name search and record query, location or locale where known, device, date and screenshots. Inspect the result’s identity, not merely the displayed name. A signed-out search reduces some personalization but does not remove all contextual variation.
2. Classify Claim/correct only when the right panel offers the needed claim or edit route. An existing entity ID without that route is evidence of an entity, not claim-ready delivery. Classify Build as supported identity/proof work still needed; use contested review for ambiguity or a crowded name.
3. Check the person’s existing public home, verified profiles and independent evidence. State the actual gaps and the services within scope. Do not promise that a checklist, payment, name domain or schema will force Google to display a panel.
4. Read the current approved price, deposit, milestone and refund terms from their maintained source. The older skill’s dollar bands and duration ranges are historical source copy; this recipe does not set a new price or repeat them as current without that check.
5. Draft the matching recommendation with the evidence, exact deliverables, owner-controlled verification account, dependencies and accepted commercial terms. Tie each milestone to its actual contract definition. Keep proposed service work distinct from Google’s decision and from a completed claim.
6. Route ambiguous scope, conflicting terms and contested identities to the responsible commercial or entity-review function with the finished evidence packet. A named colleague’s availability is not a reason to pause safe research, nor authority to send an unapproved offer.
7. Save the decision and draft. Send only under existing authorization and record the exact sent version when it happens. The classification task is checked when its evidence and matching proposal are reviewable; a sale or a panel is a later outcome.

## Definition of done (QA checklist)

Quality assurance (QA) means checking the actual result against its agreed requirements. Follow the [Article Guidelines](https://localservicespotlight.com/article-guidelines/).

- [ ] The recommendation distinguishes identity evidence from an actual claim/edit route.
- [ ] All quoted commercial terms match the current approved source; unsupported timing promises are absent.
- [ ] The evidence-backed offer remains accurately labeled draft or sent, with the next owner named.
- [ ] The exact output, source revision, reviewer evidence and remaining owner action are saved.
- [ ] For any reader-facing output, the short grade-five opening states the reader’s useful outcome and supporting method or proof. The body delivers that promise; a useful authentic visual appears in the first screen. Retain exact text and quoted reviewer evidence.

## Example(s)

**Fictional teaching example. This is not a client result or proof of a completed run.**

A fictional accountant has a name shared by a musician. The visible card belongs to the musician. The team prepares a contested-identity review with the accountant’s true work and site. It does not sell a ready-to-claim service or borrow an old price; the current offer owner must supply the actual terms.

## Handoff and Content Factory context

[Resolve identity facts](https://local-service-spotlight.github.io/task-library/?task=establish-entity-identity#task-establish-entity-identity) or [Claim the available panel](https://local-service-spotlight.github.io/task-library/?task=claim-and-verify-knowledge-panel-when-it-appears#task-claim-and-verify-knowledge-panel-when-it-appears) receives the accepted route after scope approval.

This task supports the [Content Factory: Produce, Process, Post and Promote](https://blitzmetrics.com/content-factory/). Identity, proof, access or coordination can support several stages. Use the real inputs and receiving owner above; this task does not create unrelated transcripts, clips or ads merely because the diagram has four stages.

## Start with an agent

Give the [AI worker](https://blitzmetrics.com/build-agents/) this recipe, the real inputs, desired result and actions already authorized. Ask for the saved output, sources, checks and next owner. A [skill is a written recipe](https://localservicespotlight.com/plugin/); loading one does not prove account access or perform the task. Use the [installation guide](https://localservicespotlight.com/install/) if reusable setup is needed. A ZIP is a source snapshot, not an access grant or automatic update.

Use the app’s actual supported tools and verified file/account access. Keep a missing human verification step with its real owner. Recurring work needs its own configured job, trigger, timezone and observed result; this guide creates no schedule. Before any media playback, mute the player and set its volume to zero. If silence cannot be verified first, use captions, frames, metadata or another silent check.

## Record the real execution

Open the run record when work begins. Keep one execution ID, starting recipe revision, real inputs and current state. Write the [meta article, the record of this execution](https://blitzmetrics.com/meta-article-prompt/) with actual steps, results, checks, failures and next owner. Writing is required; public release follows existing authority. Link it to this recipe and the [Task Library](https://local-service-spotlight.github.io/task-library/).

Reuse the same execution ID for internal checks, revisions, retries and meta writing. A blocked run stays open with its dependency and owner, without an invented finish time. Dated public examples and distinct verified execution counts remain separate. Propose the smallest source-backed recipe improvement when the actual evidence reveals a defect.


<!-- factory-layer:start -->

## Factory chain (do not treat this as isolated)

- **Phase:** —
- **Importance:** 3/5 `●●●○○` — frequency 3, revenue 3, gating 3 (supporting)
- **Suggested previous station:** —
- **Suggested next station:** —
These stations are generated neighbors, not verified prerequisites or handoffs. Follow the task’s actual Inputs and Handoff sections.
- **Handoff:** Save this task’s actual output, source, date and checks where the receiving owner can read them. Follow the Inputs and Handoff sections for its next step.

## Model routing (same factory, any engine)

- **This task's lane:** `judgment` — Frontier judgment: honest scoring, entity disambiguation, the subject's voice. Claude, ChatGPT, or Grok — pick the one you have.
- **Single-engine path:** Use the capable AI app you already have. Check its required tools and access before starting. Pass the actual result and proof to the next task.
- **Optional multi-engine:** A tested local model may draft; a stronger model may review facts and voice. Use supported tools for approved actions. Pick models from observed quality and cost; a model name does not prove it can run this task.
- **Never** store the working state in one vendor's memory. Files in the Content Library are the bridge.

<!-- factory-layer:end -->
## Definitive article & links

- [Maintained source guide](https://blitzmetrics.com/knowledge-panel/)
- [This task in the Task Library](https://local-service-spotlight.github.io/task-library/?task=classify-and-offer-knowledge-panel#task-classify-and-offer-knowledge-panel)
- [Article Guidelines](https://localservicespotlight.com/article-guidelines/)
- [Definitive article and task recipe standard](https://blitzmetrics.com/definitive-article-guide/)
- [How recipes and run records fit together](https://localservicespotlight.com/meta-articles/)

### Primary method references

- [Google panel explanation](https://support.google.com/knowledgepanel/answer/9163198?hl=en)

## Review and evidence still needed

The inherited contributor status is `needs-work`. It is preserved, not promoted by this rewrite. That label alone does not prove document readiness, account access, an actual execution or a client result.

The fictional example teaches the method and does not fill a real-run evidence gap. A named semantic reviewer must check the actual opening, full method, sources and handoff. Check the useful opening visual in the normal rendered guide at the current required desktop and mobile sizes, including 1280 × 800 and 390 × 844. Source readability checks do not prove public presentation or task execution.