Tuning your first Pack — what to change in week two

You installed the Pack. It ran. Some output is right, some is almost-right, some sounds like a model wrote it because a model wrote it. Now what.

The instinct is to open the standing orders and start editing. Don't. Not yet. The first month is mostly watching, then making three or four changes in a specific order. Tune the wrong thing first and you re-tune it twice. Tune in the right order and the Pack settles into the Boss's voice by week three.

Four weeks. What to change, what to leave alone, when to hire it out.

Why is week one the wrong week to tune?

A Pack is a recipe your harness executes on a cadence. Standing orders, voice, watchdogs, receipts. The first week of output is noisy because the harness hasn't run against enough of your real data to show its pattern. One bad Tuesday brief isn't a pattern. Six in a row, same mistake, is.

The mistake Bosses make is treating every off-key output like a bug and editing the standing orders the same afternoon. By Friday they've made nine changes, half of which fight each other, and the Pack has drifted further from what they wanted than it was on Monday.

Week one is for watching. Week two is for the first real edit.

Week 1, install and observe

Don't tune. Capture every output for seven days. Outbound Engine drafts forty-eight messages, you read forty-eight. Lead Rescue nudges thirty cold leads, you read thirty. PM Engine runs seven mornings in a row, you read every brief before opening Slack.

Three columns in a notebook:

• Right. Ship as-is.
• Almost-right. Ship after a 30-second edit. Tone off, one fact wrong, structure fine.
• Wrong. Won't ship. The Pack misread the input, hallucinated a number, picked the wrong audience, or sounded like ChatGPT.

You're looking for the qualitative pattern, not single mistakes. Three good messages and one bad one is noise. Twenty-eight of forty-eight opening with the same generic line is a pattern. The bad email isn't the bug. The opener is.

Write three things at the end of the week:

1. The voice. Does it sound like you, or like the model? If a peer read these, would they guess you wrote them?
2. The audience. Is the Pack hitting the right segment? Nudges going to leads who never asked about your offer is a targeting problem, not a voice problem.
3. The cadence. Too often, not enough, or about right? PM Engine every two hours is too much; once a day is usually right.

That's it. The temptation to edit on Wednesday is enormous. Resist it. The pattern needs the full week.

Week 2, what to tune first

Three changes, in order. Voice, then audience, then cadence. Don't change all three at once or you can't tell which change moved the output.

Tune the voice first

Almost every Pack in week one sounds more like the model than the Boss. The voice file shipped thin. A VOICE.md with two paragraphs of "we're friendly but professional" and a logo isn't a voice file; it's a placeholder. The model has nothing real to anchor against, so it defaults to LinkedIn copy from a mid-tier SaaS.

The fix is the same across every Pack: load five to ten examples of your own writing into the file. Not your best writing. Your normal writing. Pull from:

• Five sales emails you sent and got replies on
• Two Slack messages where you explained something to a client in plain language
• One sales-call transcript where you described the offer
• One LinkedIn post you were happy with

Paste them into VOICE.md under "Reference samples, Boss's actual voice." Don't paraphrase. Don't clean them up. The typos are part of the voice. The way you start sentences with "Honestly," and end them with "anyway" is part of the voice. The model picks up the rhythm in two or three runs.

This single edit fixes more output quality than any other tune in month one. If you only do one thing in week two, do this.

Tune the audience parameters second

After voice is fixed, run two more days and watch. Half the time, what looked like a voice problem was an audience problem. The Pack was writing in a generic voice because its picture of the buyer was generic.

This is where Outbound Engine and Lead Qualifier Engine break most often. Standing orders ship with a default qualifier like "B2B operators with $1M+ revenue." Too broad. Anyone who fits is too generic to write to specifically, so the messages all sound interchangeable.

Narrow it. If you sell to fractional COOs at agencies between $1M and $5M, the qualifier says so. If your highest-converting buyer last quarter was agencies in the $2M to $4M band who'd already tried hiring an in-house ops person and failed, that's the qualifier.

For PM Engine, the audience tune is who reads the brief. A brief for a solo Boss looks nothing like one for a four-person team.

Tune the cadence third

By end of week two you'll know whether the Pack is running too often, not enough, or right.

• Too often: outputs repeat, you stop reading, receipts pile up unread.
• Not enough: things slip. Lead Rescue isn't catching leads before they go cold; PM Engine isn't surfacing blockers before they're fires.
• About right: you read the output the day it lands, act on it, don't dread it.

Outbound Engine runs three times a week by default. Faster cycle, move to daily. Messages feeling like spam, move to twice a week. PM Engine runs daily. Solo Boss and the daily brief is noisy, move to three days a week with a "blockers only" alert on off days.

One rule: change cadence in one direction at a time. Daily to three. Watch another week. Drop further if it's still too much.

Week 3, the second pass

Week three is for the things week one and two surfaced but you didn't act on yet.

Encode the edge cases

Open your week-one notebook. Wrong column entries fall into two or three patterns. Lead Rescue keeps nudging leads who replied last week. Outbound Engine keeps writing to enterprise decision-makers in SMB founder-bro tone. PM Engine keeps escalating blockers waiting on a client, not the team.

Each pattern becomes an exception in the standing orders, plain English:

