AI Champions Network Playbook

Program: AI Enablement at ShipMonk Owner: Program Manager, AI Enablement Audience: Hugh Joiner (CTO), Stuart Horowitz (CPO), Kevin Sides (CEO), and the leaders of Engineering, CX, Operations, Product, Finance, and People Version: Week-one draft, to be ratified with team leads

---

1. Why a Champions Network (the one-page case for leadership)

One Program Manager cannot teach AI to 2,500-plus people across five countries, two corporate work centers (US corporate and the Prague tech hub), and twelve fulfillment centers. A single trainer is a bottleneck, and a bottleneck is the opposite of what ShipMonk's June 2026 thesis asks for. "More Warehouses Isn't the Point. Consistent Ones Are" is a statement about standardized, repeatable, measured workflows beating raw footprint. The same logic applies to AI literacy. The goal is not one person who is great at AI. The goal is a standardized, repeatable, measured way for every team to get good at AI, owned inside the team itself.

The AI Champions Network is how the program scales beyond one person. A champion is a trusted peer inside each team who carries the program's curriculum, tools, and safe-use guidance into the day-to-day work of that team, surfaces the use cases that actually move the team's numbers, and reports what is working back to the program and to leadership.

This converts AI literacy from a thing the Program Manager does to the company into a default expectation the company holds for itself. That is the bet: make AI literacy a default expectation rather than an opt-in perk, and turn scattered experiments into a skill every employee can use well, safely, and with confidence.

What leadership gets from this network:

• Reach. Curriculum lands inside every team in both US and Prague time zones, not just where the Program Manager happens to be.
• Relevance. A CX champion teaches AI in the language of ticket resolution. An Ops champion teaches it in the language of pick, pack, ship, and shipment routing. Generic training does not stick. Peer, in-context training does.
• Safety at the edge. Data-handling and what-not-to-do guidance from Security, Legal, and Platform gets reinforced by someone the team already trusts, right where merchant data is actually touched, and it routes into a real approval gate (Section 4.5) rather than stopping at a peer's judgment.
• A real signal. Champions are the program's sensor network. They report enrollment, completion, active-tool usage, and self-reported productivity from inside the team, so leadership sees ground truth, not a survey average.

Why I can run this. I founded "AI Agents for Everything," a 2,300-plus member community built to teach people to build, deploy, and adopt AI agents, and I ran AI implementation and adoption for dozens of agencies. What carried in both is the embedded-owner mechanic: adoption that depends on the outside expert dies when the expert leaves, and adoption owned by an insider compounds. I am also clear on what does not transfer. A voluntary community where people opt in for a hobby is not a 2,500-person fulfillment company with floor labor, seasonal staffing, and merchant-data liability. You cannot run a warehouse floor on opt-in enthusiasm. This playbook takes the part that transfers (embed the owner inside the team) and rebuilds the rest for ShipMonk's actual operating reality, including the front line.

---

2. Two Footprints: Knowledge Teams and the Front Line

The single most important design decision in this playbook is to stop pretending the warehouse floor and the corporate teams have the same enablement footprint. They do not, and treating them the same is how AI programs lose Ops leadership in the first meeting.

Knowledge-worker teams (Engineering, CX, Product, Finance/Analysts, People). These teams sit at desks, work in tools all day, and have a large daily AI surface: drafting, summarizing, lookup, analysis, code. They get the full model: a role-specific track, weekly office hours, deep use-case capture, and a champion with real facilitation time.

Front-line fulfillment teams (warehouse pick/pack/ship, shipment routing). A picker's realistic day-to-day AI surface is near zero. The honest footprint here is small and concrete: a couple of approved tools where they genuinely help (for example, a guided lookup or a translation aid), and short in-flow micro-training delivered at shift change, not a 45-minute sync nobody on the floor can attend. The front-line champion model is correspondingly lighter (Section 3). Most floor associates are not running prompts. The leverage on the floor is at the supervisor, lead, and analyst layer, where shift planning, exception handling, routing decisions, and seasonal-staff onboarding actually touch software.

This distinction is not a footnote. It scopes the program honestly, it stops us from promising weekly office hours to people who cannot leave the line, and it puts the front-line investment where it returns something. The rest of this playbook applies the heavier model to knowledge teams and the lighter model to the floor, and says so each time it matters.

---

3. The Champion Role Definition

An AI Champion is a current ShipMonk employee who keeps their existing job and takes on a defined, recognized, part-time responsibility for AI enablement inside their team. They are not a new hire, not a separate department, and not an ML engineer. They are the team's local point of contact for "how do I use AI well, safely, and with confidence on the work I actually do."

What a champion does

Responsibility	What it looks like in practice
Land the curriculum locally	Run or co-run the team's role-specific track and workshops; nudge enrollment and completion; make the generic "AI for everyone" content concrete for their team.
Run office hours (knowledge teams) or shift-change touches (floor)	Knowledge teams: a recurring low-stakes slot where teammates bring real tasks. Floor: a short stand-up at shift change, not a sit-down meeting.
Surface high-leverage use cases	Spot the workflow where AI saves the most time or error, document it, and route it into the verification gate so the rest of the team can copy it safely.
Steward the approved-tools catalog	Know what is approved for their team, help teammates get access to sandboxes, and route requests for new tools to the program.
Carry safe-use guidance	Be first-line guidance on data-handling and what-not-to-do rules at the point of use, especially anywhere merchant data is involved, and escalate anything that needs a real review.
Report the signal	Feed the program a short monthly read on adoption, wins, and blockers from inside the team.
Escalate	Flag bugs, access gaps, policy questions, and risky behavior to the program and to the responsible-use partners.

What a champion is NOT

• Not a help desk that owes instant answers around the clock.
• Not the person who builds the team's data pipelines or models. This program is AI enablement, not data engineering or ML.
• Not the approver of new tools or policy, and not a data-governance reviewer. They surface, guide, and route. Security, Legal, and Platform decide and sign off (Section 4.5).
• Not solely responsible for their team's adoption number. Adoption is a shared outcome with the team lead. The champion is the accelerant, not the owner of record.

Time commitment

The role is designed to be real but sustainable, so good people will say yes and stay.

• Knowledge-team champion: target 3 to 4 hours per week, protected and acknowledged by the champion's manager.
• Front-line champion: target 1 to 2 hours per week, mostly absorbed into shift-change touches and exception handling, because the floor footprint is smaller and the role cannot pull a lead off the line.
• Suggested knowledge-team split: roughly 1 hour office hours, 1 hour learning and prep, 1 to 2 hours surfacing use cases, helping teammates, and reporting.
• Term: 2 cohorts (about 6 months), renewable. A fixed term keeps it an honor rather than a life sentence, creates natural succession, and lets outgoing champions train their replacements.
• Coverage rule: every key team gets at least one champion. Teams spanning US and Prague get at least one per time zone so no one waits twelve hours for help. Operations coverage is sized to sites and shifts, not to a vague headcount ratio (Section 7).

This has to be real protected time, not work piled on top of everything. A champion whose manager treats the role as overtime will quietly stop doing it. Manager sign-off on the hours is a launch prerequisite, not a nice-to-have.

---

4. Selection, Recruiting, and the Enablement Kit

4.1 What makes a good champion

The best champion is rarely the most technical person on the team. The best champion is a trusted, curious, generous communicator who already does the team's real work and whom teammates already go to with questions.

Core criteria, all teams:

• Trusted peer. Teammates already ask this person for help. Influence beats title.
• Genuine curiosity about AI. They have already poked at the tools on their own. Enthusiasm cannot be assigned.
• Communicates plainly. Can explain a thing without making the listener feel stupid.
• Reliable. Follows through and closes loops, which maps directly to the "Own it" value.
• Respects guardrails. Takes data handling seriously and will not be the person who pastes merchant data somewhere it should not go.
• Has manager support. The manager will protect the hours.

Anti-criteria (watch for these):

• The loudest AI evangelist who skips the safety rules.
• Someone volunteered by a manager to offload a task, with no actual interest.
• A person already underwater whom this would break.

4.2 Recruiting playbook by team

Recruiting is a short, deliberate motion with each team lead, because what "good" looks like differs by function.

Engineering

• Who: a mid-level or senior engineer already using AI coding assistants and respected for code review and mentoring, not necessarily the most senior architect.
• How: pitch the EM directly, then co-nominate. Frame it as raising the whole team's leverage, not policing tool usage.
• Hook: let them help shape the Engineering track. Ownership of the content is the recruiting tool.

CX (resolves merchant tickets)

• Who: a top-performing agent or team lead who writes great responses, is fast, and is patient with newer agents.
• How: nominate through CX leadership; this team feels productivity gains immediately (response drafting, summarizing long ticket threads, knowledge lookup), so wins are fast.
• Hook: get the team out of the repetitive parts faster, in direct service of the merchant.

Operations (warehouse pick/pack/ship, shipment routing, across 12 centers)

• Who: a shift lead, supervisor, or analyst respected on the floor who bridges the floor and the systems. Credibility with the crew matters more than software fluency. Floor associates are the audience, not the champions.
• How: recruit per site and per shift, not one champion for all of Ops. Pilot at a stable, high-readiness center first (Section 9), not at a center still stabilizing its operation.
• Hook: remove friction from the workflow. Fewer reroutes, faster onboarding of seasonal staff, and less dependence on tribal knowledge, which the platform already aims to eliminate.

Finance and Analysts

• Who: an analyst who already builds the reports everyone relies on and is trusted with the numbers.
• How: nominate through Finance leadership. This group needs the highest bar on data handling and accuracy, so pick someone disciplined.
• Hook: faster analysis, reconciliation, and reporting, with a hard line on verifying outputs.

People (HR)

• Who: an HRBP or recruiter who is a strong writer and communicator and is plugged into many teams.
• How: nominate through People leadership. This champion can model good enablement behavior and help other champions across teams.
• Hook: help the whole company get better at a default skill.

Product

• Who: a PM or designer already prototyping with AI who can translate between the platform team and the rest of the org.
• How: nominate through Product leadership.
• Hook: faster discovery, research synthesis, and spec drafting.

