---
name: keep-speaker-bureau-profile-bookable
description: "Give event hosts the facts they need to book your talk."
category: Personal Branding
stage: —
definitive_article: /speaker-kit
status: complete
---

# Keep speaker bureau profile bookable

Give event hosts the facts they need to book your talk. This guide keeps your speaker page and booking profile in line with one approved kit. Start with your current talks, fees and real proof.

**The path:** Approved kit → Exact profile fields → Real proof → Checked booking path

**Start when:** The speaker’s public booking surfaces are missing facts or differ from the current approved speaker kit.

## Inputs

- The speaker’s current approved kit with source revision, bio, talks, public fees, permissions and contact route.
- Actual bureau/profile access and the personal-site speaking page, plus their release owners.
- Real headshot, stage photos, talk video, attributed testimonials and confirmed public event dates.

## Steps

1. Read the kit and current public pages before touching fields. Compare dated source revisions and flag conflicting current facts to the kit owner. The maintained approved kit governs this pass; do not replace a newer authorized change with an older source merely because it is in git.
2. Confirm the person’s current positioning, operating company and approved public contact details. Preserve former companies as accurate history where relevant. Never publish a private street address, personal phone or unpublished fee just to fill a directory field.
3. Use exactly the fee policy the speaker has approved for public use. Enter actual U.S., international, virtual and travel terms where applicable; if fees are not approved for publication, keep the decision with the owner. Do not claim a universal bureau ranking penalty for an inquiry-only price.
4. Load each approved talk with its title, format, intended audience and useful takeaways. Write clear grade-five context explaining the audience’s benefit, backed by the real program. Use first person on the personal site and the bureau’s required voice in its profile.
5. Add real relevant proof: a headshot, stage image or talk video and attributed testimonials with supported event context. Check media and rights silently. Link the actual speaking page and its inquiry path, not a homepage that hides the booking details.
6. Enter only confirmed, permitted public calendar events. Private holds and tentative invitations remain internal or explicitly tentative where appropriate. The source’s earlier three-date target never permits invented future appearances or a claim that an empty calendar means inactivity.
7. After authorized updates, compare the public bureau URL and speaking page with the approved kit. Check the first-screen value, program, proof, fees policy and contact destination. A form submission test may send a message, so use the existing test authority and verify its destination.
8. Save the changed fields, exact public URLs, kit revision and pending owner actions. Review when programs, fees or events change. Future speaking footage goes to the content owner after the event actually occurs.

## 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/).

- [ ] Both public surfaces match the current approved kit on identity, programs, public fee policy and contact route.
- [ ] All proof and event claims are real, permissioned and correctly scoped.
- [ ] The normal public pages and booking path are checked, with pending or untested steps explicit.
- [ ] 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 speaker has two approved talks and one confirmed public event. The bureau offers room for three dates, but the team enters only the real event. A private hold remains in the kit. The public page now shows clear audience takeaways and the working booking route without inventing a fuller calendar.

### Dated source evidence

The maintained speaker-kit article links its documentation meta article and Dennis Yu’s kit as dated method evidence. They are not a new booking or independently counted execution by this guide author.

## Handoff and Content Factory context

[Prepare relevant speaking pitches](https://local-service-spotlight.github.io/task-library/?task=secure-guest-appearances-and-speaking-engagements#task-secure-guest-appearances-and-speaking-engagements) receives the checked kit; [Capture the delivered talk](https://local-service-spotlight.github.io/task-library/?task=film-conference-presentations#task-film-conference-presentations) receives only actual booked-event needs.

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 2 (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:** `any` — Any capable chat model (Claude, ChatGPT, Grok, Gemini). SOP following, drafts, checklists.
- **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/speaker-kit/)
- [This task in the Task Library](https://local-service-spotlight.github.io/task-library/?task=keep-speaker-bureau-profile-bookable#task-keep-speaker-bureau-profile-bookable)
- [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/)

## Review and evidence still needed

The inherited contributor status is `complete`. 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.