Before you start:

• The connector reads one account at a time. The Klaviyo MCP reads whatever account it’s currently connected to. For portfolio work you connect the client you’re working on, run their prompts, then reconnect to the next client, Claude assembles the per-client reads. The same rule governs scheduling: a scheduled prompt reads whatever account is connected when it fires, so keep the connection matched to the client whose reports are running (see the scheduling section below).
• Adjust everything bracketed, and keep each prompt’s “Format the result like this” block, it’s what gives you copy-pasteable output for a client doc or Slack instead of conversational prose.
• Read before approving any write. The diagnostic prompts are read-only. The few that suppress or subscribe (clearly marked) show the plan first. On client accounts especially, read it.
• Ask for a chart. Several prompts end with a chart request, Claude renders the data as an HTML chart you can screenshot straight into a client report. Any data prompt works this way: after the result, add “now build that as an HTML chart for the client deck.”
• Each client’s own numbers are the benchmark. A 28% open rate is healthy for one client and an alarm for another. Several prompts here establish each account’s own normal first, then measure against it, which is also exactly the framing that makes your reporting credible to a client.
• Put the recurring ones on a schedule. The monitoring prompts are built to run on a cadence, and Claude Cowork (desktop) can run them automatically across your accounts. Where a prompt is worth scheduling, a suggested cadence appears right after it. Full setup walkthrough, including how to handle a multi-client portfolio, is in “Scheduling these in Claude Cowork” just below.

Scheduling these in Claude Cowork

The diagnostics and monitors earn their keep when they run on a cadence, a client’s weekly snapshot ready when you sit down, a monthly report prepped the day before the check-in. Claude Cowork (the desktop app) does this. You set a prompt up once, pick how often it runs, and Cowork runs it on a cadence using your connected Klaviyo account, saving the output each time. Setup is about two minutes per task. One thing to get right up front, covered in detail below: a scheduled run reads whichever Klaviyo account is connected when it fires, so for a portfolio you keep the connection matched to the client whose reports are running.

Two ways to set one up.

The quick way, from a chat: open Cowork, start a new task, paste the prompt you want to recur, then type /schedule and send. Claude asks a few multiple-choice questions, how often, what time, where to save, then confirms with the task name, its cadence, and what it does.

The precise way, from the sidebar: click Scheduled in the left sidebar, then New task, and enter the prompt, frequency, and working folder directly in the form. This is the better route here, the prompts in this book are already well-defined, so you’re just pasting a finished one and setting a cadence.

What to put in the scheduling instruction. A good recurring prompt tells Claude what to pull, what you want back, and where to put it. The prompts here cover the first two; add the third when you schedule, e.g. “save the result as a dated file, deliverability-pulse-{client}-{date}.md.” That dated trail per client is half the value when you’re reporting month over month.

Handling a multi-client portfolio. This is the one thing that’s different for agencies, and it’s worth being precise about. The Klaviyo connector points at one account at a time, whichever one it’s currently connected to. It can’t switch clients mid-run, and a scheduled task can’t reliably pick a client for you unattended. So the rule is simple: before a scheduled run fires, make sure the connector is connected to that client’s Klaviyo account. The schedule controls when a prompt runs; the active connection controls which client it reads. Keep those two in sync and there’s no ambiguity.

In practice that means scheduling is a per-client setup, not a one-and-done across the whole book:

• One client connected, one set of tasks. Connect the Klaviyo account for the client you’re working on, set up their scheduled prompts (their weekly snapshot, monthly report, etc.), saving to that client’s folder. Those tasks read whatever account is connected when they fire, so they’re reliable as long as that client stays the connected account.
• Switching clients means reconnecting. When you move to another client, reconnect the connector to their account. Tasks scheduled for the previous client will then read the newly-connected account, which is usually not what you want, so the clean pattern is to run each client’s scheduled reports while that client is the connected account, rather than expecting a dozen clients’ tasks to all fire correctly overnight.
• The realistic cadence. Treat scheduling as “kick off this client’s reports while I’m in their account” rather than full unattended portfolio automation. Many agencies dedicate a recurring block (e.g. a Monday morning per-client pass) where they connect each account in turn and let its scheduled prompts run, saving outputs to per-client folders. You then review each client’s saved outputs on whatever cadence suits the account.

The honest state of things: scheduling per-client through Cowork is reliable when you keep the connection matched to the client, which works well when you’re running a handful of accounts. Across a larger book, the constant reconnecting becomes the bottleneck, and fully hands-off automation across many Klaviyo accounts at once isn’t something Cowork does reliably on its own. If that’s you, several merchants, all needing scheduled reporting, the next section covers a setup that removes the connection-switching problem entirely.

