Your job ad describes the person. Here are the 90 days of work it should describe instead.

Most first ops hires are given a job title and no job. This is the job. Ninety days of it, in order, with a test at the end of each month that an owner can grade without being technical. Every example in here is a real defect out of a live system, and several of them are ours.

01 / Start hereWho this is for

You are about to hire your first ops person. Maybe the title is Marketing Ops, maybe it is CRM Manager, Automation Specialist, Growth Engineer, or just "someone to sort out our systems". Same job.

You have written a job ad describing the PERSON. Almost nobody writes down the WORK. That gap is why most first ops hires take nine months to produce something the owner can point at, and why a good number of them quietly become a person who runs reports.

This is the work. Ninety days of it, in order, with a test at the end of each block that you can grade without being technical.

Use it to write a better ad. Use it to interview. Use it to hold the first ninety days to something. Or ignore it. It costs you nothing either way.

02 / The sequenceThe one thing that decides whether this hire works

Almost every failed first-ops hire fails the same way: they were pointed at automation before anyone had agreed what the process actually is.

There is a sequence, and it only runs in one direction.

ELIMINATE. Does this task need to exist at all? A surprising amount of what a business does by hand exists because somebody once needed it and nobody ever switched it off. Automating it makes it permanent.

STANDARDISE. Is the process the same every time, or does each person do it their own way? If three people do it three ways, there is no process to automate. There is only chaos... and automating chaos gets you chaos at scale, faster, with an audit trail.

AUTOMATE. Only now.

The most valuable thing your new hire can do in month one is DELETE things and WRITE THINGS DOWN. If they come to you in week two with a list of automations to build, they have skipped both gates. If they come to you in week two with a list of four things you should stop doing entirely, hire more of them.

03 / Month oneDays 0 to 30. Map. Do not build.

The temptation in month one is enormous. The owner wants a win. The new hire wants to prove the hire was right. Something gets built in week two, and it becomes the thing everyone has to work around for the next three years.

Month one produces documents, not automations. One exception, at the end of this section.

1. Enumerate every rail money arrives on

Not "how do we take payment". Every distinct route by which a customer's money reaches you. There are always more than anyone thinks: a checkout page, an invoice, a payment link sent in a chat, a subscription, a card taken over the phone, a bank transfer somebody reconciles by hand, a deposit collected at an event.

For each rail, four questions:

• Does anything mark the customer as having paid?
• Does anything record what they paid, as a NUMBER, against them?
• Does a HUMAN get told, on a channel they actually look at?
• Does anything create the next action somebody now owes them?

This is the highest-yield exercise in the whole ninety days. We have audited a business with a full-looking sales pipeline that had never recorded a single unit of currency, because the automations creating those records never wrote a VALUE or an OWNER. The records existed. They were worth zero and belonged to nobody. Nothing errored. Nothing looked broken. Money had been arriving invisibly for over a year.

The NEWEST rail is almost always the worst one. It gets added in a hurry, it works (the money arrives), and nobody wires it into any of the four obligations, because the money arriving felt like the finish line.

Deliverable: a table, one row per rail, four ticks or crosses. Nothing else. It will be uncomfortable reading, which is how you know it was worth doing.

2. Answer the one onboarding question nobody asks

Ask your team this, in these words:

"When someone on your team picks up one of these leads, what do they actually OPEN?"

Most people assume the answer is "the chat". Most business owners say "our email". That gap is a live bug in every system you own.

Here is why it matters more than it sounds. A web-chat visitor who never gives an address is unreachable, and everybody understands that. But a messaging-app contact with a phone number and no email is EXACTLY as unreachable if your team replies out of a mail client. The channel improved. The record looks healthy. The task exists. And not one of them is actionable.

The rule your hire should be able to state on day 30:

REQUIRED = what follow-up needs, MINUS what we already hold.

Both halves matter. The second half is where businesses annoy their own customers: asking a member for the email address they gave you at signup reads, to them, as broken software.

3. Map who may be contacted, and how they say stop

Two separate questions that constantly get merged, and merging them is a defect in BOTH directions.

May we message them? Opt-outs, do-not-contact, unsubscribes.

May we publish them? Photos, video, testimonials, case studies.

Someone who says "please don't use my photo" has asked you not to PUBLISH them. If that quietly drops them out of your service pipeline too, you have done the opposite of what they asked. And a media refusal is blanket by default: someone objecting to the video in front of them is naming the thing in front of them, not scoping the request down to that one asset.

On opt-outs, two hard rules your hire should know before they touch a list:

