Adoption Packet and Support Route
Version 1.1 · Kramaniti Kosh
Intended outcome
A one-page packet that tells a small team how to use a new AI-assisted workflow in daily work: what it is for, what stays with people, when to override it and who to ask when it goes wrong.
Before you begin
- One workflow that is about to go live, or that people already use informally
- The person accountable for the workflow and the person who will answer questions about it
- Your rules on which client information may go into which tools
How to use
- Fill in the packet with the workflow owner before rollout. If AI is already being used informally for this work, describe what people actually do today and build from that.
- Walk the team through it in a short meeting, then run the first-week plan. Keep the packet where the work happens, not in a separate folder no one opens.
- Collect questions and overrides during the first two weeks, update the packet and note the version each time.
Working template
Workflow purpose
What this workflow is for, in one or two sentences:
Who uses it:
Version and date:
Version owner:
Approved uses
Not approved
- [For example: sending anything to a client without a person reading it]
- [For example: pasting in client contracts, financial data or personal details]
Client information rules
- Which client information may go into the tool:
- Which information must never go in:
- Where to check if unsure:
Inputs and sources
- Source records the workflow should use (tracker, notes, briefs):
- How to prepare the input (a short standard or example prompt):
Review before it leaves the team
- Who reviews output before it goes to a client:
- What the reviewer checks (facts, dates, commitments, tone):
- Output that always needs the account lead or a partner: [for example, anything about fees, scope changes or delays]
Override rule
When to ignore or rewrite the output, and what to record when you do:
Support route
- First point of contact for questions:
- How to reach them (channel):
- What to include when asking (the input, the output, what went wrong):
- Who decides if the workflow should be paused:
First-week plan
- Day 1: short walkthrough and one supervised run each
- Days 2 to 4: use on real work with review; log every question and override
- Day 5: 20-minute review of the log with the workflow owner; update this packet
Feedback and write-back
- Where questions and overrides are logged:
- Who reviews them and how often:
- Where agreed fixes are written back (instructions, input standard, this packet):
Demonstration
This is an illustrative scenario, not a client case study or a measured result. Do not reuse its details as facts about your work.
A sample five-person branding agency wants to use an AI assistant to draft weekly client status updates from its project tracker and meeting notes. Two designers have already been trying it on their own.
Sample inputs
Demonstration inputs only: the tracker lists tasks, owners and due dates; meeting notes are kept in a shared document; the founder currently writes every client update; one designer has pasted a client’s unreleased campaign brief into a free tool.
Example output
Workflow purpose
Draft weekly client status updates from the tracker and meeting notes so the account lead reviews rather than writes from scratch.
Approved uses
Drafting status updates for active projects; summarising internal meeting notes for the account lead.
Not approved
Sending any update without the account lead reading it. Pasting unreleased client briefs, contracts or fee details into any tool not approved by the founder.
[Fact within this demonstration] One unreleased brief has already gone into a free tool.
[Recommendation] The founder decides whether the client needs to be told, before the packet is shared.
Review before it leaves the team
The account lead checks dates, deliverables and anything that sounds like a promise. Any update mentioning a delay, extra rounds or fees goes to the founder.
Support route
Questions go to [Name the designer who has used the tool most] on the team chat, with the input and output attached. The founder decides whether to pause the workflow.
First-week review
[Inference] The two designers who tried it first may find the rules restrictive. Their questions from week one are the most useful input for version two of the packet.
Quality check
A new team member could use the workflow from the packet alone; client information rules are specific; every client-facing output has a named reviewer; the support route names a real person; the packet has a version and an owner.
Limits and human review
The packet sets out how the team should work; it does not make a tool secure or confirm what a provider does with the data you enter. Check each tool’s current terms and your client agreements before use. Keep consequential actions with the named human owner.
Edition notes
New in Kosh at version 1.1. Provider-neutral Markdown instructions; no installation or platform compatibility is implied. Runtime behaviour has not been verified across AI providers. Reuse terms have not yet been published. Background reading: The Adoption Packet Before the AI Build. Team support and regular reviews after a system goes live are part of Kramaniti’s Complete Lifecycle Retainer.