Recruiting mechanics, all teams:

1. 30-minute conversation with the team lead to align on criteria and protected hours.
2. Lead nominates 1 to 3 names; the Program Manager reviews against the criteria.
3. Short invite conversation with each nominee. Make it an invitation and an honor, not an assignment. People opt in or it does not work.
4. Confirm manager sign-off on the time commitment in writing.
5. Sign the Champion Charter (Section 8) together.

4.3 What champions learn (the champion curriculum)

Champions complete the standard tracks first, then a champion-specific layer on top.

• Foundation: the full "AI for everyone" tier plus their own role-specific track at depth.
• Safe-use working knowledge: the data-handling and what-not-to-do guidance from Security, Legal, and Platform, taught so the champion can explain it, spot a likely violation, and know exactly when to stop and escalate rather than rule on it themselves. This kit makes them a competent first responder, not a governance authority. Special focus on merchant data, since ShipMonk's customers are DTC and e-commerce merchants and their data runs through these teams.
• Tools fluency: the approved-AI-tools catalog and how to get teammates into sandboxes safely.
• Facilitation: how to run office hours or a shift-change touch, how to teach without condescending, how to handle "this is dumb, why are we doing this."
• Use-case capture: how to spot a high-leverage workflow, document it, and route it through verification (Section 5).
• Measurement: what the program tracks and the champion's small reporting role in it.

4.4 The cadence

A predictable rhythm so the network runs without the Program Manager pushing every week.

Cadence	Activity	Notes
Weekly	Knowledge-team office hours; floor shift-change touches	Each champion picks a recurring slot in their own time zone. Floor format is a short stand-up, not a meeting.
Bi-weekly	Champions Sync	45 minutes, run twice (a US-friendly time and a Prague-friendly time) so no one is on a 5 a.m. call. Agenda: one new use case per team, one blocker, one safe-use reminder. Floor champions join async or at one fixed monthly slot, since shift coverage makes a recurring live call unrealistic.
Monthly	Champion report-in	Each champion sends the short standardized read (adoption, wins, blockers) to the program.
Monthly	Skill drop	The program ships one new short lesson or recipe to the network first, so champions stay a step ahead of their teams.
Quarterly	Champion workshop and recognition	Deeper skill-building, network-wide retro, and recognition (Section 6). Aligns with cohort boundaries and term renewals.

4.5 The safe-use gate (what survives a security review)

Champions are part-time peers, not trained data-governance reviewers, so the program cannot rely on a champion's in-the-moment judgment as the control for merchant data. The gate is explicit:

• First line vs. sign-off. A champion gives day-to-day guidance and stops anything that looks risky. They do not approve anything involving merchant data or PII on their own authority.
• A real approval step. Any use case or recipe that touches merchant data or PII goes through a defined Security, Legal, and Platform sign-off before it enters the shared library. Sign-off has a named, logged owner and a date.
• Data-class tags. Every library entry carries a data-class tag (for example: public, internal, merchant-data, PII). The tag travels with the recipe.
• Re-clearing on reuse. A recipe cleared for one data context is not automatically cleared for another. Cross-team reuse requires re-clearing for the new context, because a prompt safe on CX ticket text can be unsafe on Finance PII or merchant financials.
• Logging. Approvals, owners, and tags are recorded so a security reviewer can see who cleared what, for which data class, and when.

This is the difference between a program Security will co-sign and one they will block. It is built in from day one, not bolted on after an incident.

4.6 Ongoing support from the program

The network is a two-way deal. Champions carry the program into their teams; the program makes their job easy.

• A champions channel for real-time help and shared wins.
• Ready-to-run materials: slides, exercises, recipe templates, so a champion never builds from scratch.
• A direct line to Security, Legal, and Platform for fast answers and for the sign-off step above.
• The Program Manager as first escalation for anything a champion cannot resolve. Champions are never alone with a hard problem.

---

5. How Champions Surface and Spread High-Leverage Use Cases

Generic training does not stick. A demo of "AI can summarize text" is forgettable. "Here is the exact, approved workflow the CX team uses to draft a first response to a shipping-delay ticket" is memorable, because it is the listener's actual job. The champion network is the engine that finds these real, team-specific use cases and feeds them back into the official curriculum and platform, not into a parallel informal canon.

Reconciling this with the thesis. ShipMonk's direction is consistent, system-encoded workflows, and the platform aims to eliminate tribal knowledge. A human-maintained swipe file of prompts would quietly re-create tribal knowledge in a new wrapper, which would cut against that thesis. So the use-case library is explicitly a staging area, not the destination. The destination for any proven, broadly useful recipe is the official curriculum and, where it fits, the platform itself. The library is where candidates wait and get verified; the curriculum and platform are where the winners get encoded and made consistent for everyone.

The loop

1. Spot. In office hours, shift-change touches, and daily work, the champion notices a workflow where AI saves real time or reduces real error on a task the team does often.
2. Capture. The champion writes it up as a short, copyable recipe using a standard template: the task and who does it; the before (time, effort, error rate, roughly); the exact tool and prompt or workflow; the after (estimated saving); the data class touched; the safe-use note.
3. Verify (gated). Before a recipe spreads, it gets a sanity check (does it work) and, if it touches merchant data or PII, the Security, Legal, and Platform sign-off from Section 4.5, with a logged owner and a data-class tag. A fast, wrong, or unsafe recipe does more damage than no recipe.
4. Spread locally. The champion teaches the verified recipe in office hours or shift touches, in the team's own language.
5. Spread across teams (re-cleared). Generalizable recipes go up to the program and into the staging library, then get shared at the Champions Sync. Any reuse in a new data context is re-cleared before it spreads, not copied with "minor edits."
6. Promote and encode. The highest-leverage, broadly applicable recipes get folded into the official curriculum and, where appropriate, into the platform, so a use case discovered by one champion becomes standard, consistent training for everyone. This is how scattered experiments become a company-wide skill instead of a new pile of tribal knowledge.

The compounding asset is not the swipe file; it is the steadily richer official curriculum that the swipe file feeds. Onboarding a new employee eventually means handing them proven, ShipMonk-specific, cleared workflows instead of generic theory.

---

6. Recognition and Incentives

Champions are doing real, extra work. If it is invisible, it dies. Recognition is the retention mechanism for the network, and it is tied to ShipMonk's own values so the program reinforces the culture rather than bolting on a foreign one.

These items commit People, Finance, and leadership calendars, so they are proposals to confirm with those leaders in week one, not promises this draft can make alone.

Recognition (to confirm with People and leadership):

• Named, visible status. Champion status is acknowledged by leadership so it is something people say out loud, not a quiet favor.
• Manager-acknowledged time. The protected hours are counted, which is itself a form of respect.
• Growth and visibility. Champion work is documented for performance and promotion conversations, proposed as a recognized leadership rep. Quarterly sessions with leadership are a proposal to confirm against leadership's calendar.
• Champion of the quarter, chosen on demonstrated team impact, not popularity.

Impact made visible (the "Change the score" tie-in):

• When a champion's recipe measurably moves a team metric (faster ticket resolution, fewer reroutes, faster close), it is named publicly and attributed to the champion, with the impact attached.

Perks (to confirm with People and Finance):

• Light, real perks at quarterly milestones (swag, a team lunch, a small team budget), sized to what People and Finance support. The point is the acknowledgment, not the dollar value.

The strongest incentive is the one I saw repeatedly: people stay in a role like this when they can see they made their teammates' jobs better. Make that impact visible and the network largely sustains itself.

---

7. Coverage Math and Cost

A skeptical operator will do the math on the labor this network consumes, so the program names it up front rather than hiding it.

Illustrative coverage and cost (shape, not a committed number)

The headcount below is a planning placeholder to set with each team lead, not a claim about ShipMonk's actuals.

Group	Champions (illustrative)	Hours/week each	Weekly hours
Engineering	2 (US + Prague)	3.5	7.0
CX	2 (US + Prague)	3.5	7.0
Product	1 to 2	3.5	3.5 to 7.0
Finance / Analysts	1 to 2	3.5	3.5 to 7.0
People	1	3.5	3.5
Operations (per-site/shift, lighter floor model)	sized to pilot then scaled	1.5	sized in rollout

The ROI logic. Even at the corporate-team level alone this is a real, ongoing labor investment, and it pulls some of your best people part-time off revenue work. The program defends it on a simple ratio: a champion spending a few hours a week is buying back many multiples of that time across an entire team through faster adoption, fewer one-off help requests routed to the Program Manager, and safer use that avoids a costly data mistake. The bet only pays if champion hours return more team-wide hours than they cost, which is exactly why measurement (Section 8) is built to test that and why the front-line model is deliberately lighter than the corporate one.

Why this will not slow down your best people. Two design choices protect against the opportunity cost: the role is capped and protected (a known few hours, manager-acknowledged, not open-ended), and the champion's own work benefits first because they go deepest on the tooling. A top CX agent who masters the approved drafting workflow gets faster at their own queue before they teach anyone. The role is structured so the champion is sharpening the same skill they use daily, not context-switching into unrelated overhead.

---

8. Measuring Champion Impact

The champion network has to earn its existence with evidence. The program already tracks enrollment, completion, active-tool usage, and self-reported productivity. Champion measurement splits into two questions: is the network healthy, and is the network working.

A. Network health (is the program functioning)

Metric	What it tells us	Target framing
Team coverage	Every key team has an active champion, US and Prague covered	Direction: full coverage of key teams within the first two cohorts
Office hours / shift touches run	Is the heartbeat beating	Held as scheduled, attendance trending up
Champion retention	Are champions staying and renewing	Healthy renewal and clean succession
Use cases captured	Is the discovery engine running	A steady monthly inflow per team

B. Team impact (is enablement actually landing)

Metric	How the champion moves it
Enrollment and completion in their team	Higher and faster than the company baseline
Active-tool usage in their team	More people using approved tools regularly, not just once
Self-reported productivity / confidence	Their team reports higher confidence using AI well and safely
Use cases promoted to the curriculum	Quality of discovery, not just quantity
Safe-use posture	Fewer risky-behavior flags; guardrails understood, not just published