A few things worth knowing.

• After the first run, Claude tidies your prompt into standing instructions based on what it learned, so later runs are sharper.
• Every scheduled task lives in the Scheduled tab, view upcoming and past runs, open any result, edit the prompt or cadence, pause, or delete.
• Claude Desktop notifies you when a run finishes.
• Scheduled tasks only run while your computer is awake and Claude Desktop is open. If the machine’s asleep at the scheduled time, Cowork runs the task next time you open the app. For a full book of clients, a machine that stays awake during your scheduled window (some agencies dedicate a spare Mac to this) keeps everything firing on time.

Where a prompt below is worth automating, you’ll see a Schedule it line with a suggested cadence. The rest are one-time client actions, run those by hand.

Scheduling across many accounts: a dedicated agent per merchant

The section above works well for a handful of clients. But there’s a real wall when you scale it: the Klaviyo connector authenticates to one account at a time, so running a book of merchants through a single Cowork connection means constantly reauthorizing and hoping the right account is connected when a scheduled task fires. Reauthorize, switch, run, repeat, for ten clients on a weekly cadence, that’s not automation, it’s a chore you’ve scheduled.

The fix is to stop sharing one connection and give each client its own dedicated agent that stays permanently connected to that client’s account. We do this with Tasklet.ai, a cloud agent platform (from the team behind Shortwave) that connects to MCP servers, including Klaviyo’s, and runs tasks on a schedule in the cloud, 24/7, without your machine being on. Because each agent holds its own connection, the switching-and-reauthorizing problem disappears entirely.

Setting it up:

1. Create a Tasklet account and, in your dashboard, add the Klaviyo MCP server as a connection (Tasklet supports custom MCP servers alongside its prebuilt integrations). You’ll authorize Klaviyo the same way you do in Claude, the difference is where the connection lives.

2. Create one agent per merchant account. For each client, set up a separate agent and connect it to that client’s Klaviyo account, with its own authorization. Name them unambiguously, “Northbay, Deliverability”, so a dozen agents stay readable. This is the step that solves the core problem: each agent is permanently pointed at one account, so nothing has to be switched or re-authed at run time.

3. Give each agent its prompts, in plain English. Tasklet takes natural-language instructions, so the prompts in this guide go straight in. Paste a prompt and tell the agent when to run it: “Every Monday at 7am, run this deliverability snapshot on the connected Klaviyo account and save the report as northbay-pulse-[date].” Add as many of this guide’s prompts as you want on that client, the weekly snapshot, the monthly report, the anomaly scan, each on its own cadence.

4. Set the schedule and let it run. Tasklet’s triggers run daily, weekly, or on any custom schedule, executing in the cloud. Reports land on time whether or not your computer is on, each client’s agent producing that client’s reports in parallel. Review the first few runs of each agent before you trust it unattended, then leave it.

5. Compile when you need the portfolio view. The per-agent runs produce each client’s reports on schedule, every account’s data generated and saved without you switching connections and waiting.

When it’s worth it. Tasklet is a paid service, so the honest line is: if you’re running scheduling for one or a few accounts, Cowork does the job for free and you don’t need this. The moment you’re managing several merchants and want them all reported on automatically, the math flips fast, the hours you’d otherwise lose to reauthorizing, account-switching, and manually running reports across a portfolio dwarf the subscription, and you get scheduling that actually fires on time instead of scheduling you have to sit and supervise. As with any agent you grant account access, connect each one with least-privilege permissions where Klaviyo allows it, and review early runs before relying on them.

Turning a prompt into a client-ready asset

The chart and dashboard prompts (and any data prompt you follow with a chart request) render as HTML. Ask Claude to save the result and you get an .html file, a clean, self-contained visual you can open in any browser. That file is the shareable asset: drop it in the client’s Drive folder, attach it to the recap email, or open it on screen and screenshot it into your review deck. Generated in seconds from their real data, it replaces the half-hour you’d otherwise spend rebuilding numbers in a slide tool, and it makes the work visible, which is what keeps a retainer.

A practical instruction to add to any dashboard or chart prompt: “save this as a self-contained HTML file named [client]-deliverability-[date].html, with all styling inline so it opens correctly on its own.” Inline styling matters, it means the file works when emailed or moved, with no broken dependencies.

If you want a link instead of a file, some agencies prefer sending a URL, you can host the HTML with a CLI static host (Surge, Netlify, and similar deploy a file to a public URL in one command). Treat this as an optional, set-it-up-yourself path, not a default, and mind one thing: these services publish to public, unauthenticated URLs. A client’s deliverability data, complaint rates, suppression counts, revenue, any sample addresses, should not sit on a page anyone with the link can open. If you host, scrub identifying data first, use a host that supports password protection or access control, or stick with the saved file and share it through a channel you control. For client data, the file is the safer default.

