Customer support when the product is free

The most persistent myth about giving software away is that free means nobody can complain. Run a free product for a month and the inbox will correct you. People email about browsers, about file formats, about features that exist, about features that will never exist, and occasionally about their disappointment in you personally. They are not wrong to write. The moment you published a URL and invited the world to rely on your tool, you created expectations — and expectations, not invoices, are what generate support.

What free changes is the economics underneath the duty. A paid product can fund a support team out of margin; a free tool supported by ads earns cents per visitor, which means a single fifteen-minute email exchange can erase the revenue of hundreds of users. Handled naively, support becomes the reason a free product dies — not server bills, not competition, but a solo operator drowning in a channel that costs more per interaction than any user generates. Handled deliberately, it shrinks to a manageable hour or two a week that doubles as the best product research you have.

This post is the deliberate version, drawn from years of supporting a portfolio of free browser tools: how to set expectations so most tickets never get written, how to build the help-page-first funnel that absorbs the rest, what to do with the handful of message types that make up nearly all volume, when and how to say no, and how to turn the residue into a roadmap. The paid-product version of this playbook is at Customer support that doesn't eat your whole week; this is the edition for when there is no invoice anywhere in sight.

Start with what does not change. A user facing a broken export at midnight does not experience your pricing model; they experience a tool that failed them. Bugs deserve fixes, misleading UI deserves correction, and a person who took the time to write deserves an answer that respects the time. Free is not a licence for contempt, and the operators who treat it as one discover that reputation is priced in the same currency whether the product costs money or not.

What does change is the shape of the obligation. A paying customer has bought a slice of your future attention; that is part of the price. A free user has been offered the tool as-is, and the honest framing — to yourself first, then in your published expectations — is that support is best-effort, asynchronous, and bounded. You are not running a service desk with response-time targets; you are a builder who reads the inbox and fixes real problems on a schedule the economics can survive. Most users, told this plainly, find it completely fair. The ones who do not were never going to be satisfiable at any price they were willing to pay, including zero.

The strategic consequence: for a free product, prevention is worth roughly ten times reaction. When each interaction costs more than the user will ever generate, the highest-leverage support work happens before the message is sent — in the interface, in the copy, in the docs. Every confusing label you fix and every error message you make self-explanatory deletes a category of future email. I now treat every repeated question as a defect report against either the product or its documentation, and the inbox has been shrinking ever since.

Expectation-setting starts on the product page, not in the reply. Somewhere visible — ours lives in the footer and on the contact page — say what the deal is: the tool is free, support is best-effort by email, and answers typically arrive within a few days. Three plain sentences. The point is not legal cover; it is that anger at slow support is almost always anger at violated expectations, and expectations you never stated are being invented for you, usually by analogy to whatever paid product the user dealt with last.

The same principle governs what you promise implicitly. A live-chat widget promises a live human; if there is no live human, the widget is a lie with a UI, and its unanswered messages manufacture more resentment than having no widget at all. The channel menu for a solo-supported free product should be short and honest: a help page, a contact form or address, and nothing that performs a responsiveness you cannot deliver. One good asynchronous channel beats four abandoned ones.

There is a quieter expectation lever that took me longer to learn: publish what the product does not do. A visible “limitations” or “what this tool is not for” section reads like confidence, not weakness, and it intercepts entire categories of mail — the wrong-use-case question, the missing-integration question, the why-no-mobile-app question — before they are typed. Users forgive a boundary they were told about and resent the one they discovered mid-task. Saying no in the docs is infinitely cheaper than saying it one inbox at a time.

The structural answer to support volume is a funnel that puts self-service in front of the inbox, in that order, on purpose. Research on self-service support has said the same thing for years: most users prefer solving a problem themselves and contact a human only when the self-serve path fails them. Your job is to make the self-serve path genuinely good and to arrange the site so it is encountered first — not as a maze that hides the contact address, but as a shortcut that is usually faster than writing to you.

Ours works in three layers. The docs at Documentation cover every tool with task-oriented pages — how to do the thing, not a tour of the menus — because users arrive with a task, not curiosity about your feature taxonomy. Under that sit walkthroughs like How to remove a background from an image with NSS Background Remover for the flows where seeing beats reading. The FAQ layer catches the questions that recur regardless of documentation quality. Only then comes the contact form — reachable from every help page, so nobody feels trapped in a deflection loop, but positioned after the content that answers most questions faster than I could.

Two details make the funnel honest instead of hostile. First, the help content has to be maintained like product code: when a ticket reveals a missing or wrong page, fixing the page is part of closing the ticket. Second, measure the right thing. The goal is not zero contact — some questions genuinely need a human, and those are often the most valuable messages you get. The goal is that no user ever writes to you about something a findable page already answered. When that number approaches zero, the funnel is doing its work.