• "Skip leads who replied in the last 14 days, regardless of qualification status."
• "When the lead's title contains VP, SVP, Director, or C-suite, drop the casual openers and use the formal voice profile."
• "Don't escalate a blocker flagged 'waiting on client.' Surface in the weekly brief, not the daily."

These exceptions are how the Pack compounds. By month three, fifteen or twenty are encoded and the output is sharper than what most agencies produce by hand.

Look at integration friction

Where does the Pack hand off to a human, and is the handoff in the right place? Two failure modes.

Too early. Outbound Engine drafts, dumps in your approval queue, sits until you review fifteen at once. Should have been later: Pack drafts, sandbox for two hours, watchdog runs a quality check, queues only messages below confidence threshold. The rest go automatically.

Too late. PM Engine writes the standup brief, posts to Slack, includes a blocker that needed a decision yesterday. Should have been earlier: when the Pack detects a blocker needing an operator call, ping in real time, not the morning brief.

Walk every handoff. Move the ones in the wrong place.

Catch memory drift

A Pack running three weeks accumulates things it should remember and things it forgets. Forgot your client's preferred name, this quarter's offer, the vertical you stopped selling to in January? Write it back into the recipe.

Open VOICE.md and the source assets folder. "Don't reference the Q4 webinar offer; retired." "Refer to the client as Marcus, not Mr. Chen." "We don't sell to the legal vertical anymore."

The unglamorous part of tuning. Also why Packs get sharper over time and one-shot prompts don't.

Week 4, the Boss's review

End of month one. Thirty minutes with the receipts folder open. Four questions.

One: how many hours did this Pack save me?

Outbound Engine drafted 180 messages; 8 minutes per message by hand is twenty-four hours saved. If half were messages you'd never have sent because you didn't have time, that savings number is misleading. The honest version: hours saved on work you would've done anyway, plus revenue on work you wouldn't have.

Two: how much revenue did this Pack move?

Upstream, not the Pack itself. Lead Rescue doesn't generate revenue; it nudges cold leads back into the cycle that close. The number is "revenue from deals that touched the Pack." Closed three deals, Lead Rescue nudged two of them back, that's the number. If none, the Pack is running but not earning back yet. Worth recording.

Three: which parameter is working and which isn't?

Pick one to keep, one to fire. The keeper is the week-two-or-three change that obviously moved the output. The one to fire is the parameter still producing noise. Qualifier too broad. Cadence wrong. A watchdog firing so often you've started ignoring it.

Bosses who write "keep one, fire one" every month end up with a Pack pruned a dozen times by month six. That Pack outperforms a fresh install by a wide margin.

Four: keep, retire, or stack?

• Keep: earned its install cost back. Run as-is. Re-review end of month two.
• Retire: ran a month, moved nothing. Either the bleed wasn't real, the Pack wasn't right for it, or you didn't have the inputs. Pull it, free the token budget, install something else.
• Stack: it worked, and you can see where the next Pack compounds. Lead Rescue worked; Lead Qualifier Engine becomes the obvious next install because you're nudging leads back but can't tell which to prioritize. The stack is where the Bleed-to-Build Loop kicks in: last month's Pack tells you which Pack to install next.

The Weekly Operator Scorecard at /templates/weekly-operator-scorecard is the template I use. Five fields, ten minutes.

The three things you should never tune in month one

Three things in the standing orders look tunable in week one and aren't.

The trigger conditions. The entry point the Pack uses to decide when to run, a new CRM lead, an invoice over X days unpaid, a calendar event flagged as discovery, is the contract between the Pack and the rest of your business. Change it in week one and you'll spend three weeks chasing a regression because outputs are firing on the wrong inputs. Watch for thirty days. If they're wrong, you'll know.

The output destination. Where the Pack writes, your CRM, a Notion doc, an email draft folder, a Slack channel, is load-bearing. Move it and you've added noise to a settled system. Bosses move the destination because a notification annoys them, then realize a week later they've broken the audit trail. Don't.

The schedule, separate from cadence. Cadence is "how often." Schedule is "what time, what day." If the Pack runs Monday 6am and you wish it ran Sunday night so you'd have it for Monday, leave it. The Pack is telling you what timing works in your business. After thirty days you'll have real data on whether Sunday night beats Monday. Move it then if it does.

When to call for help

Some Bosses run this loop themselves and have a tuned Pack by week four. Others open the receipts folder on a Saturday and admit they didn't read the output for two weeks. The Pack is running but not being tuned.

That's what the Tune retainer is for. Case Call-scoped DWY, we tune for you. Watch outputs, write exceptions, edit the voice file, prune noise. You stay the Boss. We keep the standing order tuned. The retainer makes sense when the Pack is producing real revenue and you don't have bandwidth for month-one observation. It doesn't make sense if the Pack hasn't moved revenue. The question there isn't tuning; it's whether the Pack is the right one for the bleed.

The other call is back to the diagnostic. If by week four the Pack is tuned, watched, and still not moving revenue, the install was wrong. Re-take the Bottleneck Check at bossmode.ing/bottleneck-check or book a Case Call. Tuning a Pack pointed at the wrong hole is expensive practice for nothing.

You're the Boss. You tell the Co-pilot where to go. Month one teaches you what the standing order does well, what it doesn't, and where you have to rewrite the route. By month three, the Pack runs cleaner than anything you'd produce by hand, and the only person who can run it is you, because the voice file and the exceptions and the memory all live in your harness.