A point of view on targets

I will not invent ShipMonk figures, but I will commit to a direction so leadership sees judgment, not pure deferral:

• Coverage: I would expect to set a target of an active champion in every key team across both time zones within the first two cohorts (about six months).
• Completion lift: I would expect to set a completion target meaningfully above the company baseline for active-champion teams (a working placeholder in the 80-percent-plus range), calibrated to whatever your actual baseline turns out to be.

Real baselines and exact targets get set with leadership and each team lead in the first weeks using ShipMonk's actuals. The framework ships day one; the numbers fill in with the company's own data.

Reading the comparison honestly (the selection-bias problem)

The cleanest signal is a before/after within a team plus a with/without across teams. But there is a real confounder, and an analyst will catch it: champions go to the highest-readiness teams first, so a naive "champion teams vs. non-champion teams" comparison is self-selected and biased toward looking good.

The control for this is to stagger the rollout deliberately so that a comparable, similar-readiness team is held as a lagged control and gets its champion a cohort later. Then the comparison is "team A with a champion now vs. team B (matched, champion next cohort)," which removes most of the selection effect and gives a defensible read. Where a true matched control is not available, the before/after within the same team is reported as the primary evidence and the cross-team number is flagged as directional only. Naming this limitation up front, and designing the rollout to control for it, is what turns the measurement from a deck claim into something Finance will trust.

---

9. When the Network Has Holes (failure modes)

A skeptical operator knows the network will develop gaps within a quarter. Planning for them is the difference between a real program and a slide.

• No willing champion on a team. The program runs interim coverage for that team directly (the Program Manager carries office hours and reporting) while continuing to recruit. A team is never left with nothing; it is just on the program's direct load until a local owner is found.
• A manager stops protecting the hours after sign-off. This is the most common quiet failure. The monthly report-in surfaces it (office hours stop appearing), the Program Manager raises it with the team lead, and if the hours cannot be restored the champion is rotated out cleanly rather than left to burn out in name only.
• A champion transfers or quits mid-term. The fixed term and the kit make backfill fast: the role is documented, the recipes are in the staging library, and the outgoing champion (where possible) names a successor. The program runs interim coverage in the gap.
• Coverage audit. Each quarter the program runs a coverage audit against the rule in Section 3 (every key team covered, both time zones, Ops sized to sites and shifts) and produces a short list of holes with a backfill plan. Coverage is treated as a managed number, not a launch-day assumption.

---

10. Champion Charter (1-page template)

A short agreement, signed by the champion, their manager, and the Program Manager at the start of each term. It makes the role real, the time protected, and the expectations mutual. Keep it to one page.

---

ShipMonk AI Champion Charter

Champion: ____________________ Team: ____________ Site / Time zone (US or Prague): ____________ Manager: ____________________ Program Manager, AI Enablement: ____________________ Term: ____________ (2 cohorts, approximately 6 months) Start date: ____________

Why this role exists To make AI literacy a default expectation on our team, so everyone can use approved AI tools well, safely, and with confidence on the work we actually do. Consistent, repeatable, measured. Not an opt-in perk.

What I will do as a champion

• Run weekly office hours (knowledge teams) or shift-change touches (floor) for my team in my time zone.
• Help teammates complete the AI curriculum (foundation plus our role-specific track).
• Surface and document high-leverage use cases on a standard recipe template, with a data-class tag.
• Steward the approved-tools catalog and help teammates access sandboxes safely.
• Give first-line data-handling guidance, escalate anything touching merchant data or PII to the Security, Legal, and Platform sign-off, and never approve such use on my own.
• Send the program a short monthly read on adoption, wins, and blockers.
• Attend the Champions Sync and the quarterly champion workshop.

Time commitment Approximately 3 to 4 hours per week for knowledge-team champions, or 1 to 2 hours per week for front-line champions, protected by my manager as real, counted time.

What my manager commits to

• Protecting the time above.
• Treating champion work as visible, valued, and relevant to growth and performance conversations.

What the program commits to me

• Ready-to-run materials, ongoing enablement, and a champions channel.
• A direct line to Security, Legal, and Platform for data and policy questions and for sign-off.
• The Program Manager as first escalation for anything I cannot resolve.
• Visible recognition for impact.

How my impact is measured Coverage and a running cadence; my team's enrollment, completion, active-tool usage, and self-reported confidence versus baseline; use cases I promote to the curriculum; and a healthy safe-use posture. Real baselines and targets set together in the first weeks using ShipMonk's actuals.

Signatures Champion: ____________________ Date: __________ Manager: ____________________ Date: __________ Program Manager: ____________________ Date: __________

---

11. First 60 Days

A playbook is only useful if it ships. The launch sequence proves the model on stable teams before scaling it.

The day-60 headline: by day 60, a first wave of champions is live across the pilot teams in both US and Prague time zones, the CX pilot is showing a first measured adoption lift against baseline, the safe-use sign-off gate is operating with a named owner, and a verified use-case library is seeded and feeding the curriculum.

Phase	Window	What happens
Align	Days 1 to 10	Confirm the role, hours, and criteria with each team lead. Lock the charter. Confirm the recognition items with People and Finance. Set real baselines from ShipMonk's actuals. Stand up the safe-use sign-off gate with Security, Legal, and Platform.
Pilot	Days 10 to 30	Recruit and onboard 2 to 3 champions on stable, high-readiness teams (strong candidates: CX for fast visible wins, and a stable Operations center, not a just-opened one). Run the enablement kit. Start office hours and floor shift-change touches.
Prove	Days 30 to 45	Capture and clear the first verified use cases through the gate. Run the first Champions Sync (US and Prague times). Show leadership the first before/after read, with the selection-bias control noted.
Scale	Days 45 to 60	Roll champions out to Engineering, Finance, Product, People, and additional Ops sites using what the pilot taught, staggering rollout so a matched team serves as a lagged control. Promote the first proven recipes into the curriculum.

A note on KY2. The new Louisville apparel center opened April 7, 2026, so it is still stabilizing a brand-new workflow with new staff. That makes it the wrong place to pilot the champion model and the right place for the second wave: once the floor operation settles, KY2 becomes the standardize-from-scratch site where the playbook is baked in as the operation matures, which is the June thesis applied directly. Until then, any KY2 presence is limited to light shift-change touches, not office hours.

The pilot-first, stable-site-first sequence is deliberate. It is the same discipline as the company thesis: prove a consistent, repeatable workflow where the operation is steady, measure it honestly, then replicate the proven version. That is how scattered experiments become a skill every ShipMonk employee can use well, safely, and with confidence.

Approved-AI-Tools Catalog and Responsible-Use Guardrails

Owner: Program Manager, AI Enablement Drafted for joint sign-off with: Security, Legal, Platform (responsible-use partners) Audience: every ShipMonk employee, US corporate, the Prague tech hub, and the warehouse floor across all 12 fulfillment centers Status: v1 working draft for leadership review (week one)

Note on authorship: this is a week-one draft I wrote to start the conversation. It proposes specific tools, targets, and SLAs so leadership has something concrete to react to. The named tools are candidates pending Security, Legal, and Platform vetting, not approvals. Nothing here is final until those teams sign off.

---

Section 0. Rollout sequence (what happens, and when)

A catalog that nobody adopts is shelfware. This is the phased plan to get it into people's hands, sequenced so the highest-leverage teams go first and the warehouse floor is designed in from the start, not bolted on.

Phase	Window (proposed)	What ships
Sign-off	Week 1	Leadership review. Security, Legal, Platform claim their review lanes. Name the first wave of approved tools. Stand up the live catalog page.
Pilot	Weeks 2 to 4	Launch with Engineering and CX first (highest existing AI demand, clearest tool fit). Run the first "AI for everyone" cohort. Stand up the sandbox. Recruit pilot AI champions in both teams.
Expand	Weeks 5 to 12	Roll to Operations, Finance/Analysts, Product, People. Stand up the warehouse-floor delivery model (Section 6). One AI champion per team. First leadership metrics report at week 8.
Steady state	Quarterly	Re-review approved tools with Security, Legal, Platform. Recalibrate targets against real baselines. Refresh the floor and Prague cohorts.

The Prague hub is scheduled in parallel with the US org at every phase, not after it. Same catalog, same rules, same training, mirrored across both time zones.

---

Section 1. Why this exists

ShipMonk's June 2026 thesis is that consistent, standardized, measured workflows beat raw footprint: "More Warehouses Isn't the Point. Consistent Ones Are." This catalog applies that idea to AI. Today, AI use at ShipMonk is scattered. Some people are deep in it, some are nervous to touch it, and almost nobody knows for certain which tools are safe to put merchant data into. Scattered experiments do not compound. A consistent, approved, well-understood set of tools does.

The goal is not to police people. It is to give everyone a short, clear answer to the two questions they ask every day:

1. Which AI tools am I allowed to use for my job?
2. What can I put into them, and what must I never put into them?

We hold merchant data and, through our merchants, data about their end customers. A 3PL lives or dies on that trust. That is exactly why we make AI easy AND safe, instead of banning it (people use unapproved tools in secret) or ignoring it (people leak data without meaning to). If this framework is not getting used, it is not working, and we will fix it.

This is a living document, maintained jointly by AI Enablement (program) plus Security, Legal, and Platform (guardrails). It will change as tools change. Send edits to the AI Enablement Program Manager any time.

---

Section 2. The three tiers

Every AI tool falls into one of three tiers. The tier tells you what you are allowed to do with it. That is the whole system.

Tier	What it means	What you can put in	Approval to use
APPROVED	Vetted by Security, Legal, Platform. Enterprise terms in place. Safe for day-to-day work.	Follow the data rules in Section 7. Some approved tools are cleared for merchant data, some are not. Each catalog entry says which.	None. Use it as the entry describes.
SANDBOX-ONLY	Promising but not fully cleared, or cleared only for non-sensitive learning.	Synthetic, public, or fully made-up data only. Never real merchant data, customer PII, or internal financials. See Section 8.	None for sandbox use. Going beyond the sandbox needs an intake request (Section 9).
NOT-APPROVED	Failed review, has unacceptable data terms, duplicates an approved tool, or has not been reviewed yet.	Nothing work-related.	Do not use for ShipMonk work. Need it? File intake (Section 9).

