Operations work shows up before anyone is hired to do it. The first enterprise pilot sends support tickets to the engineers who built the product, and the first contracts land in a founder's inbox on five different sets of terms. Much of it can wait. The pieces that can't depend on the stage you're at.
Before the first customer
I'd set up four things, and all of them fit in tools you already pay for.
- A shared inbox for customer questions, so they stop arriving in a founder's personal email.
- One folder for every signed agreement.
- A written list of what each pilot customer was promised.
- Books that keep their history when something changes.
The rest can wait for the first paying customer.
When the first enterprise pilots start
This is when support starts landing on engineers. A support site with the manuals and known issues gives customers somewhere to look before they write in. Each pilot customer will want a weekly report, and building it once from the data the product already records costs less than rebuilding it by hand every Friday.
While there are only a few contracts, put each one's terms and billing in one place, because the renewal that slips is the one whose terms live in an inbox. Then write down onboarding, so a new customer gets through setup without a founder on the call.
Before the first operations hire
Around the Series A, someone joins to own operations, whether that's a head of operations or a new President or COO. Their first week goes better if each process is written down and the tools under it are wired together. The numbers they'll be asked for in that week should already exist, so they start from a system they can change.
Where an AI agent fits
Once a process is written down, an agent can take the part that repeats. It can answer the support questions your documentation already covers and hand the rest to a person with the history attached. It can also draft the pilot report from what the product recorded that week, for someone on your team to check and send. Test each agent on your own tickets and reports before you switch it on.
The questions an agent can't answer are useful too. At Uber, R2D2 was an internal Slackbot that a support agent built on the knowledge base I owned. It answered about 85% of support agents' questions, and each one it missed showed me where the knowledge base had a gap.