00SEGMENT SETUP, DO THIS FIRST

Several prompts below depend on segments existing in the Klaviyo account. Build these once per account before running any prompt that requires them. Name them exactly as shown so the prompts can find them.

The segment names above are what the prompts look for. If existing segments match these definitions but use different names, either rename them or update the prompts when you run them.

01Triage the portfolio

You have N clients. Which one is on fire, which one is smoldering, and which one can wait.

01Per-client health snapshot

Run this on each client. Run it on each client account as your regular per-client read.

Use the Klaviyo MCP to do the following. Pull a deliverability health snapshot for the currently active Klaviyo brand, covering the last 30 days. Show blended open rate, engaged share (last 90 days), complaint rate, bounce rate, and unsubscribe rate. Give it a status of GREEN, AMBER, or RED and a one-line read.

DMARC, SPF, DKIM, and the branded sending domain require a DNS lookup, which the connector can't do, flag those as "check externally" in the output rather than omitting them.

Format the result exactly like this:

```
{brand} · deliverability snapshot · last 30d

→ blended open: [%]
→ engaged share (90d): [%]
→ complaint rate: [%]
→ bounce rate: [%]
→ unsub rate: [%]
→ branded sending domain / SPF / DKIM / DMARC: check externally

status: [GREEN / AMBER / RED]
one-line read: [the headline]
```

Output only the format above, no preamble.

OPERATOR NOTE

Standardize the status thresholds across your portfolio so “RED” means the same thing on every account, e.g. RED if complaint rate >0.1% OR engaged share <45%, AMBER on either trending the wrong way, GREEN otherwise. Consistency is what lets you triage a dozen clients in one sitting instead of re-deciding the criteria each time. Save this prompt as a snippet; you’ll run it constantly.

Schedule it: in Cowork, paste this prompt and /schedule it to run weekly, per client. This is the input to your monitoring, schedule it per account to produce a regular per-client snapshot.

02Set each client's baseline

A new client’s “normal” isn’t your other clients’ normal. Establish it before you judge anything.

Use the Klaviyo MCP to do the following. Establish this client's deliverability baseline from the last 6 months, but compute it the way the account actually sends, not as a blended average. Most accounts vary rates dramatically by audience type (engaged-segment sends run far higher than wider lists), so a single median across all campaigns hides the truth.

Pull the last 6 months of email campaigns. For each one, the connector returns the audiences (lists or segments) it was sent to. Use those audience names to classify each campaign into one of two tiers:
• Engaged-segment sends, campaigns sent to recency/engagement segments (names usually contain "Engaged," "L15/L30/L60/L90," "Active," "VIP + Engaged," "RFM Loyal/Champions," or similar)
• Broad sends, campaigns sent to wider lists, lapsed cohorts, all-subscriber lists, or paid-media intake lists (names usually contain "All Subscribers," "L180/L365/L500/L720," "Newsletter," "Pop-Up," "Lapsed," or are domain-segmented like "All_Gmail_Domains")

If the account uses unfamiliar naming or you can't cleanly classify a campaign, group it under "mixed" rather than guessing. If MOST campaigns end up in "mixed" because the account doesn't use named engagement segments, flag that as a finding, it usually means the account doesn't have a clean engagement-segmentation strategy in place yet, which is itself a deliverability issue worth noting.

For each tier show the median and the normal band (the range it sits in most weeks) for open rate, click rate, bounce rate, spam complaint rate, and unsubscribe rate.

Format the result exactly like this:

```
{brand} · deliverability baseline · trailing 6 months

ENGAGED-SEGMENT SENDS ([N] campaigns):
→ open:    median [%] · band [%–%]
→ click:   median [%] · band [%–%]
→ bounce:  median [%] · band [%–%]
→ spam:    median [%] · band [%–%]
→ unsub:   median [%] · band [%–%]

BROAD SENDS ([N] campaigns):
→ open:    median [%] · band [%–%]
→ click:   median [%] · band [%–%]
→ bounce:  median [%] · band [%–%]
→ spam:    median [%] · band [%–%]
→ unsub:   median [%] · band [%–%]

MIXED / UNCLASSIFIED ([N] campaigns): [if >30% of campaigns landed here, flag the segmentation gap]

what "abnormal" means for this client: [one line per tier, the number that should trigger a closer look, measured against THIS account's range, not a generic benchmark]
```

Output only the format above, no preamble. This is the reference card every downstream prompt compares against.

OPERATOR NOTE