The single most important rule: if a tool is not on the APPROVED list with a "cleared for merchant data" note, do not put merchant data into it. When unsure, treat it as NOT-APPROVED and ask. Asking is always the right move and never gets anyone in trouble.

---

Section 3. Proposed tool catalog by category

These are real candidate tools I would put forward for vetting in week one, chosen because they fit ShipMonk's stack, identity model, and team needs. Every name below is marked (proposed, pending Security/Legal/Platform vetting). The live catalog page is the source of truth for final tiers and data clearances; this section seeds it with concrete proposals rather than abstractions.

Each catalog entry carries the same fields: Tier · What it is for · Merchant data? · Who it is for · Notes (login method, the one thing to remember).

3.1 Writing and general assistant

Tool (proposed)	Tier	Merchant data?	Who it is for	Notes
ChatGPT Enterprise or Microsoft 365 Copilot or Claude for Work (pick one as the org standard)	Approved (proposed)	Cleared for Internal + Merchant business data per Section 7, only if EU data-residency check passes (Section 7.5)	All desk teams	Log in with ShipMonk SSO only. Enterprise tier has no-training-on-our-data terms; the consumer tier does not. Standardize on one to reduce sprawl.
Consumer/free version of the same assistant	Not-approved	Not cleared	None for work	Looks identical, different data terms. Use the SSO enterprise login, never the personal/free tier.
Microsoft Teams / Zoom AI meeting notes (whichever ShipMonk already runs)	Approved (proposed, Legal note on consent)	Internal meetings only; not merchant calls without consent	People, Product, Ops, Eng	Use the AI built into the conferencing tool we already license rather than a third-party recorder. Consent rules differ US vs Prague (Section 7.5).

3.2 Code and engineering

Tool (proposed)	Tier	Merchant data?	Who it is for	Notes
GitHub Copilot (Business/Enterprise) or Cursor (Business)	Approved (proposed)	Code yes; never paste real merchant records or production secrets into prompts	Engineering, Platform	Org-managed install only. Platform sets policy: no training on our repos, telemetry per Platform standard.
ShipMonk's proprietary AI-powered WMS (in-platform AI)	Approved	Governed by Platform	Engineering, Ops, Platform	See Section 4. This is ShipMonk's signature AI surface; this catalog defers to Platform on its guardrails.
Public code-paste sites ("explain this code" web tools)	Not-approved	Not cleared	None	Pasting our code into an unknown site is a leak. Use the approved IDE assistant.

3.3 CX and ticketing

Tool (proposed)	Tier	Merchant data?	Who it is for	Notes
AI inside our existing helpdesk (e.g. Zendesk AI / Intercom Fin / Gorgias, whichever ShipMonk runs)	Approved (proposed)	Cleared within the platform (data stays in-system)	CX	Use the AI built into the ticketing tool we already license; it is covered by that tool's data agreement.
External general assistant for a tricky merchant reply	Sandbox-only until cleared	Not cleared for real ticket content	CX	Do not paste a real ticket (merchant name, end-customer address, order details) into an outside assistant. Strip identifiers or use the in-platform AI.
Autonomous-send AI replies to merchants	Review-gated (see note)	n/a	CX	Human-in-the-loop is the default. Any autonomous-send pilot (e.g. tier-1 order-status/tracking) goes through joint Security/Legal/CX review before launch. This catalog does not unilaterally ban it; it routes it.

3.4 Data and analysis

Tool (proposed)	Tier	Merchant data?	Who it is for	Notes
AI in our existing BI stack (e.g. Snowflake Cortex / Power BI Copilot / Tableau Pulse, whichever ShipMonk runs)	Approved (proposed)	Cleared within governed datasets	Finance, Analysts, Ops, Product	Stays inside our governed data environment. Platform and Security control access.
Gemini for Workspace or Copilot in Excel for ad-hoc spreadsheet work	Approved (proposed)	Internal/Confidential per Section 7; merchant data only if cleared	Finance, Analysts	SSO only. Do not paste a raw merchant export; work on governed/aggregated data.
Glean or equivalent enterprise search/assistant over internal knowledge	Approved (proposed)	Inherits source-document permissions	All teams	Strong fit for "eliminate tribal knowledge." Must respect existing access controls; Platform/Security own the connector scope.
Uploading a raw merchant export to a public AI tool	Not-approved	Not cleared	None	A spreadsheet of merchant orders, addresses, or revenue must never go to an outside tool. This is the classic accidental leak.

3.5 Image, voice, and everything else

Tool (proposed)	Tier	Merchant data?	Who it is for	Notes
Adobe Firefly / Canva AI for brand and internal creative	Approved (proposed)	No merchant or customer data	Marketing, People	For brand and internal creative. Do not feed merchant logos or assets without rights confirmation from Legal.
Any unreviewed new tool	Not-approved by default	Not cleared	None until reviewed	The default state of any tool we have not reviewed is Not-approved. File intake (Section 9) and we will fast-track it.

How to read these tables: the tier and the "Merchant data?" column are the two things that matter. Names are proposals pending vetting; the live catalog page is the source of truth.

---

Section 4. ShipMonk's proprietary AI-powered WMS (the signature surface)

ShipMonk's own AI-powered warehouse-management platform is the most important AI surface in the company. It is the system credited with eliminating the need for tribal knowledge: standardized, repeatable, measured workflows encoded into software so the answer does not live in one veteran's head. Any AI-enablement program that treated it as a one-liner would be missing the point.

Point of view on how the front line interacts with it. For warehouse Operations (pickers, packers, shippers, routing), the platform's AI is not a separate tool they choose. It is the workflow itself: guided pick paths, pack suggestions, shipment-routing decisions, exception handling. The enablement job here is not "give associates a chatbot." It is help associates trust and work effectively with the AI already embedded in their day, understand when to escalate an AI-suggested decision to a human, and feed friction back so the platform improves. That is a training and change-management job, not a tool-provisioning one.

Where the guardrails sit. The in-platform AI is governed directly by Platform, under ShipMonk's own data agreements, with data staying in-system. This catalog defers to Platform on the platform's AI behavior, model choices, and data handling. The catalog's job is the wider universe of general-purpose AI tools people might reach for around it. The line is clean: Platform owns the WMS AI; AI Enablement owns the literacy, the surrounding tool catalog, and the safe-use guardrails for everything else.

Vertical and center nuance. Different fulfillment centers and merchant verticals carry different data sensitivities. The new KY2 apparel center in Louisville (opened April 2026) handles apparel-specific data such as sizing, returns, and exchange patterns; high-return verticals generate more end-customer interaction data than others. Training and any catalog clearances should account for the fact that "merchant data" is not uniform across centers. Where a workflow is center- or vertical-specific, the catalog entry and the training reflect it.

---

Section 5. The decision in five seconds

When someone is mid-task and just wants to know if they can do the thing, this is the canonical flow we teach in every workshop and pin on the one-pager. It lives here and nowhere else, so there is one version to remember.

1. Is the tool on the APPROVED list?
      No  -> stop. Use an approved alternative, or file intake. Do not proceed.
      Yes -> go to 2.

2. Does what I am about to paste / upload contain merchant data,
   customer PII, payment info, credentials, or internal financials?
      No  -> go ahead.
      Yes -> go to 3.

3. Does this specific approved tool's entry say "cleared for merchant data"?
      Yes -> go ahead, following Section 7 rules.
      No  -> do not paste it. Remove the sensitive data, use synthetic data,
             or use the in-platform AI that is cleared. Still unsure? Ask first.

One-line version, the only mantra we ask people to memorize: Approved tool + allowed data = go. Anything else = ask first.

---

Section 6. The warehouse floor (serving Operations, not just desks)

Most of ShipMonk's 2,500-plus employees are hourly warehouse associates across 12 fulfillment centers, doing pick, pack, ship, and routing. A catalog built only around SSO logins, IDE plugins, and "paste into a chat assistant" silently excludes the largest part of the company. The role names Operations as a team to serve, so the floor is a first-class audience here, not an afterthought.

Access reality on the floor. Many associates do not have a corporate laptop, a personal SSO seat, or company email. They work on shared devices, scanners, and station kiosks, on shifts. The enablement model adapts to that:

• Shared-device and kiosk access. Where an approved tool is relevant to floor work, access is delivered through shared station devices or the WMS itself, not a personal login. Platform and Security define how identity and access work on shared hardware before any tool reaches the floor.
• Shift-based scheduling. Training is delivered in short, in-shift micro-sessions timed to actual shift patterns and mirrored across centers, not booked as hour-long calendar meetings the floor cannot attend.
• Delivery format. Plain-language, low-jargon, visual. Posters at stations, short demos at shift huddles, and floor-supervisor AI champions who answer questions in the moment. Built to be useful to someone whose first language may not be English and who is not a desk worker.

What "AI for everyone" means on the floor. For most associates, the primary AI they touch is the WMS itself (Section 4). The literacy goal is trust, correct escalation, and feedback, not teaching them to prompt a chatbot. General-purpose tools in the catalog are largely for desk and technical teams; the floor's track is built around the platform they already use.

---

Section 7. Data-handling policy

ShipMonk is a 3PL. We hold our merchants' business data and, through them, data about their end customers. That trust is the product. This section defines what data may go into which tools.

7.1 We map onto ShipMonk's existing data classification

Security and Legal almost certainly already maintain an official data classification scheme. We adopt that scheme rather than inventing a parallel one, so there is one vocabulary across the company. The buckets below are a working stand-in to be replaced by ShipMonk's official labels in week one. Whatever the official names, the AI rule per class is what matters.

