---
name: submit-weekly-maa-report-every-friday
description: "Show a business owner what changed and what the team should do next."
category: Strategy & Measurement
stage: —
definitive_article: https://blitzmetrics.com/how-to-write-weekly-maa-reports-for-local-service-businesses/
status: needs-work
---

# Submit weekly MAA report every Friday

Show a business owner what changed and what the team should do next. This guide turns the week’s proof into a short report. Start with the same source numbers and the last action list.

**The path:** Verified numbers → Meaning → Owned next actions → Checked delivery

**Start when:** The client’s agreed weekly reporting deadline is due; use Friday only when that is the accepted cadence.

## Inputs

- [Collect verified weekly measurements](https://local-service-spotlight.github.io/task-library/?task=collect-verified-weekly-measurements#task-collect-verified-weekly-measurements) report and the client’s accepted metric definitions, source contract and period.
- Last report, evidence of actual actions, current business context and named project lead.
- The agreed reporting day, channel, recipients and sending authority; [the weekly MAA article](https://blitzmetrics.com/how-to-write-weekly-maa-reports-for-local-service-businesses/).

## Steps

1. Read the previous action list and mark actual results. Confirm the current reporting window, timezone, definitions and any approved changes before comparing numbers.
2. Open with the most useful supported finding, why it matters to this client’s goal and the decision or action it enables. Use two or three grade-five sentences beside a relevant chart or evidence diagram; do not begin with a generic explanation of marketing. Apply the meaning review in [Write the hook and establish context](https://local-service-spotlight.github.io/task-library/?task=step-7-write-hook-and-establish-context#task-step-7-write-hook-and-establish-context) and retain the exact opening text and quoted reviewer evidence in the report receipt.
3. Lead with qualified calls and leads for a local-service engagement when that is its accepted goal. Keep total calls, qualified calls, booked jobs and revenue separate. Call duration can screen a queue but does not establish qualification.
4. Show source breakdowns, actual ad spend and cost per defined result, followed by relevant search and website measures. Keep missing sources and attribution limits visible; do not report an unread source as zero.
5. Explain what is working, what misses its target and what cannot yet be judged. Use [Show what works and what needs review](https://local-service-spotlight.github.io/task-library/?task=show-whats-working-and-what-isnt#task-show-whats-working-and-what-isnt) and [Diagnose weak results](https://local-service-spotlight.github.io/task-library/?task=analyze-why-underperformers-fail#task-analyze-why-underperformers-fail) for supporting detail. Analysis connects facts to a supported reason or testable question rather than merely restating the table.
6. Write a short priority list of concrete next actions with owner, due date and pass rule. Distinguish changes already verified from proposals and blocked actions. Do not fill a three-action template with invented work.
7. Check the report’s math, links, dates, privacy and clear grade-five opening. Use the accepted voice and current [Article Guidelines](https://localservicespotlight.com/article-guidelines/) for any public form.
8. Save and deliver in the exact agreed channel only when sending is authorized. Verify the sent or posted copy and retain its location. A saved draft is still a draft; if delivery is blocked, name that dependency and next owner.
9. Carry the report and next actions into the Success Tracker and next cycle. Keep the actual scheduler configuration separate from this Friday-named recipe.

## 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 report uses agreed definitions and comparable sourced numbers, with qualification distinct from volume.
- [ ] Analysis and concrete next actions follow the evidence; unknowns remain visible.
- [ ] Saved and delivered states are verified separately in the correct destination, or the delivery blocker is explicit.

## Example(s)

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

A fictional report shows 30 total calls, 12 qualified calls and five bookings under the client’s definitions. It proposes checking six missed calls next. The draft is ready Thursday, but the agreed delivery is Friday in the client’s existing channel. The record stays draft until the authorized send is read back.

## Handoff and Content Factory context

[Update the Success Tracker](https://local-service-spotlight.github.io/task-library/?task=update-client-success-tracker#task-update-client-success-tracker) receives the report and evidence; the next agreed review checks its action list.

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:** 4/5 `●●●●○` — frequency 4, revenue 4, gating 2 (runs every factory cycle or weekly; creates the asset ads amplify)
- **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/how-to-write-weekly-maa-reports-for-local-service-businesses/)
- [This task in the Task Library](https://local-service-spotlight.github.io/task-library/?task=submit-weekly-maa-report-every-friday#task-submit-weekly-maa-report-every-friday)
- [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.