A small product can become difficult to operate while its infrastructure remains inexpensive. The hidden pressure is often the conversation queue: access questions, unclear outputs, missing records, or requests that fall outside the advertised task. Before adding an AI support layer, find out what is creating that work and which parts require a person’s judgment.
Google’s SRE discussion of toil distinguishes repeated operational work from engineering work that leaves a lasting improvement. That distinction is useful for an independent builder, although a large organization’s staffing targets should not be copied into a solo business. A repeated password question, a confusing screen, and a novel privacy complaint need different responses.
Observe one bounded operating period
Choose a pilot period and a support window that you can actually staff. Tell participants when a reply can be expected and how urgent problems are handled. Avoid a round-the-clock promise unless someone is responsible for keeping it. The purpose of this observation is to understand the work required by the current offer.
A simple private ledger can record the issue category, arrival channel, first response, resolution, active handling time, and whether the person confirmed the outcome. Keep sensitive message bodies out of a broadly shared spreadsheet. Separate elapsed waiting from hands-on work: both matter, but they explain different problems.
Turn the queue into product questions
- Group repeated issues by their underlying cause. Several differently worded questions may point to the same unclear instruction.
- Mark cases that require account access, deletion decisions, security judgment, or a change to a customer record. Retain a human owner for those decisions.
- Choose one improvement, such as a clearer status message, a recoverable error, or a short help page. Write the result you expect before shipping it.
- Observe the same issue category during the next comparable period. Keep new acquisition campaigns or product changes in the record so a different user mix does not look like an improvement.
The GOV.UK support guide connects enquiry volumes, handling times, service levels, and feedback-driven improvement. Adapt that planning logic to the pilot. A founder’s chosen response target should follow their actual capacity and the consequences of delay.
Automate a well-understood piece
Once the process is clear, a low-risk experiment might draft a reply from an approved help page while a person checks and sends it. Preserve the source reference and make escalation easy. Measure the time spent checking, correcting, and dealing with a wrong suggestion. A longer automated conversation is not evidence that a problem was solved.
Keep the baseline available while testing the change. If an assisted reply cannot explain its basis, asks for a secret unnecessarily, or proposes an action beyond the operator’s authority, defer it for human handling. Do not let a support trial silently gain permission to reset accounts, delete data, issue refunds, or contact people elsewhere.
Use the operating result to limit the offer
Pause expansion when unresolved work repeatedly exceeds the staffed window or the same failure returns after the proposed fix. Narrowing the supported use case can be a responsible outcome. Continue when you can describe both the customer task and the work needed to keep it usable. This process yields a support record for your pilot, rather than an assumed margin or a claim that automation has removed the need for support.