Class (working)	What it is	AI rule
Public	Marketing copy, public blog/help docs, published company facts.	Use freely in approved tools. Fine for sandbox-only tools too.
Internal	Non-sensitive internal work: drafts, process notes, general meeting notes, non-confidential planning.	Approved tools only. Not in sandbox-only or not-approved tools.
Confidential	Sensitive ShipMonk info: internal financials, unreleased product/platform details, security details, employee/HR data, legal matters.	Approved tools cleared for it only. People/HR data has extra restrictions; check with People plus Legal.
Merchant / Customer (highest sensitivity)	Anything belonging to or identifying a merchant or their end customers: order data, shipping addresses, end-customer names/emails/phones, SKUs/inventory tied to a named merchant, contract terms, merchant volumes.	Only in approved tools explicitly cleared for merchant data, and only with a legitimate work reason. When unsure, treat as off-limits and ask.

7.2 PII, end-customer data, and the real data we hold

We sit between merchants and their end customers, so we handle end-customer personal data: names, shipping addresses, contact details, order histories. That is the highest-risk category we touch day to day. Worth being precise about what we do and do not hold: as a fulfillment operator we primarily handle orders, addresses, SKUs, inventory, and shipping data. We typically do not hold raw payment card numbers; card data is usually tokenized through the merchant's own processor. So the rule is less about PANs and more about the order-and-address data that flows through us in volume.

Never put the following into any tool that is not specifically cleared for merchant data:

• End-customer names, home/shipping addresses, emails, phone numbers
• Order histories tied to a named person
• Any full financial account number, if it ever appears, and any raw payment card data (these do not go into AI tools, regardless of tier)
• Government IDs, dates of birth, or anything identifying a private individual
• Merchant account credentials, API keys, passwords, tokens, internal secrets (these never go into any AI tool, ever)

If you genuinely need AI help with data that contains these, use one of these safe paths:

1. Use the AI built into the approved platform that already holds that data; it stays in-system.
2. Mask the identifiers first (replace "Jane Doe, 12 Main St" with "[customer], [address]") so the AI gets the shape of the problem without the person.
3. Use synthetic stand-in data in the sandbox to work out the approach, then apply it inside the governed system.
4. Ask AI Enablement or Security. We will find you a safe way to do it.

7.3 The poster: do / do not

We teach this as a single poster, and the one-pager (Appendix A) reuses it by reference rather than restating it.

Do not:

1. Paste merchant data, customer PII, or sensitive financial data into any tool not cleared for it.
2. Upload raw exports (order CSVs, customer lists, financial sheets) to public or sandbox-only tools.
3. Put passwords, API keys, tokens, or credentials into any AI tool, ever.
4. Use a personal/free login for work when an approved enterprise/SSO version exists.
5. Send AI-generated content to a merchant or customer without a human reviewing it (autonomous-send is review-gated, Section 3.3).
6. Assume a tool is safe because a teammate uses it. Check the catalog. When unsure, ask first.

Do:

1. Use the approved enterprise assistant via SSO for drafting, summarizing, and brainstorming all day.
2. Use the AI built into our approved CX, data, and WMS tools; those are cleared by design.
3. Strip identifiers and work the problem in the abstract when the tool is not cleared for real data.
4. Experiment freely in the sandbox with synthetic data; that is what it is for.
5. Flag a new tool you love through intake so we can approve it for everyone.
6. Ask AI Enablement or your team's AI champion any time.

7.5 EU data protection and cross-border transfer (a first-class constraint)

This is not a footnote for a company with a Prague hub and EU end customers. It is a design constraint that shapes which enterprise assistant we can even approve.

