Give every automation a job description.
When a team hires a person, someone writes down what the job is. There is a title, a manager, a list of duties and a sense of what the new hire is not allowed to decide alone. When the same team switches on an automation that reads the shared inbox and drafts replies to clients, there is usually nothing written down at all.
An automation is a hire you didn't interview.
Think about what a typical automation is trusted with. It reads email, updates records, files invoices, books appointments and sometimes sends messages that carry the organization's name. A new employee with that reach would get an offer letter and a probation period; the automation gets a setup screen and a toggle.
The gap matters more as AI tools get more capable. An older rule-based automation did exactly one thing, and you could read the rule. An AI agent makes small judgment calls on the way to its goal: which emails count as urgent, which line items look like duplicates, how to phrase a reply. Judgment is the reason you want it, and it's also why somebody has to agree in advance on what it may and may not do.
What goes on the job description.
A useful job description for an automation fits on an index card and answers the questions you would answer for a person in that seat.
Start with the purpose, in one sentence a stranger could understand. "Sorts incoming intake forms by program and flags any with missing signatures" is a purpose. "Helps with intake" is not, because nobody can tell from it whether the automation is doing its job.
Then name the manager: one person who answers for the automation's output, plus a backup for when that person is on leave. Write down what it may read and what it may change, and list separately anything it may send outside the organization. Those three are different levels of trust and deserve different levels of care. An automation that reads the scheduling calendar is a small risk. One that can cancel appointments is a bigger one, and one that can email patients about those cancellations is bigger again.
Finally, set a review date. People get a ninety-day check-in; an automation deserves the same, and then a recurring one after that.
Write the limits as carefully as the duties.
Most automation setups describe what the thing should do. Very few describe where it should stop, and the stopping points are where the trouble usually starts. A school district office that sets up an agent to answer routine parent questions about bus routes needs to decide, ahead of time, what happens when a parent asks about a custody dispute or a special education plan. The answer should be that the agent hands the message to a named person and says nothing else.
If you can't say what an automation is not allowed to do, you haven't finished setting it up.
Limits also cover money and permanence. Can it spend anything, even a small subscription upgrade? Can it delete, or only archive? Can it change a record that another team relies on? For each of these, the job description should say yes, no or "only with a person's approval." Leaving it blank means the tool's defaults decide, and those defaults were written by a vendor who has never seen your workflow.
Probation, reviews and a last day.
A new automation should start the way a new hire does, with supervision. For the first few weeks, have the manager read a sample of what it produced every few days. They are looking for the odd case: the invoice it filed under the wrong vendor, the reply that was technically correct and still too blunt. Each one becomes a new limit or a clearer purpose on the card.
After probation, the review settles into a rhythm. Quarterly is enough for most automations; monthly makes sense for anything that speaks to clients or touches money. A review asks whether the job still exists, whether the output is still good and whether the automation has picked up access it no longer needs. Someone grants a wider folder to fix one problem and never narrows it again.
Every job description should also say how the automation ends. Write down the off switch, meaning where it lives and who can use it, so that turning it off takes a minute and not an afternoon of searching through settings. When a process changes or the manager leaves, the automation either gets a new manager and an updated card, or it gets switched off that week.
Who writes it, and when.
The person who asks for the automation should write the first draft, before anything is built, because writing the card first forces the conversation a team should have anyway: what problem are we solving, who will watch it, and what would make us turn it off? We often see teams discover at this step that the real problem was a broken handoff between two people, and that a shared checklist fixes it without any automation.
Keep the cards in one place everyone can find, such as a shared folder or a page in whatever system the team already uses. A professional firm with six automations doesn't need software for this. It needs six short documents and a calendar reminder.
The automation job card
Fill one in before you build, and update it at each review.
- Name: what the team calls it.
- Purpose: one sentence. What it does and why that job exists.
- Manager: the one person who answers for its output. Backup: who covers when they're out.
- Trigger: what starts it (a new email, a form submission, a time of day).
- May read: inboxes, folders, records and calendars it can see.
- May change: systems and records it can write to, and whether it can delete.
- May send: anything that leaves the organization, and to whom.
- Needs approval for: the actions a person signs off on first, such as spending, deleting or contacting a client about anything sensitive.
- Hands off when: the situations where it stops and passes the work to a named person.
- Probation: start date, end date and how often the manager samples its output until then.
- Next review: a date on the manager's calendar, not a hope.
- Off switch: where it lives, who can use it and how long it takes.
