On a Monday in Beirut, a 40-person firm switched on its first AI worker. By Wednesday, two customers had been told their container had arrived. It was still at port.
Nobody was careless. The owner had bought a sensible product, pointed it at the order-status inbox, and planned to fix problems as they appeared. That is how most of us set up software. It is also why two coordinators spent Thursday apologizing to customers, and why one of them quietly stopped using the thing.
The firm in this article is a composite, built from patterns I see in my work. It is illustrative, not a real client, and every number attached to it is a hypothetical, rounded figure. No study sits behind any of it. The point is the shape of the plan, not the arithmetic.
Why the ramp, not the switch
Nobody lets a new hire answer clients alone on day one. We know why. A new person does not yet know the shipment codes, the customers who need a phone call instead of a message, or the sentence that calms someone down. So we give them a colleague to sit beside, a folder of past examples, a few days of watching before speaking, and a conversation at the end of the first month about how it is going.
Software usually gets a settings page.
I use the word e-mployee for an AI worker that holds a defined role in a team: it has a job, a place in the workflow, and colleagues who depend on its output. The word is deliberate. Once a piece of software holds a role, the question changes. It stops being "is it configured correctly?" and becomes "is it ready to do this job, in front of these people?" Those are different questions, and the second one is answered by a ramp.
The belief I would ask you to drop is that setup is a configuration task: install, point, fix as you go. The belief I would put in its place is that a new AI worker needs the same two weeks a human hire would get, with a named trainer, a first-day pack, a staged schedule, and a written date on which the ramp ends. It is also cheaper to do for software than for people. The usual reason for skipping it is that the new worker is software, and that is not a good reason.
The Two-Week Ramp, stage by stage
I call the plan The Two-Week Ramp. It has a Day 0 and four stages.
Day 0: Name the people and the pack
Before anything runs, three things get written down.
- A line trainer. A person who does this job today. Not someone from IT. The trainer knows what a good answer looks like, and that knowledge is the whole input.
- A sponsor. The person who sits in the Day 14 review and signs its outcome.
- A first-day pack. Twenty real past cases, each with the answer your best person gave. The five rules that person actually uses, written in their own words. And a short list of five things the worker must never touch.
Also on Day 0, write the criteria for the Day 14 review. If you write them on Day 14, they will be shaped by how you feel that morning.
Days 1 to 3: Shadow
The worker handles every incoming job in parallel with the human. Nothing it produces is used. The trainer compares its output with the human's answer and marks each one as match, acceptable, or wrong. For every wrong one, the trainer writes down why.
Days 4 to 8: Draft
Now the worker's output goes to the trainer as a draft. A human sends it or fixes it. Every fix is logged as a one-line lesson, and the pack is updated the same day. The lessons are the real product of this stage, so treat them that way.
Days 9 to 12: One lane live
Pick the single easiest job type, such as "where is my order," and nothing else. The worker handles it for real. The trainer spot-checks a fixed sample every day, the same size each time, so the numbers can be compared from one day to the next.
Day 14: Ramp review
Thirty minutes. The sponsor, the trainer, and one frontline user who has seen the output. There are three possible outcomes and only three: extend the ramp by one week, widen to a second lane, or stop. The criteria you wrote on Day 0 decide which.
A composite example: the Beirut importer
Return to the 40-person food import firm. Again: composite, illustrative, hypothetical numbers. Say it receives about 60 order-status messages a day across WhatsApp and email, handled by two coordinators. The owner wants an AI worker for "where is my order."
Day 0. Rana, the coordinator who is best at this, becomes the trainer. She pulls 20 past threads and writes her five rules. One of them reads: "If the container is held at customs, say so and give the date we will re-check. Never a guess." The never-touch list covers credit terms, price changes, and complaints.
Shadow. Within three days the worker matches Rana on most routine threads. It also misreads two shipment-code formats and labels two partial deliveries as complete. Those become lessons one through four.
Draft. The lessons grow to about a dozen. Each evening Rana edits the pack so tomorrow's draft is better than today's.
One lane live. Only plain status questions. Anything else stays with the coordinators.
Day 14. The criteria written on Day 0 are met on the status lane. The owner wants to add "delivery date change requests" next, but the pack holds no cases for them. The group defers the widening by a week and builds those cases first.
Compare that with the Monday switch-on. Same product, same inbox. The difference is that the container at port became lesson five, in a notebook, on a Tuesday, with no customer involved.
What the ramp costs and who owns it
The cost is mostly the trainer's time. I suggest planning for about three hours a week during the ramp. In the composite, that comes to roughly six hours of Rana's time plus a 30-minute review, and the owner had put those hours in the plan rather than discovering them.
That is the rule I care most about: the trainer's hours are a line in the budget. If they have to be found, they will be found in the evenings, and the ramp will shrink to whatever fits. The second rule is that lessons are the output of the ramp, not a side effect. A ramp that ends with a working worker and no written lessons has taught you nothing about the next one.
Your Monday checklist
- Write the trainer's name next to the worker's name.
- Write the sponsor's name and the Day 14 date in the calendar.
- Assemble 20 real past cases with the best person's answers.
- Get that person's five rules, in their words.
- List five things the worker must never touch.
- Write the Day 14 criteria for extend, widen, and stop.
- Book the trainer's three hours a week.
Before your next AI worker goes live, write down its trainer's name and its Day 14 date. If you cannot, it is not ready.
If you have run a ramp of your own, I would like to hear how long yours was and what you would change. Reply and tell me.
Related evidence: AWS's SageMaker documentation describes shadow testing: a new model or serving setup is run alongside the one already deployed and its performance compared, so configuration errors and performance issues are caught before they impact end users. (AWS's guide to shadow testing a new model before it reaches users)
SHRM's onboarding guide treats onboarding as a staged process rather than a pile of forms, starting before the official start date with steps such as assigning a buddy to help the new employee integrate, and links quality onboarding to productivity and retention. (SHRM's guide to onboarding as a staged process with a named buddy)