The fastest way to look like you don’t know an account is to apply another client’s normal to it. One client’s list may run 38% open and another 24%, both perfectly healthy for their audience and acquisition mix. Run this at onboarding, save a baseline card per client, and every “is this bad?” question afterward answers itself against the right reference. It’s also the cleanest way to set client expectations early: “here’s your normal, here’s the line where we act” beats any industry benchmark slide.

Schedule it: in Cowork, paste this prompt and /schedule it to run quarterly, per client, plus once at onboarding. Refresh each baseline as the account matures.

03Client engagement-cohort breakdown

The “you’re mailing too many dead subscribers” finding, per client, with the money attached.

Use the Klaviyo MCP to do the following. Read this client's engagement breakdown, how much of the list is active, cooling, cold, or dead by recent engagement. This requires the four recency segments (Active, Cooling, Cold, Dead) to exist in the account. Read the profile count of each, then build the breakdown.

If any of the four segments isn't there, stop and tell me which are missing rather than estimating from samples, the breakdown is meaningless if the cohorts aren't real.

Format the result exactly like this:

```
{brand} · engagement breakdown
signal: [machine-filtered opens / clicks, based on how the segments are defined]

→ active (0-30d):   [count] · [% of list]
→ cooling (30-90d): [count] · [% of list]
→ cold (90-180d):   [count] · [% of list]
→ dead (180d+):     [count] · [% of list]

what suppressing the dead cohort would do: [the effect, one line]
client-ready line: [one sentence for a report]
```

Output only the format above, no preamble.

Once the numbers are real, render them as a clean HTML bar chart, color-coded by engagement health, ready for the client's report.

OPERATOR NOTE

The “client-ready line” field is the trick that makes this an agency prompt instead of a brand one. The cohort table is for you; the one-sentence translation is for the client, who doesn’t care about engagement density but very much cares that “the people who buy aren’t getting your emails because of the people who don’t.” Lead client conversations with the translated line and keep the table as backup.

04Infrastructure check across clients

The unglamorous audit that catches the silent caps, done as a portfolio sweep.

Use the Klaviyo MCP to do the following. Run an infrastructure check on the currently active Klaviyo brand using what the connector actually exposes. The branded sending domain, SPF, DKIM, DMARC policy, and dedicated-vs-shared IP all require DNS lookups or sender-account inspection that the connector can't perform, flag those as items to verify externally rather than skipping them.

What you CAN read from the connector: the account's email-sending volume and patterns, recent bounce/complaint trends as indirect indicators of infrastructure health, and any deliverability flags surfaced in account details. Pull those and use them to anchor the report.

Format the result exactly like this:

```
{brand} · sending infrastructure

CONNECTOR-READABLE INDICATORS:
→ account status / deliverability flags: [from get_account_details]
→ recent bounce trend: [last 30d vs prior 30d]
→ recent complaint trend: [last 30d vs prior 30d]

VERIFY EXTERNALLY (DNS / Klaviyo settings):
→ branded sending domain, Klaviyo Settings → Domains
→ SPF, DNS TXT lookup for the sending domain
→ DKIM, DNS lookup; Klaviyo shows status in domain settings
→ DMARC policy, DNS TXT lookup for _dmarc.[domain]
→ dedicated vs shared IP, Klaviyo Account → Email Deliverability

priority fix: [the one item from connector indicators most likely capping deliverability, or "no connector-visible issues, focus on external verification"]
```

Output only the format above, no preamble.

OPERATOR NOTE

Infrastructure gaps are the easiest thing to standardize across a portfolio because the fix is identical on every account: branded sending domain, DMARC to quarantine then reject. Build a one-row-per-client matrix from these outputs and you’ve got both a work queue and a tidy “here’s what we standardized across your accounts” line for your own marketing. Clients rarely know their DMARC posture; finding it for them is cheap credibility.

05Placement read for a client

Open rate says they engaged. Placement says the email reached them at all. Clients confuse the two.

Use the Klaviyo MCP to do the following. Infer this client's likely inbox placement, Primary vs Promotions vs Spam, from their engagement data. Compare open rate by mailbox provider against this client's own baseline, flag any provider where the gap suggests Promotions or Spam placement, and note what a seed-list test would confirm. Include one plain-language sentence I can say to the client.

Format the result exactly like this:

```
{brand} · placement read · last 60 days

PROVIDER SIGNALS (vs their baseline open of [%]):
→ [provider]: [open %] · [in-band / below, likely placement issue]
  ...per provider

INFERENCE:
→ likely inboxing: [providers]
→ likely Promotions/Spam: [providers + why]

client explanation: [one plain-language sentence]
confirm with: [seed test setup, one line]
```

Output only the format above, no preamble.