After enough years, you notice the inbox is not infinite variety; it is a small number of patterns wearing different subject lines. For a free browser tool, nearly everything falls into five buckets. The environment ticket: it does not work, and the cause is a browser version, an extension, a corporate network, or a device constraint. The file ticket: an input the tool does not accept or an output that surprised someone. The where-is ticket: a feature that exists but was not found. The wish ticket: a feature that does not exist, requested politely or otherwise. And the suspicion ticket: what is the catch, where does my data go, how is this free — which for our tools has a genuinely pleasant answer, covered publicly at Free forever and still funded: how ad-supported tools actually work.

Pattern recognition changes how you reply. For each bucket I keep a saved response that does three things: answers the common core in two or three sentences, links the relevant help page, and asks the one diagnostic question that matters if the common core does not fit. Saved, not automated — every reply gets a human read and a personal first line, because the recipient of a canned answer can always tell, and the whole trust position of a free tool rests on feeling like it is made by a person. The craft of keeping automation invisible is its own topic, covered in Support automation that stays human: macros, AI drafts, and escalation paths.

The discipline that makes the buckets useful is tagging. Every message gets a one-word label in the ticket subject or a spreadsheet — environment, file, where-is, wish, suspicion — plus the specific theme. Thirty seconds per message, and at the end of a month you have a frequency table instead of a vibe. That table is where the roadmap section of this post comes from, and it is also how you catch a real regression early: three environment tickets naming the same browser in one week is monitoring, delivered free.

A free product survives on the operator’s ability to decline things. The requests are usually reasonable on their own terms — an export format one profession needs, an integration with one workplace’s stack, a bulk mode for one power user’s job. What makes them declinable is arithmetic: each yes is maintenance forever, and a free tool’s margin funds exactly none of it unless the feature serves the broad middle of users. The filter I apply is blunt: would this help a meaningful fraction of everyone, or spectacularly help three people? The second category gets a no, however nicely the three people asked.

The craft is in the delivery. A good no is prompt, plain, and unhedged: thank them genuinely, say clearly that it is not planned, give the honest one-sentence reason — usually scope, sometimes privacy architecture, occasionally just focus — and, when one exists, point at another tool that does the job. What a good no never does is fake a maybe. “I’ll add it to the list” feels kind in the moment and manufactures a resentful follow-up in three months; the person you deflected politely has been converted into a person you misled politely. Help Scout’s writing on declining requests makes the same point from the paid side: customers handle no far better than they handle drift.

Some nos deserve to be promoted into policy. When the same request keeps arriving and keeps deserving the same refusal, write the reasoning once — a docs note or a short post — and let every future reply link it. We have done this for our most persistent themes, and it transforms the interaction: instead of a personal rejection, the requester gets a considered position that was clearly not invented to brush them off. Refusing by architecture rather than by inbox is one of the quiet superpowers of writing things down.

Everything above treats tickets as cost; this section is where they become revenue in disguise. A free product has no sales calls, no churn interviews, and usually no analytics deep enough to explain why — which means the inbox is very nearly the only place users tell you, unprompted and in their own words, what the product failed to do. Deleting a ticket after answering it is discarding paid-for research. The tags from the frequency table are the raw material; the monthly read of that table is the research meeting.

The translation rule I use: frequency times severity, with the correction that inbox frequency undercounts silent sufferers. One confused email usually means dozens hit the same wall and left, because writing to a free tool’s support address is high-effort behavior for a low-stakes product; treat each message as the visible tip of a larger cohort. A theme that is both frequent and blocking goes to the top of the fix list. A frequent but mild theme usually indicates a docs or labeling fix, which is cheaper than code and often more effective. A rare but catastrophic theme gets fixed out of self-respect.

Close the loop where you can, because it compounds. When a fix ships that traces back to tickets, a two-line email to the people who reported it — this is fixed, thank you for flagging it — costs five minutes and creates the most loyal users a free product can have. Several of our best recurring evangelists started as complaint emails. The machinery for turning themes into an ordered build list without a product manager is laid out in From scattered feedback to a roadmap, without a PM; the support inbox is simply that system’s best input feed.

The system above sounds like a lot; in steady state it runs in about an hour a week, plus real fixes. The trick is batching. Except for a genuine outage, support email does not deserve real-time attention, and answering on arrival trains senders to expect chat-speed responses you never promised. I process the queue twice a week in fixed sittings: read everything once, answer the quick ones immediately from saved responses, tag everything, and put anything requiring actual work — a bug hunt, a docs page — on the task list where it competes with everything else on merit.

A monthly half-hour sits on top: read the tag table, pick at most one theme to eliminate at the source, and check the funnel numbers — contact volume against traffic, and how much of the volume was answerable by existing pages. That last number is the honest KPI of the whole apparatus. When it rises, the docs have drifted from the product or the funnel has a routing problem; when it falls, prevention is winning and the remaining tickets are the interesting kind.

The last component is a boundary, stated here because nobody else will state it for you: a free product does not entitle anyone to your evening, and an abusive message closes the conversation — answer the civil version if it ever arrives, delete the rest without ceremony. Guarding the operator is not a footnote to sustainable support; for a product whose entire support department is one person’s remaining patience, it is the load-bearing wall. Protect it, and the free product keeps its best feature: an actual human, reachable, on the other end.