Sample memo · read-only · for illustration
This is a pre-built example. It is not tied to a session, cannot be edited, and is not counted in audit or export. It exists so you can see the memo format before starting real work.
Sample memo · v1 · illustrative only
Should we automate partner-request triage in Slack and email?
Audience: VP of Customer Success · Author role: TAM, infra vendor · Desired output: one-page recommendation memo.
Request
What the advisor was asked
Captured verbatim from intake. Frames the rest of the memo.
“We manually triage inbound partner requests in Slack and email. Volume has roughly tripled over the last two quarters. We want to know whether to automate triage now, pilot it on one channel, or leave it human-led.”
What I heard
The advisor's reflection
Confirmed or edited by the operator before the memo was drafted.
- Inbound partner requests arrive across Slack and email with no shared queue.
- The same request often gets handled twice by different TAMs.
- Volume has roughly tripled in two quarters; the current process is straining.
- The decision is not "automate or not" — it is automate now, pilot, or hold.
Missing context
What the advisor still wanted to know
Open questions that, if unanswered, would weaken the recommendation.
- Approval policy: Which request types require a human approver before reply? (answered: tier-1 partner contract changes only.)
- Error tolerance: Cost of a wrong auto-route? (answered: medium — recoverable within one business day.)
- Source-of-truth: Where would a unified queue live? (open — pending Ops decision.)
Watchouts
Scoped risks worth naming
Each watchout is bounded — not a generic disclaimer.
Duplicate handling will not be solved by routing alone
Routing reduces it but won't eliminate it without a shared status field per request. Plan for both.
Tier-1 partner contract changes must stay human-approved
Auto-replies on this class create real legal exposure. Hard-gate them in any pilot.
Slack thread context is easy to lose on handoff
If automation summarizes threads, capture the summary as a linked artifact, not as the canonical record.
Recommendation
Pilot on Slack only, for non-contract requests, for 4 weeks
One concrete next step, with the reasoning visible.
The volume increase is real and the cost of a wrong auto-route is recoverable, which justifies moving past status quo. But auto-handling tier-1 contract changes is not yet safe, and the unified queue question is unresolved.
The lowest-risk wedge is a 4-week pilot on Slack only, restricted to non-contract request types, with all routed items mirrored into a single audit channel for a human spot-check at end of day.
Re-evaluate at week 4 against three measures: duplicate-handling rate, time-to-first-response, and number of routed items that required human override.
Out of scope
- Email channel automation — defer until Slack pilot lands.
- Replacing the existing CRM as the system of record.
Sources
What this memo was built from
Every claim above traces back to something the operator provided.
- Intake paragraphOperator-provided, 2026-05-02
- Slack export (anonymized sample)156 messages, 14 days
- Email triage tracker (CSV)42 rows, prior quarter
- Partner contract policy v3Linked, internal wiki
What you'd get in a real session
- An editable ledger of what the advisor heard, with corrections you can make.
- An audit trail with every revision, source, and reviewer decision.
- Exportable memo with provenance, signed footer, and review-queue gating.