OPERATOR NOTE

“Delivered” and “inboxed” are different things, and the gap is where clients lose trust in email without understanding why. The connector reads engagement, not the folder, so this infers placement from the open-rate gap against the client’s own baseline, which is a strong directional signal and a great client-conversation tool, but not proof. When a client needs certainty (or you’re diagnosing a serious drop), set up a seed-list test. Being the one who can explain why their “fine” open rate actually signals a Gmail placement problem is exactly the expertise they’re paying for.

06Catch a client over-mailing

Often the client controls the send calendar. Show them the cost of cramming it.

Use the Klaviyo MCP to do the following. Check whether this client is over-mailing, but measure it the way it actually shows up, which is rarely "more sends per week → worse rates." On a sophisticated account, week-to-week rate swings are mostly caused by which audiences got mailed (heavy "all subscribers" weeks look like collapse but are usually just wider sends), not raw frequency.

Pull the last 90 days of email campaigns. For each campaign, the connector returns the audiences it was sent to. Use those names to classify into:
• Engaged-segment sends, audiences named with "Engaged," "L15/L30/L60/L90," "Active," "VIP + Engaged," "RFM Loyal/Champions," or similar
• Broad sends, audiences named with "L180+," "All Subscribers," "Lapsed," "Pop-Up," domain-segmented lists, or paid-media intake

If the account doesn't use named engagement segments and most campaigns end up unclassified, flag that the over-mailing question can't be cleanly answered without an engagement-segmentation strategy, and recommend the client establish one (see prompt 03 for the cohort segments to build).

For each week count: (a) engaged-segment sends, (b) broad sends, (c) total. Then look at whether broad-send weeks produce higher complaint and unsubscribe rates on those broad sends. This separates "you send too often" (a frequency problem) from "you send to too wide an audience" (an audience problem). They have different fixes.

Format the result exactly like this:

```
{brand} · send pattern vs engagement · last 90 days

WEEKLY MIX (avg):
→ engaged-segment sends/week: [N]
→ broad sends/week: [N]
→ total sends/week: [N]
→ unclassified: [N, flag if account lacks named engagement segments]

BROAD-SEND HEALTH:
→ avg complaint rate on broad sends: [%]
→ avg unsub rate on broad sends: [%]
→ trend across the 90 days: [stable / rising / falling]

ENGAGED-SEGMENT HEALTH:
→ avg complaint rate on engaged sends: [%]
→ avg unsub rate on engaged sends: [%]

read: [is this a frequency problem, an audience problem, missing segmentation, or fine? one line]
```

Output only the format above, no preamble.

OPERATOR NOTE

Send frequency is the most common point of friction with a client, because more sends feels like more revenue and the damage is invisible until placement drops. This prompt gives you the evidence in their own numbers, not “best practice says,” which clients ignore, but “your list, these weeks, this is what happened.” The “client line” reframes it productively: the answer to “we want to send more” is usually “then let’s send to a tighter, more engaged audience,” not a flat no. Each list’s ceiling is its own, which is why this measures their pattern, not a rule.

02Fix without babysitting

Repeatable recovery moves you can run on any client account the same way.

07Suppression plan, client-safe

Cleaning a client’s list is high-trust. Show the plan, the protections, and the dollar exposure first.

Use the Klaviyo MCP to do the following. Build a suppression candidate plan for this client, the dead weight that's safe to stop mailing, with the plan and protections shown first. Nothing gets changed; this is review only.

Read the count of the Suppression Candidates segment, that's the candidate base. If the segment doesn't exist, stop and tell me; don't try to compute the candidate count from event aggregates (the API gives event counts, not "profiles with zero events").

For protections, also read the counts of the Win-Back Protection segment and the VIP / High-LTV Protection segment. If either is missing, list it as "needs segment", don't fabricate the number.

Then show the account's trailing 12-month revenue as context for the suppression decision (this is reachable as a sum on Placed Order across the account). Per-profile revenue inside the candidate cohort is NOT reachable through the connector, don't claim a "revenue from this group" number.

Format the result exactly like this:

```
{brand} · SUPPRESSION PLAN (review, nothing changed yet)

candidate base (Suppression Candidates segment): [count] · [% of mailable list]
account 12-month revenue (context): [$]

PROTECTIONS (hold back from suppression):
→ Win-Back Protection: [count, or "needs segment"]
→ VIP / High-LTV Protection: [count, or "needs segment"]
→ in active flow (Win-Back, At-Risk): [count from flow recipients last 30d]

NOT COMPUTABLE FROM CONNECTOR (flag honestly):
→ lifetime revenue from candidate cohort specifically, requires profile-level iteration; the connector returns small samples only. If the client wants this number, build it via export to BigQuery or similar.

SPLIT (eligible candidates after protections):
→ 180-365d quiet → sunset flow first
→ 1yr+ quiet → direct suppress

client sign-off needed before any change. confirm to proceed?
```