• Suppress, never delete. A deleted opt-out gets re-acquired on the next import, and you breach on contact number two. The record of the "no" IS the asset.
• Per-channel opt-out, plus a global "stop everything" that is always honoured absolutely. Whether a stop on one channel should kill all channels is a BUSINESS decision, not a legal floor. For a messaging-heavy business it is usually the right call anyway, because the failure modes are asymmetric: over-suppressing costs one contact's marginal revenue and is reversible, while under-suppressing degrades a SHARED sender reputation that throttles delivery to everyone.

Also: firewall your transactional and service messages BEFORE switching any global suppression on, or someone who opted out of marketing stops receiving their receipt.

4. Find the manual work, and name the rung

Every mechanical thing a human does in your business is a bug report against your tooling. Not a task to schedule. Not a thing to hire a junior for. A defect.

For each one there is a ladder, and the answer is the highest rung that works:

1. Official API, integration, or CLI
2. Undocumented internal API (the one the vendor's own app uses)
3. Read the vendor's own front-end code. It contains the exact route and payload. This rung gets skipped almost universally and it is the one that pays.
4. Driving the interface automatically
5. A human

A hire who reports "the platform can't do that" without saying which rung they stopped on has told you nothing. Make "which rung did you stop on?" a standing question. It converts a dead end into a starting point for the next person.

Keep humans on judgment, taste, relationships, irreversible calls and approvals. Everything mechanical is machine work.

The one thing worth BUILDING in month one

If your hire is itching to ship something, ship the boring one: make sure every route money arrives on tells a human, on a channel that human actually looks at.

An in-app notification is not an alert. We have watched every payment alert in a business land in a platform's bell icon that the owner had never once opened. The highest-value event in the company, landing where nobody was looking, for months.

Pick the channel from where the person actually stands. Decide it per role, once.

Day 30 test, for a non-technical owner

Ask for four things. If you get them, month one worked.

1. The rails table, with its crosses visible.
2. A one-page answer to "what does each person open when they follow up".
3. A list of things we should STOP doing, with at least two items on it.
4. One alert that now reaches a human, which did not before.

04 / Month twoDays 31 to 60. Fix the money, then the handoffs.

Now they build. Order matters: rails first, because every later automation sits on top of the records those rails write.

5. Make every rail do all four jobs

Take the table from month one and close every cross. For each rail: mark them paid, record the value against them, tell a human on a real channel, create the action somebody now owes them.

Two failure modes worth naming in advance, because both are silent.

A record with no value and no owner is worth nothing and belongs to nobody, forever. Nothing warns you. The report just quietly reads zero. Have your hire show you a real record created by a real automation, and read the value and owner fields yourself.

A pipeline adopted halfway through a business's life is a lie until it is either backfilled or explicitly declared to start fresh. Pick one, in writing, with the date on it. Otherwise every report mixes two eras, nobody trusts the numbers, nobody uses them, and the work was wasted.

6. Every promise of a human is a debt

The moment an automated message tells a customer that a named person will contact them, you have created a debt. Not a nice touch. A debt.

An automated promise that a human will act must ALSO create that action, assign an owner, and escalate if the contact never happens. If it does not, the automation is not allowed to name a person.

Be strict about this one, because it is the failure customers actually remember. The system said someone would call. That someone never heard about it. The customer does not conclude that a workflow was misconfigured. They conclude you do not do what you say.

Related, and worse: never let an automated assistant confirm something it cannot verify. We measured a support bot telling twelve people they were "all set" when nothing had arrived, because there was no handler for what they said and it improvised into the gap. Even a hedge like "if you did it on the page, you're all set" reads to a human as confirmation.

The false agreement is more expensive than the drop-off, because nobody ever chases someone the system says is finished.

7. Never store the same fact twice

The most reliably-broken thing in any small business system is a piece of information that was typed into six places.

A link. A price. An address. An opening time. An age limit. A date.

Somebody changes it in one place and the other five keep serving the old value forever, with no error. We have watched a rebrand break four live assistants that each held a private copy of a link, one of which then pointed at a host that no longer existed... while paid ads drove traffic straight into it.

One value, one place, referenced everywhere else. Your hire should be able to answer "if we changed our phone number today, how many places would you edit?" with the number ONE.

While they are in there: store dates, never derived attributes. Write the date, not the day of the week. A day name goes stale, drifts, and silently contradicts the date next to it while reading as authoritative. The worst version of this reaches a customer: an event announced with a day name that does not match the date printed beside it, and somebody turns up to a locked door.

8. Build a fork for when they DON'T

Every journey has a happy path, and everybody designs it. Almost nobody designs the other one.

For each stage: what happens when they don't reply, don't open, don't book, don't pay, don't finish? If the answer is "nothing", the journey ends there for most of the people who enter it, which means most of the value you designed is never delivered.

A related trap if any flow has more than one step: when step two looks like step one, people read an advance as a failure. We measured a four-step collector where 259 people were asked, 165 opened it, and 25 finished. Thirty-seven said they had submitted when they had not. Eighteen conversations got device troubleshooting for a page that was working perfectly.

Three cheap fixes, no engineering required:

• State the shape in the copy, not in a progress bar: "three questions, one video each, then your details."
• Confirm the step they just COMPLETED, not only the one now due.
• Name the final landmark so they can self-report: "did you reach the Thank You screen?" This needs no system access at all, and it is the most useful sentence in any support script for a multi-step flow.

Day 60 test

• Show me a real customer record created this week by an automation. Read me its value and its owner.
• Show me the alert for our biggest payment rail, on the phone of the person supposed to act on it.
• Name one thing a customer is promised, and show me what creates the task.
• If we change our main phone number today, how many places do you edit?

05 / Month threeDays 61 to 90. Ship carefully, and make yourself replaceable.

9. Nothing reaches real people without five answers written down

Before ANY automation, campaign or broadcast touches real customers for the first time, five things exist in writing. Not as a feeling. As text.

1. Blast radius, as an integer. Worst case, how many people can this reach, and what does each one cost in money AND in reputation. "A few people" is not a blast radius. Writing the real number down changes decisions on its own: one audit produced "3,042 people share the only tag this fires on", which reframed the entire run in a sentence.
2. A kill switch the OWNER can hit, alone, from a phone. Not a script. Not a person who has to be awake. If stopping it requires your technical hire to be reachable, you do not have a kill switch, you have a dependency.
3. Proof of stop. Two separate things must be ruled out: new entries stopped, AND anyone already inside stopped. The second is the one everyone forgets and it is where the damage lives. Anything with a delay in it is holding people mid-flight, and closing the front door does nothing about them.
4. A progress meter. One number, readable DURING the run. If the only proof arrives after it is over, you were not monitoring. You were hoping.
5. Blind windows. Between which two moments could something happen that nobody can see afterwards? Every pause, resume and deploy opens one, and most systems keep no per-contact history, so that information is simply gone.

Two things we learned the hard way and now treat as rules.

A delay step is an invisibility window, and it reads as a failure. A correctly-enrolled contact can look identical to one that never entered, for an hour, because the marker lands after the wait. Never declare a live test failed before you have waited past the first delay... and check the field where success would actually appear, not the field you happen to be looking at.

Resuming a pause fires the whole backlog instantly, not on the original schedule. Expect the burst and do not mistake it for a runaway.

10. Version things, or the changelog will lie to you

Every artefact worth changing needs a version, and here is the part people get wrong: the changelog cannot be the mechanism. We have a real example of an assistant that reached version 14 with six of fourteen rows missing from a changelog whose own first rule said "no exceptions", and one row labelled v9 that actually described v13.

The version, the backup and the register entry must be written by the SAME operation. If a human has to remember to do the third one, the third one is fiction.

And a small rule with disproportionate consequences: never rename a tag, a field, or a stored value. In most systems the internal key is derived from the name, so a rename silently turns every reference into an empty string. Nothing errors. Messages just start arriving with blanks in them. Migration is additive: add the new one, move things across, retire the old.

11. Write the handover you would need if they left tomorrow

Not a manual. Nobody reads a manual, and a hire who spends month three writing one has been given nothing better to do.

Build the twenty percent that gets used: what runs on a schedule and when, what breaks most often and the first thing to check, who to call at each vendor, where the credentials live, and what NOT to touch and why.

The honest test: if this person were unreachable for two weeks, what would stop? Write that list. It is both the handover document and your risk register, and it takes an afternoon.

Day 90 test. The five questions.

Ask these. They need no technical knowledge and they are hard to fake.

1. "Show me the money." Pull up the pipeline. Does it show real currency amounts, on real records, with real owners? If the totals read zero, ninety days produced records, not measurement.
2. "Who found out?" Pick the last real payment. Show me the notification, on the phone of the person who was supposed to act on it.
3. "Show me a no." Find someone who opted out. Show me where that is recorded, and prove the next import cannot undo it.
4. "Stop it." Pick a live automation. Have the OWNER stop it, from their phone, without help. Time it.
5. "What did you switch off?" Anything on the list? A first ops hire who added things for ninety days and removed nothing has grown the system without improving it.

06 / Failure modesThe six ways this hire actually fails

Worth reading before you interview, because each one has a question attached.

Five of those six are the hire's to avoid. The sixth is yours. If nobody writes down what done looks like, month nine arrives and they are running reports, and that is the reason this document exists.

07 / The adRewriting the job ad, in one paragraph

Most first ops ads describe a person: proactive, detail-oriented, familiar with a list of tools. Every candidate claims all of it, so the ad filters nobody.

Describe the WORK instead:

That ad is harder to write and it filters hard, which is the point. The people who get excited by it are the ones you want. The ones who go quiet were going to be a nine-month problem.