The first pilot goes out, and a week later a customer emails a founder at 7am. The founder forwards it to an engineer. The engineer fixes it, replies, and loses the morning. That works for the first customer. By the fifth, the engineers are running support, which wasn't part of anyone's plan.
I've built support operations from both ends. At Uber, investigations started as part of one role and grew into a 130-person program across two sites. At Boston Dynamics, I led the rebuild of support.bostondynamics.com, where the products are robots with hardware revisions. The first steps were the same both times.
Decide who a customer contacts
One address or one form, written into the pilot agreement. When a unit is down, the customer shouldn't have to guess which founder to text. Behind that address, one person owns the first reply each day, even if the job rotates through the engineers.
Write down what urgent means
A robot that won't power on and a typo on the dashboard are different problems. Agree on a few levels, what each one means for the customer, and how fast each gets a reply. Put it in the pilot agreement too, so the customer knows what to expect before the first ticket. At Uber, better analytics and a redesigned escalation process cut time-to-solve on critical security escalations by half.
Keep the answers where the next person can find them
Every fixed issue is an answer someone will need again, usually at a worse hour. The support.bostondynamics.com rebuild integrated Salesforce, Jira and Paligo so cases, engineering tickets and published articles lived in connected systems. At five customers, a shared doc and a tag on each ticket do the same job. Start the habit while the volume is small.
Count the tickets
A weekly count by customer and by type shows which part of the product is costing engineering time, and when support needs a person of its own. Without the count, the hire tends to happen after the engineers are already behind on the roadmap.