Output only the format above, no preamble.

OPERATOR NOTE

On a client account, the dollar figure and the sign-off line are non-negotiable. A client who sees their list shrink by 13,600 without warning will think you broke something, even though suppressing dead weight is the single best thing you can do for their inbox placement. Frame it before you do it: “we’re going to stop mailing 7,500 people who haven’t engaged in over a year, which will raise your open rate and protect deliverability for everyone who buys.” Get the yes in writing, then proceed.

08Complaint-source trace for a client

When a client’s complaints spike, find the source before they ask why.

Use the Klaviyo MCP to do the following. Trace where this client's spam complaints are coming from in the last 90 days. The connector returns complaint events grouped by the campaign or flow that triggered them, that's the cleanest signal of which sends are generating complaints, and it works on any account regardless of segment setup. Acquisition-source-level complaint attribution requires profile-level joining the connector can't do cleanly; don't attempt that half.

Pull spam complaint events for the last 90 days grouped by campaign/flow name. Show the worst offenders. Then look at the audiences each of those sends was mailed to (the campaign report returns audience metadata) and identify whether the worst offenders share an audience pattern, broad lists, lapsed cohorts, paid-media intake, or specific engagement segments. No segment setup is required for this; you're reading audience metadata that already exists on each campaign.

Format the result exactly like this:

```
{brand} · spam complaints · last 90 days

total complaints: [count] · account complaint rate [%]

BY SEND (worst offenders):
→ [campaign/flow]: [count] complaints · [% of its recipients]
  ...ranked, cap at 8

PATTERN ACROSS WORST OFFENDERS:
→ audience type: [engaged segments / broad sends / lapsed re-engagement / mixed / unclear from naming]
→ send type: [promotional blast / flow / sunset / other]
→ what these sends share: [one line, discount-heavy, broad audience, lapsed cohort, etc.]

worst single send: [the one]
read: [one line, the fix is upstream of the send, not in the send itself]
```

Output only the format above, no preamble.

OPERATOR NOTE

Complaint spikes almost always trace back to one of two things: a badly-acquired list (contests, giveaways, purchased lists) or over-aggressive discounting to cold audiences. Being able to name the exact source turns a vague “your deliverability is bad” conversation into a specific, fixable one, which is the difference between a client trusting you and a client wondering what they’re paying for. When the root cause is acquisition, the fix lives upstream at the signup, so loop in whoever runs their forms and ads.

09Ramp a client back after a cleanup

You cleaned their list. Now rebuild reputation carefully, and don’t let the client undo it with one big blast.

Use the Klaviyo MCP to do the following. I've just cleaned this client's list. Give me a 3-week reputation ramp that starts with their most engaged subscribers and widens gradually. For each week show the audience definition and volume, and tie the go/no-go to widen to this client's own baseline signals. Include an abort condition and one line I can send the client explaining the ramp.

Format the result exactly like this:

```
{brand} · REPUTATION RAMP · 3 weeks

WEEK 1, most engaged: [audience] · [volume] · go/no-go: [signal vs their baseline]
WEEK 2, widen: [audience] · [volume] · go/no-go: [signal]
WEEK 3, normal: [audience] · [volume]

abort condition: [signal vs their baseline]
client note: [one line explaining the ramp]
```

Output only the format above, no preamble.

OPERATOR NOTE

The client note is the part that protects your work. A client who sees you “only sending to 9,000 people” after a cleanup may panic and push for a full blast, which is exactly what undoes the recovery. Explaining the ramp upfront, in their own numbers, frames the restraint as expertise. The go/no-go gates against each client’s own baseline mean “safe to widen” is defined per account, not by a generic rule, which is the whole reason you set those baselines at onboarding.

03Prove and report

The work only counts if the client sees it. These turn fixes into retainable proof.

10Before/after recovery proof

Show the lift. This is what renews the retainer.

Use the Klaviyo MCP to do the following. I ran a deliverability cleanup on this client, [describe what you did, e.g. suppressed 7,500 dead subscribers and launched a sunset flow on [date]]. Pull the before/after on the signals that matter, comparing the 30 days before the cleanup to the 30 days after. End with a one-sentence headline for the client.

Format the result exactly like this:

```
{brand} · recovery proof · cleanup [date]

                    30d before → 30d after
→ blended open:     [%] → [%]  [▲]
→ engaged share:    [%] → [%]  [▲]
→ complaint rate:   [%] → [%]  [▼]
→ bounce rate:      [%] → [%]  [▼]
→ revenue per send: [$] → [$]  [▲]

headline for the client: [one sentence]
```

