---
name: update-client-success-tracker
description: "Keep the client’s work and results easy to find."
category: Strategy & Measurement
stage: —
definitive_article: https://localservicespotlight.com/the-success-tracker-how-ai-apprentices-managing-local-service-clients-stay-organized-and-prove-results/
status: needs-work
---

# Update a client Success Tracker

Keep the client’s work and results easy to find. This guide helps your team show what changed and who owns the next step. Start with the latest report and proof of what was done.

**The path:** Run evidence → Current tracker → Owned actions → Client review

**Start when:** A client’s current work and weekly evidence need to be prepared for its next review.

## Inputs

- [Write the agreed weekly report](https://local-service-spotlight.github.io/task-library/?task=submit-weekly-maa-report-every-friday#task-submit-weekly-maa-report-every-friday) and [Collect verified weekly measurements](https://local-service-spotlight.github.io/task-library/?task=collect-verified-weekly-measurements#task-collect-verified-weekly-measurements) outputs for the agreed period.
- The existing client Success Tracker or linked template, dated work artifacts, decisions, blockers and next actions.
- [The Success Tracker method](https://localservicespotlight.com/the-success-tracker-how-ai-apprentices-managing-local-service-clients-stay-organized-and-prove-results/) and verified destination/owner/access.

## Steps

1. Find the existing relationship tracker before creating a new copy. Read the current project overview and responsible lead so the record goes to the right people and does not fork an active source.
2. Gather the period’s dated artifacts and report. For each item distinguish planned, drafted, saved, published, delivered and verified states; link the evidence that supports the chosen label.
3. Update only relevant current sections of the actual template: strategic context, plumbing, goals, content, targeting and results as applicable. Preserve prior reports as dated history, and mark a missing source rather than leaving a misleading empty slide.
4. Add sourced metrics with definitions, period and comparison. Keep audience, engagement and business conversion outcomes distinct, including qualified leads, bookings and collected revenue.
5. Explain material changes and blockers in plain language. For each next action name one actual owner, due date or trigger, source need and acceptance condition. Resolve ownership from the authoritative project record instead of inventing a contact.
6. Preserve authority boundaries: the Client Roster owns relationship status; Client Tracker owns money/routing; verified project records own work destinations; measurement sources own metric truth. This tracker is the discussion and evidence view, not a competing control system.
7. Review dates, links, current screenshots, access and privacy. Save and reopen the exact tracker, then use it in the authorized team/client review. Record pending delivery or meeting as pending; merely updating the document does not prove the review happened.

## Definition of done (QA checklist)

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

- [ ] Every completed item has dated proof and each number has source and period.
- [ ] Every next action has a real owner and check condition; missing access remains visible.
- [ ] The saved tracker is understandable and preserves history and the authoritative systems.

## Example(s)

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

A fictional tracker shows a page saved in the CMS, but its public copy is still old. The row says saved, public check blocked and names the publishing owner. The weekly report link is retained. No client-facing “live” claim or completed review is added until the evidence changes.

## Handoff and Content Factory context

The verified project lead uses the record at the next agreed review; [Write the agreed weekly report](https://local-service-spotlight.github.io/task-library/?task=submit-weekly-maa-report-every-friday#task-submit-weekly-maa-report-every-friday) reads the same history in the next cycle.

This work supports the [Content Factory: Produce, Process, Post and Promote](https://blitzmetrics.com/content-factory/) across its relevant stages. It uses the actual inputs and next owner above; a strategy or measurement guide does not manufacture transcripts, clips or other unrelated stage outputs.

## Start with an agent

Give the AI worker this recipe, the real Inputs, the desired result and the actions already authorized. Ask for the saved output, source evidence, passed and failed checks, and the next owner. A skill is a set of instructions. Loading it does not prove access, install a scheduled job or complete the work. Use the [current installation guide](https://localservicespotlight.com/install/) only if reusable setup is needed; a ZIP contains instructions and is not an access grant.

Use the actual supported app and verified source access. A model name is not a promise of browser control, memory or unattended work. For recurring work, inspect the real job’s trigger, owner, timezone and observed firing; this recipe creates no schedule. Before any media playback, mute the player and set volume to zero. A silent review does not prove sound was heard.

## Record the real execution

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

Reuse the same execution ID for internal reviews, meta writing, revisions and retries. A blocked run stays open with its dependency and owner, without an invented finish time. Keep historical public examples as dated evidence; article counts alone are not verified execution frequency. Use supported findings to propose and verify a recipe improvement.


<!-- 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://localservicespotlight.com/the-success-tracker-how-ai-apprentices-managing-local-service-clients-stay-organized-and-prove-results/)
- [This task in the Task Library](https://local-service-spotlight.github.io/task-library/?task=update-client-success-tracker#task-update-client-success-tracker)
- [Article Guidelines](https://localservicespotlight.com/article-guidelines/)
- [Definitive article and task recipe standard](https://blitzmetrics.com/definitive-article-guide/)
- [How recipes and run records work together](https://localservicespotlight.com/meta-articles/)

## 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 verify document readiness, account access, an actual execution or a client outcome.

A relevant real execution, source evidence, independent reviewer and accepted handoff remain to be recorded. The fictional example teaches the method and does not fill a real-run evidence gap. The opening and full method need a named semantic reviewer; the task-specific path is source guidance, with visible desktop/mobile presentation still to check.