| name | weekly-customer-progress-update |
| description | Draft a weekly exec-sponsor progress email for an Orderful onboarding customer. Pulls the last 7 days from the customer's #mts Slack channel, recent Gmail threads, open Intercom outreach tickets, and live Orderful org and partnership state, then synthesizes everything into a one-screen email addressed to the customer's exec sponsor and saves it as a Gmail draft. Use this skill whenever the user asks for a weekly update, exec update, weekly progress email, status email, weekly recap, Friday update, or progress note for an Orderful onboarding customer — even when they don't say "exec sponsor" explicitly. Also trigger on "draft an update for [customer]", "send [customer] a progress email", "weekly [customer] update", "status email for [customer]", "weekly check-in for [customer]", or any request to produce a short customer-facing weekly progress note. If the customer name isn't in the conversation, ask for it before doing anything else.
|
| version | 0.1.0 |
Weekly Customer Progress Update
Produce a single-screen progress email that an exec sponsor at an Orderful onboarding customer can read in 60 seconds. Deliberately short, deliberately exec-tuned, and deliberately opinionated about what to leave out.
The output is always a Gmail draft. Never send.
When this fires
A customer is past kickoff and actively in the onboarding pipeline. The AM owes the exec sponsor a weekly progress note. This is a recurring, cadence-based skill — not stage-gated. It can run any week after the kickoff, all the way through cutover.
If the customer hasn't reached kickoff yet, tell the user: "Weekly exec updates start after kickoff. For pre-kickoff, run handoff-intake or kickoff-prep instead."
The input
The skill needs exactly one input: the customer name.
If the customer name isn't already in the conversation, use AskUserQuestion to collect it. Don't guess and don't proceed without it.
If the customer name doesn't resolve cleanly in Orderful (no match, or multiple matches with similar names), surface the candidates and let the user pick.
Inputs to gather
Run the four pulls in parallel — they don't depend on each other.
Orderful org and partnership state — call search_organizations with the customer name. Take the top match if similarityScore ≥ 0.9. Capture organizationId, ISA, and EDI account ID. Then in parallel: list_trading_partnerships (partnership IDs, step statuses Setup/Testing/GoLive, leader EDI accounts = the partners, linked intercomOutreachTicketId) and list_relationships (transaction-type-level TEST/LIVE/READY/SETUP/BLOCKED per partner). This is your ground truth.
Slack channel for the last 7 days — the customer's working channel follows a #<customer-slug>-mts pattern. Try slack_search_channels with <customer>-mts first. If nothing matches, fall back to searching for the customer name across channels and surface candidates. Once you have the channel ID, call slack_read_channel with oldest set to a Unix timestamp seven days ago. Read for: milestones hit, test transactions that round-tripped, partner responses, new blockers, decisions locked, escalations. Skip noise.
Gmail threads in the last 7 days — search_threads with <customer> newer_than:7d. Skim subjects and snippets. Read for: customer-facing commitments, partner replies, escalations, anything the team already said in writing that this update should reinforce. Capture the recipient + cc list from the most recent customer-facing thread — you will reuse it.
Intercom outreach tickets — pull the intercomOutreachTicketId from each partnership in step 1. For each open ticket, you only need the current state and the latest blocker. Full Intercom conversation bodies are large and will blow up your context. Use search_conversations (not get_conversation) to keep responses small. The Slack channel often already summarizes ticket state — prefer that.
Step 1 — Synthesize
Read everything, then write. Don't draft while you're still reading.
Before writing a single sentence, answer these four questions in your head:
- Are we on track for the stated go-live target? Check Slack or a recent kickoff recap for the date. If still unknown, say "tracking against the planned go-live" without committing to a date.
- What are the two to four most concrete business outcomes from this week? "Mike configured 12 relationships" is an activity. "Setup complete on Sally and Ulta, testing in flight on both" is an outcome. Translate everything into outcomes.
- What is THE single biggest risk? Not all risks — the one. Usually a blocked partner, a customer-side dependency slipping, or a partner SLA window.
- What is the ONE ask of the exec sponsor? A senior exec gets one action item per email. Pick the one that most protects the go-live date.
If you can't compress to one risk and one ask, your understanding of the week isn't sharp enough yet. Go back to the sources.
Step 2 — Draft the email
Use this exact structure. Keep the body under 350 words.
Hi [first name of exec sponsor],
Quick weekly update on where [Customer] onboarding stands.
Headline: [one sentence — on track / on track with caveat / at risk, with a date or "early-to-mid July" style range].
Progress
- [Two to four bullets. Business outcomes, plainspoken.]
Where the risk sits
- [Partner 1]: [one-line status]
- [Partner 2]: [one-line status]
- [Partner 3]: [one-line status]
- [Cross-cutting risk if any, one line.]
[One short paragraph naming the single biggest risk and what we're doing about it. This is the most important paragraph in the email.]
One ask from you
[The single concrete action the exec can take this week. Phrased as a direct question they can answer in two sentences.]
Happy to jump on a call if it would help. Otherwise we will keep the updates flowing.
Thanks,
Mike
Mike Mason
Director of Product, Orderful
mike@orderful.com
Include
- The headline sentence — the one line an exec reads on their phone.
- A small number of business outcomes from this week.
- Per-partner status as one-liners — "on track", "in active testing", "blocked on partner response".
- The single biggest risk in one short paragraph, with mitigation in the same paragraph.
- One concrete ask, answerable in two sentences.
Leave out
- Relationship counts, transaction type lists, ISA IDs, partnership IDs, ticket IDs.
- Technical patches — JSONata transforms, SuiteApp gaps, scheduled-delivery sources, comm channel IDs.
- Multi-step internal coordination details.
- More than one ask. Multi-ask emails go in the working-level recap, not the exec update.
- Activity language ("we did X, then Y"). Translate to outcomes.
If the draft is over 350 words, cut. The exec reads the first three lines and the asks; everything else has to earn its place.
Step 3 — Recipients
to: the exec sponsor — senior business contact at the customer (founder, owner, COO, VP). Usually the person on the Salesforce account and the contract.cc: working-level contact(s) at the customer (project lead, operational SME), plus the Orderful team members in the working thread — typically the implementation architect and the AM/AE.
Pull recipients from the most recent customer-facing Gmail thread. The senior name on that thread is usually the exec; the working-level names go on cc.
If you can't disambiguate the exec — for example, three customer contacts and no obvious seniority signal — ask the user with AskUserQuestion.
Step 4 — Save and report
Save the email as a Gmail draft using create_draft. Never send.
Post a short summary in chat:
- The subject line
- A one-line recap of the headline, the single risk, and the single ask
- Which recipient list you used and where it came from
Then proactively offer to set this up as a recurring weekly scheduled task using mcp__scheduled-tasks__create_scheduled_task. Most users don't realize the skill can run every Friday morning automatically.
Rules
- Don't oversell. "On track" is allowed to mean "on track with the open risks below" — but if we're slipping, name it. Calibrated honesty wins trust.
- Don't bury the lead. The headline sentence and the one ask are the two things that have to land. If they're not crisp, rewrite them.
- Don't write while reading. Read all four sources first. Synthesize. Then draft.
- Don't expand Intercom conversations. Full bodies will blow up the context. Stick to ticket state.
- Don't send. Always save as a draft. The user reviews and sends.
After saving, suggest the next move: "Next step — review the draft, send it, and tell me if you'd like this set up as a recurring weekly task."
