07 - Customer support solo: tooling automation

Support is the cost you had not budgeted for

With the first customers come the first questions, and each one interrupts the work you were focused on. On your own you can afford neither to ignore them nor to answer all of them at once. It holds up with three habits: a single entry point for all requests, written rules for deciding in what order to reply, and template replies for the questions that repeat. This article shows them with a triage program that was really run; it does not cite paid support providers or artificial intelligence tools, because to get started they are not needed.

A single entry point

Requests arrive from email, social media, direct messages and comments. If you watch them in five places, you will miss some. The most useful rule is to choose one public support address and say in the other places "write to me there". To begin with, a dedicated mailbox is enough, not your personal one, with a filter that applies a label to the messages.

When messages grow, a customer support system helps keep a history per customer and share the work. Chatwoot is an option you can host yourself: the repository's license file states that the code outside the enterprise/ folder is under the MIT license, while the content of that folder has its own license. I did not install or try it, so I cannot tell you how much memory it needs or how much maintenance work it brings.

The trade-off is clear even without trying it: hosting the system means one more service to update, protect and include in the backups, in exchange for data that stays on a server of yours. An external service takes that work off you and moves customers' data to a third party, which you will have to name in the privacy notice. For a product with a few dozen customers, the dedicated mailbox is almost always enough.

Triage rules you can read and correct

Triage decides the order, not the reply. It serves to prevent a feature request, which can wait three days, from coming before a customer who cannot log in or who has asked for an invoice. I chose explicit rules, with no models, for two reasons: they are predictable and you can explain them to a customer, and if they get it wrong you understand at once why.

The listing below defines the rules as an ordered list of triples (category, keywords, maximum hours for the reply). The function classifica lowercases the text and returns the first rule that matches: the order is therefore a priority decision. The first message contains both "password" and "not working", that is, it matches two rules, and "access" wins because it comes first. The targets in hours are your own choice, not a regulation. At the end the program computes the median of the first-reply times with statistics.median.

# Triage of support requests with explicit rules (no model, no network).
# The messages are invented for the example. The response targets are YOUR CHOICES.
import statistics

# Order matters: the first matching rule wins, so the most urgent come first.
REGOLE = [
    ("access",    ("password", "can't log in", "login"),           4),   # hours within which to reply
    ("payment",   ("refund", "invoice", "charge", "receipt"),       4),
    ("error",     ("error", "not working", "freezes"),             24),
    ("request",   ("i would like", "could you add", "feature"),    72),
]

def classifica(testo: str):
    minuscolo = testo.lower()
    for categoria, parole, ore in REGOLE:
        if any(p in minuscolo for p in parole):
            return categoria, ore
    return "other", 48

messaggi = [
    "I can't log in, the password is not working",   # two rules match: "access" wins
    "I need last month's invoice",
    "The app freezes when I upload a large file",
    "Could you add CSV export?",
    "Hello, thanks for the service",
]
for m in messaggi:
    categoria, ore = classifica(m)
    print(f"{categoria:<9} within {ore:>2} h <- {m}")

# Hours elapsed from receipt to first reply, for the week's requests
prime_risposte = [1.5, 3.0, 26.0, 2.0, 70.0, 0.5, 5.0]
print("median:", statistics.median(prime_risposte), "hours | maximum:", max(prime_risposte), "hours")

# Output:
# access    within  4 h <- I can't log in, the password is not working
# payment   within  4 h <- I need last month's invoice
# error     within 24 h <- The app freezes when I upload a large file
# request   within 72 h <- Could you add CSV export?
# other     within 48 h <- Hello, thanks for the service
# median: 3.0 hours | maximum: 70.0 hours

From the output you learn two things. First, an unclassified message ends up in "other" with 48 hours, and is not lost: thank-you notes do not require urgency but deserve a reply. Second, the median is 3 hours while the maximum is 70: the median describes the typical case, the maximum the customer who waited longest, and a service is also judged on the latter. If the maximum far exceeds your target, a request has been forgotten. The limit of keywords is that they do not understand context: "no error, thanks" contains "error". Reread the messages that ended up in "other" every week and add the words that are missing.

Template replies: what to ask, what to promise

A template reply is not a cold form: it is the best reply you have written to that question, reused. The most valuable part is not the greeting but the request for the missing information, because it avoids the back-and-forth of messages.

• Access: the address they registered with, what they see when they try, from which device.
• Error: the steps to reproduce it, the exact message, the date and time.
• Payment: the address used to pay and the date of the charge, never the full card details.
• Request: the problem they want to solve, before the solution they propose.

The four categories ask for different things because problems are solved with different information. The last is the most underrated: asking for the problem before the solution saves you from building a feature that solves the wrong thing. One rule holds for all of them: never ask for passwords or full payment details, and write that in the template reply too.

Customer data, refunds and breaches

A support message contains personal data, and Regulation (EU) 2016/679 (the GDPR) treats it like any other data. Article 13 provides that you inform the data subject, at the time when the data are obtained, of who the controller is, of the purposes and of the legal basis; the site's privacy notice must therefore say that support emails are kept and why. Article 33 provides that, in case of a personal data breach, you notify the supervisory authority without undue delay and, where feasible, not later than 72 hours after having become aware of it, unless the breach is unlikely to result in a risk.

For refunds the reference is the Italian Consumer Code (Codice del consumo, legislative decree 206/2005, art. 52): the consumer has fourteen days to withdraw from a distance contract, subject to the exceptions of art. 59. How long to keep support messages is a choice of yours to write down and respect: a defined period, declared in the notice. The period suited to your case is decided with a consultant, not here. How to set up payments and checkout you find in the article on Stripe.

When to stop doing it alone

The signal that support is wearing you down is measurable: the time you give it each week, noted for a month. If it exceeds the share you decided to devote to it (your own choice), you have three routes: improve the product or the documentation to eliminate repeated questions, raise the price to make the time sustainable, or delegate. Delegating is the last, because it costs and requires teaching what you know. Repeated questions are the hidden treasure: each one is a documentation page that is missing. The content strategy can start right from there, and the pre-mortem helps you know beforehand where they will weigh most.

Frequently asked questions

Do I need a support system from day one?

No. A dedicated mailbox, a filter and a file with template replies are enough as long as requests are few. Move to a more structured system when you can no longer remember who wrote what.

How quickly must I reply?

There is no time valid for everyone: it depends on the product and on what you promise. Write down your target, for example four hours for access and payments, and measure it with the median and the maximum as in the example. If you promise the time publicly, keep it.

Can I use artificial intelligence to reply?

In this article no, and I do not discuss it: I have no measurements to show you. If one day you add it, first ask where customers' texts go, because they are personal data and must be named in the notice.

What you can do now

You can set a single entry for requests, write ordered triage rules and verify them with a program, prepare template replies that ask for the right information, and measure times with median and maximum. You also know which obligations touch customers' messages: the notice, breach notification and withdrawal terms. The rest of the path goes back to the infrastructure, where the backups must also live, and to the numbers of small projects.

For the picture of the fixed costs that support must stay under control of, reread the break-even point in the first article.