---
name: content-strategy-90-greatest-hits-10-new
description: "Get more from content that has worked well."
category: Strategy & Measurement
stage: —
definitive_article: /9-triangles-framework-scalable-home-service-businesses/
status: complete
---

# Content Strategy (90% Greatest Hits, 10% New)

Get more from content that has worked well. This guide helps your team plan mostly proven content, with some room for new tests. Start with a list of past work and its results.

**The path:** Content + results → Greatest hits → 90/10 plan → Review

**Start when:** A content or promotion plan needs a split between proven work and new experiments.

## Inputs

- The content inventory with current rights, URLs, dates and evidence for its results.
- The planned period, effort capacity, approved budget and business goals.
- [Topic Wheel, the map of your offer, topics and real stories](https://blitzmetrics.com/topic-wheel/) and the previous plan or review.

## Steps

1. Use the source’s 90/10 principle as a planning target for effort: about 90% on proven greatest hits and 10% on new tests. Name the unit being allocated, such as hours, assets or approved spend; do not blend these into one misleading percentage.
2. Group comparable assets by their job and judge them against that job. Reach or watch time may support an awareness asset; qualified leads support a lead goal. Mark old or missing evidence for recheck.
3. Build the greatest-hits pool with each item’s proof and current fit. Confirm its claim, offer, rights and destination are still usable; past success does not guarantee future success.
4. Allocate reuse actions: refresh the existing canonical page, recut a clip, or prepare paid distribution under [Dollar a Day, small paid tests of proven content](https://blitzmetrics.com/dollar-a-day/). Connect reused assets to their parent on the [SEO Tree, the map of related pages](https://blitzmetrics.com/seo-tree/) rather than creating competing thin pages.
5. Choose a small experiment list from real questions and gaps. For each test name the hypothesis, variable, limit, review window and success rule before results arrive. Publication and spend stay within their separate authority.
6. Prepare the calendar with owner, source, output and review date for each item. Compare planned effort and any authorized spend to the intended split; record a justified exception rather than fabricating a 90/10 match.
7. At review, compare actual allocation and results. Promote a new item into the greatest-hits pool only when its relevant evidence meets the agreed test; a generic median from unlike assets is not a valid gate.

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

- [ ] The hit pool has current supporting evidence and usable source assets.
- [ ] The plan states its allocation unit and shows the intended split or a clear exception.
- [ ] Every experiment and reuse action has a scope, owner and review rule.

## Example(s)

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

A fictional shop has ten content hours this week. It plans nine hours to update and recut two proven service stories, and one hour for a new customer question. Paid spend has no new approval, so the plan contains no live boosts. At review, hours and results are recorded separately.

## Handoff and Content Factory context

[Plan the next recording session](https://local-service-spotlight.github.io/task-library/?task=use-for-content-planning-and-video-topics#task-use-for-content-planning-and-video-topics) receives the recording needs; Process or Post receives exact reuse briefs. [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) receives the later allocation and performance review.

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://blitzmetrics.com/9-triangles-framework-scalable-home-service-businesses/)
- [This task in the Task Library](https://local-service-spotlight.github.io/task-library/?task=content-strategy-90-greatest-hits-10-new#task-content-strategy-90-greatest-hits-10-new)
- [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 `complete`. 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.