Output only the format above, no preamble.

Then build an HTML before/after chart: paired bars per metric, before vs after, clearly labeled with the lift, clean and presentation-ready for the client's deck.

OPERATOR NOTE

“Revenue per send went up while we mailed fewer people” is the most retainer-renewing sentence in email marketing, because it counters the one fear every client has about list cleaning, that a smaller list means less money. It doesn’t; it means less waste. Always pull revenue-per-send alongside the open rate, because the open-rate lift alone can read as vanity. The dollar number is what makes deliverability work feel like profit instead of hygiene.

11Monthly client deliverability report

A clean, repeatable client-facing report you can generate per account.

Use the Klaviyo MCP to do the following. Build a monthly deliverability report for this client for [month], written for the client in plain language with no jargon. Cover where their list health stands, what moved this month, what we did about it, and what's next. Keep it to something a founder reads in 60 seconds.

Format the result exactly like this:

```
{brand} · deliverability report · [month]

WHERE YOU STAND:
→ list health: [plain-language read]
→ key numbers: open [%], complaints [%], engaged share [%]

WHAT MOVED:
→ [the one or two things that changed, plainly]

WHAT WE DID:
→ [the actions taken this month]

WHAT'S NEXT:
→ [next month's focus, one or two items]
```

Output only the format above, no preamble.

OPERATOR NOTE

Write client reports for the person who pays the invoice, not the person who’d understand “DMARC alignment.” The founder wants to know: is it working, what did you do, what’s next. Keep one paragraph of plain-language story over a table of metrics they won’t parse, the numbers are proof, but the sentence is what they remember and repeat to their partner when deciding whether to keep paying you.

Schedule it: in Cowork, paste this prompt and /schedule it to run monthly, per client (while that client’s account is the connected one). Time it just before your client check-in so the report’s ready when you need it.

12Flag what's abnormal per client

Across a portfolio you can’t read every metric on every account. Surface only what broke its own baseline.

Use the Klaviyo MCP to do the following. Using this client's saved baseline, [paste it, or recompute it], scan their last 30 days and return only the signals that fell outside their own normal range, ranked by how far off baseline they are. If nothing is outside normal, say so. Keep it short, this is a scan, not a report.

Format the result exactly like this:

```
{brand} · anomalies vs their baseline · last 30 days

OUTSIDE NORMAL:
→ [metric]: [current] vs band [%–%] · [how far off] · [since when]
  ...or "nothing outside normal, account healthy"

most urgent: [the one that matters + the client-facing implication]
```

Output only the format above, no preamble.

OPERATOR NOTE

This is the prompt that makes a baseline worth setting. Run across a portfolio, it lets you skip the accounts sitting in-band and spend your attention only where something genuinely changed for that client. A 0.11% complaint rate is an emergency for a client who normally runs 0.05% and a chronic-but-stable condition for one who always runs 0.11%, same number, opposite response. Generic thresholds can’t tell those apart; per-client baselines can. Re-set each client’s baseline quarterly as their list matures.

Schedule it: in Cowork, paste this prompt and /schedule it to run weekly, per client, against their saved baseline. The fast scan that flags only accounts that genuinely moved.

13Audit a client's list-growth quality

Clients celebrate subscriber count. Show them whether the new ones actually open.

Use the Klaviyo MCP to do the following. Audit this client's list-growth quality by intake channel. "Acquisition source" at the profile level isn't reachable through the connector cleanly, but the closest practical proxy is: subscriptions grouped by the Klaviyo List or signup form they came through.

Pull "Subscribed to List" events for the last 90 days, grouped by List name (and form_id where available). For each list, show the new-subscriber count, ranked by volume. Then look at which lists are tied to known-quality sources (organic signup, checkout) versus lower-quality ones (paid lead-gen, bought lists, aggressive popups) based on the list names.

Format the result exactly like this:

```
{brand} · list-growth quality · last 90 days

NEW SUBSCRIBERS BY LIST (last 90d):
→ [List name]: [count added]
  ...ranked by volume

LIKELY HIGH-QUALITY INTAKE: [lists from organic / checkout / owned channels]
WATCH: [lists from paid lead-gen, popups, or anything that tends to bring low-intent subscribers]

read: [which channel is driving the most growth, and which to scrutinize for engagement before scaling]
```

Output only the format above, no preamble. This is a volume-and-source read; to measure whether each list's subscribers actually engage, you'd need per-list engagement segments built in Klaviyo (not required for this prompt).

OPERATOR NOTE