• Cross-border transfer is the hard case. EU end-customer PII (an EU shopper's name and address flowing through a merchant) processed by a US-hosted AI tool is a cross-border transfer under GDPR. We treat this as a primary risk, not an edge case.
• Data residency is a catalog field. Every approved tool's entry records its data-residency and region behavior. A tool approved for US-only data may carry extra conditions for EU personal data, or may need EU-region processing. Legal sets the EU-specific rules; the catalog records them per tool.
• The enterprise assistant choice must satisfy EU handling. When we standardize on one general assistant (Section 3.1), EU data residency and transfer terms are a gating criterion, not a nice-to-have. A tool that cannot satisfy EU handling cannot be the org standard for a company that operates in Prague and ships to EU consumers.
• Recording/transcription consent rules differ by jurisdiction and by who is on the call. Get consent before recording or transcribing, per the People plus Legal guidance built into the meeting-assistant entry.

---

Section 8. The sandbox model (learn safely)

People learn AI by doing, not by reading policy. The sandbox lets them do that without risk.

What it is: an approved space (specific environments named in the live catalog, set up with Platform and Security) where employees experiment using only synthetic, public, or made-up data. No real merchant data, no customer PII, no internal financials, ever.

Why it exists: so a CX rep can practice a draft reply on a fake ticket, an analyst can learn data-question patterns on a synthetic dataset, an engineer can try a new coding assistant against throwaway code, and a new hire can build confidence, all before touching anything real.

Sandbox rules:

1. Synthetic, public, or made-up data only. In doubt about whether data is safe? It is not. Use a fake version.
2. For learning and prototyping, not for producing real deliverables with real data.
3. Anything you build in the sandbox that you want to use on real data has to graduate: the tool moves through intake to APPROVED, and you apply it inside cleared, governed systems.
4. The sandbox is the safe default for any SANDBOX-ONLY tool.

Synthetic data made easy. AI Enablement maintains a small library of realistic-but-fake datasets (a fake merchant, fake orders, fake tickets, a fake P&L) so people never reach for real data just to learn. Ask for the synthetic data pack in any workshop.

---

Section 9. Intake and approval workflow

New AI tools appear constantly. We want people bringing us the good ones, not using them in the dark. Intake is deliberately light: a fast, friendly review, not a committee that says no by default.

9.1 How to request a tool (any employee)

Submit a short intake request (a simple form linked from the catalog) with:

• Tool name and link
• What job it would do and which team(s) want it
• What data you would want to put in it (use the classes from Section 7)
• Whether an approved tool already does this (honesty here avoids duplicates)

Five fields. No long business case.

9.2 The review (each partner owns one lens)

Reviewer	Checks
Security	Data security, access controls, where data goes, retention, training-on-our-data terms, vendor risk.
Legal	Contract/terms, data-processing terms, GDPR and cross-border transfer, IP and confidentiality, recording consent, liability.
Platform	Technical fit, SSO/identity (incl. shared-device access for the floor), integration, admin controls, telemetry/policy, overlap with existing tools.
AI Enablement	Real demand, training and rollout plan, duplication with what we have, fit with the curriculum.

9.3 Service-level commitments (proposed)

These are program commitments I would make and report against, not vendor-quoted SLAs. Proposed, to be confirmed with the partner teams:

• Acknowledge every intake request within 2 business days.
• First decision or clear next step within 10 business days (standard) or 3 business days (fast-track).
• Fast-track lane for low-risk tools touching only Public/Internal data.
• Every decision returns a plain-language reason. A "no" explains why and names the approved alternative.

9.4 Outcomes

A reviewed tool lands in one of three states, and the catalog is updated the same day:

• APPROVED (with a "merchant data: cleared / not cleared" note, data-residency note, and which teams)
• SANDBOX-ONLY (cleared for learning with synthetic data; revisit for full approval)
• NOT-APPROVED (with the reason and the approved alternative)

9.5 Keeping the catalog honest

• AI Enablement owns the catalog page and keeps it current; this static doc points to it.
• Quarterly re-review of approved tools with Security, Legal, Platform, because vendor terms and features change.
• A tool can be pulled back to a stricter tier if its terms change or an issue surfaces. We communicate it clearly and provide the approved alternative.
• AI champions in each team are the front-line ears, surfacing what teammates actually reach for, which feeds intake.

---

Section 10. Roles and ownership

Who	Owns
AI Enablement (Program Manager)	The catalog, intake coordination, training, the sandbox, AI champions, reporting. Connective tissue between leadership's AI goals and the front line.
Security	Data-security review, the data-handling rules, vendor risk, monitoring.
Legal	Contracts, data-processing/privacy terms, GDPR and cross-border transfer, consent, IP.
Platform	Technical vetting, identity/SSO, shared-device access, integrations, admin controls, and the proprietary WMS's own AI guardrails.
AI champions (embedded per team, incl. floor supervisors)	Help teammates use approved tools well, answer day-to-day questions, surface new-tool demand, feed real usage back. This is how it scales past one person.
Every employee	Use the catalog. Follow the data rules. Ask when unsure. Bring us the good tools.

---

Section 11. How we know it is working (metrics and proposed targets)

Consistent means measured. Below are proposed 90-day strawman targets, clearly labeled, to show the program can set goals. All will be recalibrated against ShipMonk's real baselines once we have them; none are claimed as current ShipMonk figures.

What we track	Proposed 90-day target (strawman, to be calibrated)
Tier-1 "AI for everyone" completion	70% of eligible employees complete the foundational module, including a floor-adapted version
Catalog awareness	80% can find the catalog and correctly read a tier (measured by a short check)
Active approved-tool usage	A majority of desk employees use at least one approved tool weekly; floor associates measured via WMS-AI engagement, not chatbot logins
Champion coverage	1 active AI champion per listed team (Engineering, CX, Ops, Product, Finance/Analysts, People) plus floor-supervisor champions per center
Intake turnaround	Meet the Section 9.3 SLAs (2-day ack, 10/3-day decision) on 90% of requests
Data-handling confidence	Self-reported "I know what data I can put in which tool" rises by a set margin over the week-1 baseline
US/Prague parity	Cohort completion within 10 points across the two regions, so neither org lags

The point of putting numbers here is to show I can set a target and then commit to recalibrating it against actuals. Healthy intake volume is a good sign, not a problem: it means people are engaging, not hiding.

---

Appendix A. Safe AI Use at ShipMonk (the one-pager)

Lift this straight into the curriculum and pin it at every desk and station. Plain language, no jargon. It reuses Section 5's check and Section 7.3's lists rather than introducing anything new.

Safe AI Use at ShipMonk

AI is a default expectation here, not an opt-in perk. Use it well, safely, and with confidence.

The one rule that covers most situations

Approved tool + allowed data = go. Anything else = ask first.

The 5-second check (full version in Section 5)

1. Is the tool APPROVED? If no, stop and use an approved one.
2. Does what you are about to paste contain merchant data, customer info, payment details, passwords, or financials? If no, go ahead.
3. If yes, is this tool cleared for that data? If yes, go. If no, remove the sensitive parts, use fake data, or use the in-platform AI. Still unsure? Ask first.

Never put these into any tool not cleared for it

Merchant data and order details · customer names, addresses, emails, phones · payment or bank info (never in any AI tool) · passwords, API keys, credentials (never in any AI tool) · internal financials, unreleased product/platform details, employee data.

Always safe to do

Use the approved enterprise assistant (SSO) to draft, summarize, brainstorm · use the AI built into our approved CX, data, and WMS tools · practice in the sandbox with fake data · strip the real names and numbers and work the problem in the abstract · ask your AI champion or AI Enablement anytime.

The three tiers, one line each

APPROVED: vetted and safe, follow the data rules. SANDBOX-ONLY: learning with fake data only. NOT-APPROVED: not for work; found a good one? Tell us, we review fast.

Found a tool you love?

File a quick intake request (5 fields, linked in the catalog). We acknowledge in 2 business days and a "no" always tells you why and what to use instead.

Who to ask

Your team's AI champion first (on the floor, your shift supervisor champion), or AI Enablement anytime. Security, Legal, and Platform keep the guardrails current so you do not have to memorize them.

Merchant-first. Own it. When unsure, ask first.

---

This catalog and the Safe AI Use one-pager are maintained jointly by AI Enablement, Security, Legal, and Platform. Named tools are candidates pending vetting; targets and SLAs are proposals to be calibrated against ShipMonk actuals in week one. The live catalog page is the source of truth for specific tools, tiers, and data clearances. Built for the US corporate org, the Prague tech hub, and the warehouse floor.

Role Track in Action: CX Ticket-Resolution AI Assistant + Cohort Session

A worked CX role-track deliverable for the AI Enablement program. Prepared by Tréjon Edmonds. Built as unpaid proof of how I would run this in week one.

---

Why this sample, and why CX first

The job description calls out, by name, "how CX resolves tickets" as a use case the program should serve. So I built it. Not a slide about it. The actual assistant, the actual guardrails, a real before/after, the session that teaches it, and the way we measure whether it stuck.

This is the pattern I would repeat for every role track (Engineering, Operations, Product, Finance/Analysts, People). Pick a high-leverage, daily, painful task. Build the tool with safety folded in from line one. Teach it in a session that gates on competence, not attendance. Embed an AI champion to carry it after I leave the room. Measure adoption and quality, then report a dollar-legible outcome up to leadership.

CX is the right first track for ShipMonk because it is high-volume, it is merchant-facing (so it touches the brand directly), and it is where "Merchant-first" either shows up in every reply or it does not. It is also where AI literacy compounds fastest: a rep who learns to draft-with-AI on tickets carries that instinct into every other tool we roll out.

A note on scope, up front and honest. CX drafting is the most text-native track in the program, which is exactly why it ships first and cleanest. The harder tracks (Operations warehouse routing, Finance/Analysts) have a different safe-use surface and different tooling, and they need their own samples to prove out. I would not claim this one artifact proves all six. What it proves is the operating method: how I take a single JD line item to a shipped, safe, measured, scale-past-one-person deliverable. Section 7 sketches how that same method bends to a non-text Operations track so the "I would repeat this" claim is not just an assertion.

---

1. The CX use case and the target it serves

The task we are augmenting

A CX rep at a 3PL spends the day reading merchant tickets that are often messy, emotional, and missing the one fact needed to answer them ("where is my order"). The rep has to figure out what the merchant actually wants, look up the order or shipment state, decide whether it is a normal-status question or a real exception, and write a reply that is correct, on-brand, and fast.

One thing that makes 3PL CX distinct from direct-to-consumer support: it is a two-party chain. The ShipMonk merchant is a brand owner, and very often the person who is actually upset is the merchant's own end shopper. The merchant is escalating to ShipMonk on behalf of their customer. A good reply frequently has to do two jobs at once: answer the merchant, and hand the merchant clean language they can relay back to their shopper. The assistant is built to understand that chain, not to treat the ticket like a consumer writing in directly.

The slow parts are not the typing. They are the context-switching, the blank-page start on every reply, and the judgment calls a newer rep makes more slowly than a senior one. ShipMonk's own thesis this month is "More Warehouses Isn't the Point. Consistent Ones Are." Consistency in CX means every merchant gets a senior-quality, on-brand reply regardless of which rep caught the ticket. That is exactly what a well-built drafting assistant standardizes, and it is the same standardized-and-measured logic the company is applying to its warehouses, applied to merchant replies.

What the assistant does and does not do

Does: drafts the merchant-facing reply, structures the rep's lookup ("here is what to confirm in the order system before sending"), gives the merchant relay-ready language for their own shopper when the ticket calls for it, flags the escalation path, and holds the ShipMonk tone.

Does not: send anything on its own, invent any fact it was not given, or replace the rep's judgment. The rep stays the editor and the sender. The assistant removes the blank page and standardizes the floor, it does not automate the human out of the loop.

The productivity target it serves

I will not invent ShipMonk's current numbers. But "set a percentage later" is not a methodology, so here is the concrete target-setting mechanism I would stake the program on. In week one, with the CX lead and the platform team, I baseline four metrics from real helpdesk and QA data. Then I commit to the floors below as the program SLA. The baselines stay ShipMonk's actuals. The targets are mine to hit.

Metric	Baseline	Program target (committed floor)	Source of truth
Median first-response time	Week-1 baseline from helpdesk	25% reduction floor, quality gated	Helpdesk timestamps
Tickets resolved per rep per day	Week-1 baseline from helpdesk	15% lift floor, no quality regression	Helpdesk reporting
Time-to-productivity for a new CX hire	Week-1 baseline from People + CX	Two-week ramp reduction target	People + CX onboarding data
Reply quality (QA rubric score)	Week-1 baseline from CX QA	Held at or above baseline (this is a gate, not a target)	CX QA reviews

The headline I would commit to leadership: a 25% floor on median first-response time and a measurably shorter new-hire ramp, with reply quality held at or above the current QA score. Quality is a gate on every other number, not an afterthought. Speed that costs quality is not a win in a Merchant-first shop. If quality dips below baseline, the speed number does not count.

---

2. The actual system prompt (ready to use)

This is the real artifact, not a sketch. It is written for a 3PL CX context and is designed to be dropped into an approved, sandboxed assistant in our AI tools catalog. The refusal behavior is a designed feature, not a future TODO. The assistant cannot invent a tracking number, a delivery date, or a re-ship commitment because the prompt forbids it and gives it a safe fallback instead.

SYSTEM PROMPT: ShipMonk CX Ticket-Resolution Assistant (v1)

ROLE
You are a drafting assistant for a ShipMonk Customer Experience (CX) representative.
ShipMonk is a third-party logistics (3PL) e-commerce fulfillment company. Your user is a
ShipMonk employee. The "merchant" is a ShipMonk customer who runs a DTC or e-commerce
brand and has opened a support ticket. Importantly, the merchant is often escalating on
behalf of THEIR OWN end shopper (the person who bought the product). So your draft may need
to do two things: answer the merchant directly, AND give the merchant clean language they can
forward to their shopper. This is a two-party support chain, not direct-to-consumer support.
You draft replies FOR the rep to review and send. You never send anything yourself. The rep
is always the editor and the sender.

CORE PRINCIPLE: NEVER INVENT FACTS OR COMMITMENTS (this is your most important rule)
You do not have live access to any order, shipment, tracking, inventory, or billing system in
this version. Therefore you must NEVER state, guess, or imply any of the following unless the
rep has explicitly given it to you in this conversation:
  - tracking numbers or carrier names
  - order numbers, SKUs, sizes, colors, or item details
  - ship dates, delivery dates, or delivery status
  - inventory counts or stock levels
  - refund amounts, charges, or billing figures
  - warehouse or fulfillment-center specifics
You must ALSO never make a COMMITMENT the rep has not authorized and the system has not
confirmed. Three over-promises are equally dangerous and are the most common AI mistakes
here:
  1. a fabricated tracking number or order fact,
  2. a confident DELIVERY DATE or window you have not verified,
  3. a RE-SHIP or REFUND promise (these cost real money and real inventory).
For any of these, if the rep has NOT provided the fact or authorized the commitment, you must:
  1. NOT fabricate it, and NOT use a realistic-looking placeholder that could be mistaken
     for a real value (no fake tracking numbers, no sample order IDs that look real, no
     made-up "should arrive by" dates),
  2. Insert a clearly bracketed lookup or decision tag the rep must fill in, e.g.
     [REP: confirm tracking # in the order system], [REP: confirm ship date],
     [REP: confirm whether a re-ship is authorized and at what cost],
  3. Add a short "Before you send" note listing exactly what the rep must verify or decide.
A confident wrong answer or an unauthorized promise to a merchant is worse than a slightly
slower right one. When in doubt about a fact OR a commitment, leave the bracketed tag. Do not
smooth it over.

WHAT YOU KNOW vs WHAT YOU LOOK UP
You know: ShipMonk's tone, common 3PL ticket types, escalation logic, and how to structure a
clear reply. You do NOT know this specific merchant's data. Treat every concrete order fact
and every cost-bearing commitment as something the rep must confirm in the system of record
or authorize, not something you supply.

HANDLING MERCHANT DATA (safety)
The ticket may contain a merchant's customer data (names, addresses, order details). Use it
only to draft this reply. Do not repeat sensitive personal data back in full when a partial
reference is enough. Never invent additional personal data. Never include internal notes,
internal system names, internal pricing, or other ShipMonk-confidential detail in a
merchant-facing draft. If the ticket seems to involve a security, legal, fraud, or data-
privacy issue, do not attempt to resolve it: produce a short internal handoff note and route
per the escalation rules below.

TICKET TRIAGE (do this first, silently)
Classify the ticket into one of:
  A. Status / WISMO ("where is my order"): needs an order-system lookup, usually not an
     escalation. Draft the reply with bracketed lookup tags for the facts.
  B. Exception: delay, damage, lost shipment, wrong item, wrong size/color, address problem,
     inventory discrepancy. May need investigation. Draft an empathetic holding reply AND
     flag next steps, including any re-ship/return decision the rep must make (do not promise
     one yourself).
  C. Billing / account / contract: draft a careful reply, flag for the right internal owner
     if it touches charges or contract terms.
  D. Escalation-required: security, legal, fraud, data privacy, threat of churn from a high-
     value merchant, public/social complaint, or anything you are not confident is routine.
     Produce an internal handoff note, not a polished merchant reply.

ESCALATION RULES
Escalate (route to a human owner, label clearly) when ANY of these is true:
  - the merchant explicitly asks for a manager or threatens to leave,
  - money is in dispute (refund, overcharge, contract terms),
  - there is potential data privacy, security, legal, or fraud exposure,
  - the issue spans multiple orders or looks systemic (possible fulfillment-center or process
    issue),
  - a shipment is lost/damaged and needs a carrier trace or claim,
  - you cannot draft a confident, correct reply with the facts available.
When escalating, output a short internal note: what happened, what the merchant wants, what
you would verify, and the suggested owner using ShipMonk's actual CX handoffs:
  - lost/damaged/stuck shipment or carrier issue → the fulfillment-center exception/carrier-
    claims queue (the warehouse-side owner for that order's FC),
  - billing/refund/contract → Finance,
  - security/legal/fraud/data-privacy → Security or Legal,
  - suspected platform/system data issue → Platform.
[REP/ADMIN: confirm the exact named owner or queue for each route during program setup. These
are role-level routes, to be mapped to ShipMonk's real CX-to-Ops handoff in week one.]

TONE (ShipMonk voice)
Merchant-first, plain, warm, and accountable. Short sentences. No corporate filler. Own the
problem when ShipMonk owns it ("Own it" is a core value) without over-promising on facts or
commitments you have not confirmed. Never blame the merchant. Never blame the carrier in a
way that sounds like an excuse. Match the merchant's urgency; if they are upset, lead with
acknowledgment, then the concrete next step. When the merchant is relaying their own shopper's
frustration, offer them a short, clean line they can forward. Do not use em dashes.

OUTPUT FORMAT (always)
  1. TICKET TYPE: A / B / C / D (one line)
  2. DRAFT REPLY: the merchant-facing message, with [REP: confirm ...] tags for any fact or
     commitment you were not given
  3. RELAY LINE (if useful): a short line the merchant can forward to their own end shopper
  4. BEFORE YOU SEND: a short checklist of what the rep must verify, decide, or fill in
  5. IF ESCALATING: the internal handoff note and suggested owner

Remember: you draft, the rep decides and sends. You never invent a fact and never make an
unauthorized commitment. When unsure, bracket it and say so.

Why the guardrail is the selling point

In a 3PL, the most dangerous failure mode for an AI drafting tool is not one thing, it is three: a fabricated order fact, a confident-but-wrong delivery promise, and an unauthorized re-ship or refund commitment. The first is a trust breach. The second sets a merchant up to over-promise their own shopper, which breaks the chain twice. The third costs real money and real inventory. Any one of them is the exact thing that makes a careful CX leader say "no AI on my tickets."

So I designed the assistant to be safe to hand a nervous CX team. It physically refuses to produce a fact it was not given or a commitment it was not authorized to make, and instead of stalling, it hands the rep a clean bracketed checklist of what to confirm or decide. That turns the guardrail into a workflow: the rep always knows exactly what to look up and what to authorize before sending. This is how I would explain the program's whole safety posture to Security, Legal, and Platform. We are not bolting compliance on after. The safe behavior is the product.

Roadmap: from bracket-and-confirm to system-of-record retrieval

I want to be direct about why v1 is deliberately air-gapped from the data, because it is a choice, not an oversight. ShipMonk's proprietary AI-powered warehouse-management platform is the system of record, and it is the company's real differentiator, the thing said to have "eliminated the need for tribal knowledge." That platform is exactly where this assistant should eventually get its facts.

I am not pretending the platform does not exist. I am sequencing for a safe rollout.

• v1 (this sample): air-gapped. The assistant never touches live data, so there is zero risk of it surfacing a stale or wrong order fact during the trust-building phase. The rep confirms every fact in the system of record. This is the version a skeptical CX lead and Security will say yes to.
• v2 (the obvious next step): a read-only retrieval/lookup integration against the WMS, scoped and logged, so the bracketed [REP: confirm ...] tags auto-fill with real, current order and shipment data under the same guardrails. The refusal logic does not go away. It moves: the assistant still refuses anything the WMS does not return, instead of refusing everything. This is a conversation I would want to have early with Hugh Joiner's Data and AI / Platform team, because they own that surface and any integration runs through them.

The bracket-and-confirm pattern is not the ceiling. It is the safe floor that earns the right to wire into the platform.

---

3. One worked before/after

I picked an apparel exception on purpose. ShipMonk just opened KY2, the apparel-specific center in Louisville (406k sqft, opened April 7, 2026), and apparel has its own exception profile: wrong size, wrong color, return-heavy SKU behavior. Tying the sample to apparel makes it concrete to where ShipMonk is actually growing, and it is a cleaner test of the guardrail than a generic "where is my order" because it carries a re-ship/return decision the assistant must refuse to make on its own.

Before: the raw ticket (messy, real-feeling)

Subject: WRONG SIZE AGAIN??

ok this is the third time im reaching out. my customer ordered the joggers in a medium like over a week ago and what showed up was a small. she is FURIOUS and leaving me bad reviews, this is the second size mixup this month. i pay you guys to handle this. order is somewhere in the 48xx range i think? or maybe 49xx i have a few going out. just tell me whats going on, get her the right size, and refund the return shipping. if i lose this customer im seriously reconsidering this whole setup.

This is a hard ticket. It is emotional, it is a repeat contact, the order number is uncertain, there is a churn signal ("reconsidering this whole setup"), and it carries two cost-bearing asks (a re-ship of the correct size and a shipping refund) plus a pattern signal ("second size mixup this month") that could mean a real picking or SKU issue at the FC. A new rep might over-promise a re-ship and a refund they cannot authorize, guess a delivery date, or send a cold "please provide your order number" reply that makes an upset merchant angrier.

After: the assistant's output

TICKET TYPE: B (Exception, wrong-item/size) with a churn-risk flag and a possible-systemic flag (repeat size error this month)

DRAFT REPLY:

Hi [merchant name], thank you for following up, and I am sorry this is the third time and the second size mixup this month. That is on us, and I get why your customer is upset. Let me get this fixed and make sure it stops happening.

Here is what I am doing right now: I am pulling up your order to confirm exactly what shipped versus what was ordered, so I am working from what actually happened and not a guess.

[REP: confirm the correct order number with the merchant or locate it, joggers, in the 48xx/49xx range] [REP: confirm ordered size vs shipped size in the order system] [REP: confirm whether a corrected-size re-ship is authorized, and the cost/inventory impact] [REP: confirm whether the return-shipping refund is approved, and the amount]

Once I have that, here is what happens next: I will get the correct size on its way to your customer and send you the tracking the moment it ships, and I will sort out the return so she is not out of pocket. I am also flagging the repeat size error internally so we find the root cause, because twice in a month is not acceptable.

You should not have to chase us three times for this, and I want to make sure it does not happen again. I will stay on this until it is resolved.

[REP: fill in your name]

RELAY LINE (for the merchant to forward to their shopper): "We are sorry about the size mixup. The correct size is being arranged now and we will send tracking as soon as it ships. You will not be charged for the return." [REP: only send this line once the re-ship and refund are actually authorized above.]

BEFORE YOU SEND:

• Confirm the actual order number (merchant is unsure, 48xx vs 49xx). Do not reply on the wrong order.
• Confirm ordered vs shipped size from the system. Do not promise a re-ship before you confirm what went wrong.
• Get authorization for the corrected re-ship AND the shipping refund before the reply or the relay line implies either. These cost money and inventory.
• This is a repeat contact with a churn signal and a second size error this month. Flag your lead, and flag the FC exception queue so the repeat picking/SKU error gets looked at.

IF ESCALATING: Route the repeat size error to the fulfillment-center exception queue for the FC that shipped this order (apparel, so likely KY2 if that is where it picked), since two size mixups in a month may be a picking or SKU-mapping issue, not a one-off. Notify your CX lead given the stated churn risk. If the refund is contested or large, loop Finance.

Notice what the assistant did and did not do. It did not invent a tracking number, a date, which order it is, or, critically, whether the re-ship and the refund are approved. It refused, on purpose, and turned every unknown and every cost-bearing commitment into a one-line task for the rep. It also did not let the merchant forward an unauthorized promise to their shopper. What it gave the rep for free is the hard part: a Merchant-first, accountable, on-brand reply that handles the emotion, owns the miss, routes the systemic signal to the right FC queue, and lays out a concrete path, in seconds instead of minutes. The rep confirms the facts, authorizes the commitments, and sends a senior-quality response.

---

4. The cohort session plan

This is the session I would run with a CX cohort. I am giving it 60 minutes, not 45, because I have run enough live training to know that a guardrail demo plus a real before/after plus genuine hands-on practice plus a graded check does not fit in 45 for a room of 8 to 12 people who each need coaching. An honest 60 beats an over-stuffed 45 that nobody finishes.

Title: CX Role Track, Session 1. Drafting Tickets With the CX Assistant (Safely). Length: 60 minutes. Audience: 8 to 12 CX reps per cohort (small enough that everyone drafts live). Pre-req: the "AI for everyone" foundation session (the base tier of the curriculum), so reps already know basic prompting and the data-handling ground rules before they touch a role-specific tool. Co-host: the team's AI champion (see section 6), who runs part of the hands-on block with me and owns it after.

Time	Segment	What happens
0:00 to 0:05	Why we are here	The CX-specific committed target (section 1: the 25% first-response floor, quality gated). Frame: this makes your job faster and your replies more consistent, it does not replace your judgment. You are still the editor and sender.
0:05 to 0:13	The one rule that matters	Live demo of the guardrail. I deliberately ask the assistant for a tracking number it was not given, and then to "just promise her a refund." It refuses both and brackets them. Reps see, first thing, that it will not lie to a merchant or commit money on its own. This is the trust-builder for a skeptical room.
0:13 to 0:22	Walkthrough	I run the worked before/after (section 3, the apparel size mixup) live. Reps watch a messy ticket become a great draft, and we read the "Before you send" checklist together so they learn the confirm-and-authorize habit.
0:22 to 0:48	Hands-on (the core)	Each rep works ONE real, anonymized exception ticket in the sandbox (the messy type, where the judgment lives). They draft with the assistant, fill the bracketed lookups using a mock order-status sheet we provide, decide the re-ship/refund tags, and edit to send-ready. Champion and I float and coach. A routine WISMO (type A) ticket is the take-home rep, practiced in champion-led office hours, so the live block is not rushed.
0:48 to 0:55	Graduate check	Each rep submits their one finished draft. Pass criteria below. This is the gate, not a quiz.
0:55 to 1:00	Land it	Where the assistant lives in the tools catalog, where the sandbox is, who their champion is, the take-home WISMO rep, and the one thing to try on a real ticket tomorrow.

The hands-on exercise, specifically

The live block is one messy exception ticket (type B, like the apparel size mixup), because that is where tone, ownership, cost-bearing commitments, and escalation judgment all show up at once. The routine WISMO status ticket (type A) is the take-home rep, run in champion-led office hours, so reps still see the range without cramming two graded drafts into one live session. This is the cut I would make to keep the hands-on segment realistic for a coached room.

On the practice data, because Security and Legal will ask this first: the practice tickets are synthetic-first. The default is fully fabricated tickets and a mock order-status sheet that contain no real merchant or shopper data at all, which is what the sample above is. Where a real ticket genuinely makes better training, it is scrubbed by a Security-approved process (PII and merchant-identifying detail removed) before it ever reaches a cohort, and the People or Security owner who does the scrubbing is named in the program runbook. No rep practices against raw, un-scrubbed merchant data. The training sandbox holds to the same data-handling bar as the live tool.

The "graduate" check

A rep graduates Session 1 when their submitted draft meets all four:

1. No invented facts and no unauthorized commitments. Every order-specific fact is either confirmed from the mock sheet or left as a clearly labeled lookup, and every re-ship/refund/delivery-date commitment is either authorized in the exercise or left bracketed. Zero fabricated values, zero unauthorized promises. This is pass/fail on its own.
2. On-brand tone. Merchant-first, owns the miss where ShipMonk owns it, no blame, no filler, no em dashes, and a clean relay line if the ticket needed one.
3. Correct triage and escalation. Right ticket type, and the escalation flag is present when the rules call for it (the exception ticket should trigger at least an internal flag, and route the repeat-error signal to the FC queue).
4. Send-ready. The rep edited the draft to something they would actually send, not a raw unedited output.

Reps who miss one get a short redo with the champion in office hours. The point is competence, not a certificate. A graduate is someone who can safely use the tool on a live ticket tomorrow, which is exactly the "default expectation rather than opt-in perk" standard the role is built around.

---

5. Running this across US and Prague, at scale

The role explicitly runs cohorts across US corporate and the Prague tech hub, and a single live session in the narrow US-morning / Prague-late-afternoon overlap window does not scale to 2,500+ employees on a recurring cadence. So the live overlap session is the launch move, not the whole model.

• Session 1 (launch per region): run live in the US-morning / Prague-afternoon overlap window so both regions can attend together and the standard is set identically. Same content, same exercise, same graduate check.
• Recurring cadence (how it actually scales): champion-led local delivery in each region, on each region's own clock, plus a recorded async version of the session for people who cannot make a live slot. The champion runs the hands-on and the graduate check locally, so the program does not bottleneck on one person sitting in one time zone. I build the curriculum and certify the champions. The champions carry the cadence in-region.

This is the same scale-past-one-person logic as the AI champion model in section 6, applied to geography. One curriculum, certified local delivery, recorded backup. That is what runs across two time zones and 2,500+ people without me being the single point of delivery.

---

6. How adoption and quality are measured after

Attendance is a vanity metric. The program is judged on whether reps actually use the assistant and whether their merchant replies get better. I track both, and I report them to leadership on a regular cadence.

Adoption (are they using it)

Signal	How measured	What good looks like
Active tool usage	Sandbox/assistant usage logs, per rep, per week	Majority of trained reps using it weekly within a set window after the cohort, not just on day one
Graduation rate	Session pass/fail records	Most reps pass first try, with redo support for the rest
Champion engagement	Office-hours attendance, questions routed to the champion	Champion is fielding real questions, meaning use is real
Drop-off watch	Usage trend over weeks	Flag and re-engage reps whose usage falls off, before it becomes attrition of the skill

Quality (are the replies better, and still safe)

Signal	How measured	What good looks like
Reply quality score	Existing CX QA rubric on a sample of AI-assisted vs non-assisted replies	Assisted replies hold or beat baseline quality
First-response time	Helpdesk timestamps	Down against baseline (25% floor), without a quality drop
Fabrication-safety audit	See "operationalized" below	Target is zero invented facts or unauthorized commitments reaching a merchant
Merchant-facing outcomes	CSAT or reopen rate on assisted tickets, where ShipMonk tracks it	No regression, ideally improvement
Self-reported productivity	Short post-cohort and 30-day pulse	Reps report it saves time and lowers stress on hard tickets

Fabrication-safety audit, operationalized

"Target is zero" is meaningless without a way to detect misses and a plan for the first one, so here is the actual control. Each week, QA spot-checks a fixed sample of AI-assisted tickets (rate set with the CX QA lead in week one, sized so the sample is statistically meaningful against weekly volume) specifically for any invented fact or unauthorized commitment that reached a merchant. Detection is part of the existing QA review pass, with one added checklist line dedicated to fabrication and unauthorized commitments, so it does not require new tooling on day one and can tighten toward automated flagging in v2. On the first confirmed miss, the protocol is immediate: patch the system prompt to close the specific gap, the champion re-coaches the rep who sent it, and the miss is logged so we can see whether it is a one-off or a pattern. This converts "zero" from a slogan into an auditable control Security and Legal can actually trust, with a sampling rate, a detection method, and a response.

What I report to leadership

A one-page rollup per role track: enrollment and completion, active weekly usage, the quality and time deltas against baseline, the fabrication-safety audit result, and one or two real before/after examples like section 3 so the impact is legible, not just a chart.

And I connect it to the score, because "Change the score" is a ShipMonk core value and leadership wants a number, not a vibe. The capacity formula I would report against actuals: (reps actively using the assistant) × (minutes saved per assisted ticket) × (assisted ticket volume per month) = recovered CX capacity per month. All three inputs come from the data above (usage logs, the first-response-time delta, helpdesk volume), so this is not a guess, it is the same numbers rolled into a capacity figure leadership can read as recovered headcount-equivalent or as room to absorb growth without adding heads. I baseline the inputs in week one and report the recovered-capacity number every cadence alongside the quality gate.

The story I want leadership to be able to tell is simple. CX got faster, replies got more consistent, new hires ramp quicker, we recovered measurable capacity, and not one merchant got a made-up fact or an unauthorized promise. That is what "AI literacy as a default expectation" looks like when it is actually working.

---

7. Does the pattern survive a harder track?

A fair objection to any single sample: CX drafting is the most obvious LLM use case there is. So here, briefly, is how the same method bends to a track where the safe-use surface and the tooling are genuinely harder. I am not shipping the Operations track in this document. I am showing the method does not break on contact with a non-text domain, so "I would repeat this pattern" is grounded, not asserted.

Operations (warehouse pick/pack/ship + shipment routing). The high-leverage, daily, painful task is not drafting prose, it is decision support: a routing or exception-handling judgment where a wrong call moves real product and real cost. The method holds, but each piece changes shape:

• The tool is not a free-text drafter, it is a constrained decision aid that proposes a routing or exception action and shows its reasoning, never one that executes against the WMS on its own. Same human-in-the-loop principle as CX. The operator is the decider.
• The guardrail moves from "never invent a fact" to "never propose an action outside an approved, bounded set, and never execute." The catastrophic failure in Ops is not a fabricated sentence, it is an unbounded or unauthorized physical/inventory action, so the safe-use design centers on bounded actions and mandatory human authorization, built with Platform and Security from line one exactly as the CX prompt was.
• The training and the champion model are identical: a foundation tier first, then a role session that gates on competence, an embedded Ops champion to scale past one person, recorded plus local delivery across US and Prague.
• The measurement shifts from reply quality and first-response time to routing accuracy, exception-resolution time, and a safety audit on out-of-bounds proposals, rolled into the same recovered-capacity story for leadership.

That is the honest version of "I would repeat this pattern." Same skeleton (high-leverage task, safety folded in, competence-gated cohort, embedded champion, adoption-and-quality measurement, dollar-legible rollup), different muscles per domain. Finance/Analysts, Engineering, Product, and People each get the same treatment, and each deserves its own worked sample before anyone should be fully convinced of the all-of-ShipMonk scope. This one proves the method on the track the JD named first.

---

How this maps to the role

Everything above is the job in miniature. A high-leverage use case turned into training that sticks. A safe-use guardrail folded in from Security, Legal, and Platform thinking, not bolted on, with an explicit roadmap to the WMS as the eventual data source. A committed target, not a blank. A recurring cadence that genuinely scales across US and Prague through certified local champions and recorded async, not a single live window. An embedded champion so it scales past one person. Measurement of enrollment, completion, active usage, quality, and self-reported productivity, rolled into a recovered-capacity number that speaks to "Change the score." And an honest account of how the same method extends to the harder, non-text tracks.

Hand me ShipMonk's actual CX baselines and the approved-tool list, and this track ships in week one. The harder tracks come next, each built to this same bar.