Building support at Workbrew

If you run a technical product for long enough, the support inbox becomes one of the most useful sources of information about the product itself. It is where the environments you did not expect show up, where assumptions break down, and where you discover how people are actually using the product. No product manager could predict every variation in device fleets, policies and security tooling used by real organizations, and Workbrew is blessed with very creative customers that push the product in new and exciting directions.

The support conversations we have with customers are therefore not just about fixing individual issues: they are the fastest way to understanding the real challenges that IT admins of MacOS fleets face, and what tools Workbrew gives them to overcome them. Most importantly, they may reveal tools that Workbrew could give them in the future.

Workbrew needed someone that could craft and drive a support organization that could make the most of that challenge, both solving customer issues, but also distilling the requirements and identifying product and documentation opportunities. Enter Petros.

From programming to support#

Petros came to support from engineering, having spent the first twelve years of his career working as a programmer and technical lead. Much of that time involved talking directly with customers about the systems he was building, an experience that shaped how he approaches customer problems.

Petros eventually moved into support full time when he joined GitHub. At the time the company was growing quickly and the support team was expanding along with it. Over the next nine years he worked in technical support and later managed the team, eventually becoming Director of Support Engineering. The role involved helping the organisation handle a rapidly increasing number of users while still keeping support conversations useful and technical.

After GitHub he joined GitBook as Head of Support, where his role transformed again. Instead of working inside an established organisation he was responsible for building the support function itself. That meant deciding how requests should be handled, how the team should communicate with product and engineering, and what kind of information needed to flow between those groups.

Workbrew is earlier in its life than either of those companies were, which is part of what makes the role interesting. At a young company the line between support and product is still fairly thin. When a customer reports a problem, the person investigating it may also be able to help remove the underlying issue entirely.

What support conversations reveal#

In support, customers rarely contact you with neat, isolated questions. Most messages contain several problems at once, mixed together with the context that led up to them. This can result in a frustrating experience for the customer, who feels they have written a detailed message explaining what happened, and who often receives a reply that answers part of it but not all of it. It is rarely intentional, but it happens often enough that people learn to expect it.

Petros tries to avoid that pattern by reading messages carefully before responding. If someone took the time to explain their situation, the least we can do is make sure the reply actually addresses what they wrote. It’s not always possible to provide an answer or solution to every problem right away, but by at least acknowledging each part of the email, the customer knows they are heard and that their queries are being handled.

Keeping conversations moving even when the answer is not immediately clear is something Petros considers a hallmark of good support. Many support issues require some investigation, and in those situations the worst outcome for the customer is usually silence. A short update explaining what is being checked is often enough to reassure someone that their issue has not disappeared into a queue.

Handling support requests#

Support conversations also tend to begin when something has already gone wrong. The customer may be trying to complete a task under time pressure, or they may have encountered behaviour that does not match what they expected. In those situations even routine diagnostic questions can feel frustrating.

Products like Workbrew often require quite a bit of context before an issue becomes clear. Logs, configuration details, and the steps that led to the problem all help narrow down what actually happened. Asking for that information is sometimes unavoidable, but explaining why it matters usually makes the process easier to work through.

Over time those conversations start to reveal patterns. Certain workflows turn out to be confusing. Certain pieces of documentation assume more prior knowledge than they should. Occasionally a feature behaves in a way that made sense when it was implemented but causes problems in real deployments. Those signals are valuable because they point to improvements that benefit everyone using the product.

Fixing the underlying problem#

The best outcome for a support issue is often not the resolution of a single ticket but the removal of the problem entirely. Sometimes that means fixing a bug, or improving documentation so that the next person encountering the same situation can solve it themselves. 

Startups have an advantage here. The distance between a support conversation and a product change is often short. When a pattern appears it is usually possible to bring it directly to engineering or product discussions and adjust the system before it becomes a recurring problem. Support therefore becomes a useful source of product feedback rather than just a queue of requests.

Helping us help you#

Customers can help with this process as well. One of the most common challenges in support is the message that simply says something does not work. It is an understandable starting point, but it leaves a lot of questions unanswered. The most helpful requests usually include a short description of what someone was trying to do, what they expected to happen, and what actually happened instead.

Screenshots, logs, and the steps that led to the issue make it much easier to recreate the situation and understand what went wrong. Even when a problem eventually needs to be escalated to engineering, that context helps us present the issue clearly so it can be investigated quickly.

Workbrew’s customers also come from a wide range of backgrounds. Some of the people contacting us manage large fleets of devices and have spent years working with macOS administration tools. Others are interacting with a Workbrew managed device as part of their normal work and may not think of themselves as technical users at all. Good support means adapting explanations so that each person gets the information they need without unnecessary complexity.

Building support early#

One of the advantages of building support early in a company’s life is that these conversations can influence how the product grows. The goal is not just to respond to problems but to learn from them. Over time that feedback loop tends to produce clearer documentation, better workflows, and fewer surprises for the people using the product.

That process is already underway at Workbrew, and it is one of the areas where Petros’ experience helps the most. Support conversations often reveal where the product needs to become clearer or more resilient. When those signals are fed back into engineering and product work quickly, many of the issues that first appear in the inbox never need to appear there again.