This reframes a metric clients love (list growth) into one that actually predicts deliverability (growth quality). A client proud of adding 10,000 subscribers won’t realize half of them are dragging the program down until you show it against their own baseline. It’s also a natural upsell into acquisition or form work, when you can prove a source is poisoning the list, fixing it upstream becomes an obvious next engagement. Judge every source against the client’s own normal, not a generic open rate.

Schedule it: in Cowork, paste this prompt and /schedule it to run monthly or quarterly, per client. Pairs naturally with the monthly report.

14Build a client deliverability dashboard

One screenshot-ready visual per client, branded for your reports.

Use the Klaviyo MCP to do the following. Build a single-page HTML deliverability dashboard for this client covering the last 6 months, for use in their report. Include four elements: a status header (green / amber / red against the client's own baseline), an open-rate trend with their normal band shaded, their current engagement-cohort split (Active, Cooling, Cold, Dead), and a complaint-rate trend with their personal threshold marked. Use real numbers, no placeholder data, clean and presentation-ready.

The trend lines and status header come from campaign reports and aggregate metrics. The engagement-cohort split requires the four recency segments to exist in the account, read each segment's count to build that section. If any of the four segments is missing, render the cohort element as "needs setup, see Segment Setup section" rather than inventing the split from event samples.

First give me a two-line plain-language summary, then build the HTML dashboard as an artifact I can save and drop into the client's deck.

OPERATOR NOTE

A per-client dashboard is the artifact that makes a retainer feel tangible every month, the client sees one clean visual instead of a wall of numbers, and the “against their baseline” framing shows you understand their account specifically, not just email in general. Build one per client, keep them dated, and the monthly series becomes its own proof of the work.

Schedule it: in Cowork, paste this prompt and /schedule it to run monthly, per client (run it while that client’s account is connected). A standing dashboard run keeps each client’s deck current with minimal manual pulling.

★Put your data provider to the test

If a client buys or enriches contacts from a third-party data or identity provider, here’s the test that source should be able to pass. Run it and find out.

Use the Klaviyo MCP to do the following. Test the deliverability of contacts that came from a specific data provider, by isolating their cohort and comparing engagement and complaint rates to the rest of this client's list over the last 90 days.

The provider's contacts must be isolated as a cohort first. Most accounts mark provider contacts with either a profile property (e.g. source = ProviderX, lead_source = Y, acquisition_source = Z), or by putting them on a dedicated list or segment. If the client doesn't know how their provider's contacts are tagged, ask the provider directly, if the honest answer is "they aren't tagged," that's your first finding: untraceable bought data fails any audit.

Build (or use) a segment defined as: "has property [name] = [value]" OR "is in list [list name]", both filtering for email marketing consent = subscribed. Reusable for every provider you ever audit. If you create this segment fresh, name it "[Provider] cohort, Q[N] audit" so it doesn't pollute the long-term segment list.

Then compare the cohort's engagement to the rest of the list. For both groups show open rate, click rate, bounce rate, spam complaint rate, and unsubscribe rate side by side over the last 90 days. If a rate can't be computed cleanly from available data, say so rather than estimating.

Format the result exactly like this:

```
Provider deliverability test · [provider] · last 90 days
based on: [property / list / segment used to isolate the cohort]

cohort size: [count] · [% of list]

                    provider    rest of list
open rate:          [%]         [%]
click rate:         [%]         [%]
bounce rate:        [%]         [%]
spam complaint:     [%]         [%]
unsub rate:         [%]         [%]

verdict: [do these contacts clear the bar, or are they dragging deliverability vs the rest of the list?]
```

Honest note before running: if the cohort is tagged via a profile property only (not a segment), this audit may be slow on a large list, Klaviyo's MCP returns aggregates by metric, list, form_id, and inbox provider, but not by arbitrary profile properties. The cleanest path is to build a segment that uses the property as a condition; then this audit reads off segment-level numbers in a single pass.

Output only the format above, no preamble.

OPERATOR NOTE

Read the gap, not the absolute. A provider’s contacts opening a few points under your list average is normal, new contacts haven’t warmed up yet. A cohort running multiples of your normal bounce or spam rate is the red flag: those contacts are actively eroding sender reputation, and the client is paying for the privilege. Bounce and complaint rates are the truest tells, because they reflect address validity and genuine consent, the two things a data provider is directly responsible for delivering. If a source fails this test repeatedly, no subject-line tweak fixes it; the fix is a better source. And when a provider’s contacts pass clean, engage like the rest of the list, low bounce, low complaints, that’s a source worth feeding more budget. The test cuts both ways, which is what makes it fair.

Next steps

Two ways to take this further with your clients.

By CustomersAI · customers.ai