A growing product is a lot like a ship taking on water. Each new customer brings not just revenue, but support requests, custom requirements, and maintenance needs. At first, it’s manageable - founders and early employees can bail water fast enough to stay afloat. But success changes everything. More customers mean more requests, more edge cases, more operational overhead. Soon you’re drowning.
This is the story of how we’re navigating the seas of operational complexities.
All hands on deck
In the startup world, Paul Graham’s “do things that don’t scale” is gospel for good reason. Early-stage founders handle everything - from building the product to marketing to customer support. With few customers and low opportunity costs, what should be done is whatever it takes to keep those precious early customers happy.
One of my favorite parts of Paul’s wisdom is the “Manual” section:
Manual
There’s a more extreme variant where you don’t just use your software, but are your software. When you only have a small number of users, you can sometimes get away with doing by hand things that you plan to automate later. This lets you launch faster, and when you do finally automate yourself out of the loop, you’ll know exactly what to build because you’ll have muscle memory from doing it yourself.
When manual components look to the user like software, this technique starts to have aspects of a practical joke. For example, the way Stripe delivered “instant” merchant accounts to its first users was that the founders manually signed them up for traditional merchant accounts behind the scenes.
Some startups could be entirely manual at first. If you can find someone with a problem that needs solving and you can solve it manually, go ahead and do that for as long as you can, and then gradually automate the bottlenecks. It would be a little frightening to be solving users’ problems in a way that wasn’t yet automatic, but less frightening than the far more common case of having something automatic that doesn’t yet solve anyone’s problems.
Complexity is a byproduct of success and automating ourselves out of the loop is needed.
The Rising Tide of Requests
As the volume of features shipped increases, so do the requests for further customization, bug reports and special inquiries. As you attract larger clients, they start needing enterprise capabilities such as reporting. The water gets to your neck. Should we embed a new feature in our product? Should we automate this task? Who should be responsible for resolving the issue?
Build every customer request into the product, and you’ll create a Frankenstein of features plus an unbearable operational nightmare.
Let customers customize everything, and they’ll build their own Frankensteins. They will drown themselves by using your product for things that probably are not impacting their businesses. Your tool becomes a distraction.
Trying to automate everything is also suboptimal. There are opportunity costs in every decision. The boat may stay afloat indefinitely, albeit stuck in deep sea waters, unable to go anywhere.
Throwing Out the Life Ring
At Pilar, our solution started with a Tech Service Desk in Jira. We made an unconventional choice: customer support representatives became the clients, while engineers and product managers served as agents for ticket resolution.
The Problem with Traditional Support
Exposing a help center to the application users and making CS agents the ones responsible for solving issues is the common practice amongst businesses. That’s probably required for B2C companies that offer their solutions to millions of customers, such as utilities providers, airlines and large banks.
This landscape is likely changing with Agentic AI. How many consumers of electricity or airline passengers are fully satisfied with the digital support they receive? They may have their issue resolved, but it does take some time to get from generic FAQs and automated bots to reaching a human being that will then take the necessary steps for actually solving the problem.
This human interaction is needed because usually whatever needs fixing involves coordination with other humans and/or system interaction, something the current widespread support tools are not able to provide. The future of customer support is to provide AI agents with the same capabilities and tools of the best human support agents. This future is an engineered sincerity that has the scalability of present software offerings with the unbeatable quality of human touch.
Our Approach to Customer Support
Although our setup may look awkward, it works in our case. It enables us to understand the true cost of operations while keeping product specialists accountable for the operational burden.
Our clients are real estate agents who prioritize simplicity and efficiency - they don’t want yet another system to learn. They want tools that help them accomplish tasks quickly and effortlessly. What they value most is human interaction: the ability to briefly explain an issue to someone who can understand what they really mean, even when it’s not perfectly articulated. We’ve made a conscious decision as a company to provide top-notch, human-centric service.
Our customer satisfaction metrics validate this strategy. We consistently achieve 70+ NPS score in frequent assessments across key areas: support team interactions, ticket resolutions, and our overall product offering. This is particularly noteworthy in the real estate industry, where professionals are typically demanding and time-sensitive in their needs.
Equally important, this setup hasn’t created friction between teams - quite the opposite. Our Employee Net Promoter Score (eNPS) consistently stays above 70, indicating that both customer support representatives and technical teams are satisfied with their roles and interactions. Perhaps most tellingly, turnover in these teams is zero.
Technical Implementation
Returning to the implementation details, Jira Service Desk proves highly effective once properly configured. The initial setup requires careful attention to three key components:
- Custom Form Fields - to capture all necessary information for each request type
- Request Types - to categorize and route different kinds of support needs
- Automation Rules - to handle ticket distribution and workflow management
While the setup process requires a good amount of work, the resulting system is robust and reliable.
For those interested in implementing a similar Tech Service Desk, feel free to connect with me on LinkedIn.
Once everything is in place, what you get is a Help Center with web and Slack interfaces and a nice Kanban board for ticket progress visualization, which is also available via a Slack channel.
Help Center screenshots
Each item is a Request Type and when clicked shows a Form with Custom Fields. The CS rep fills the form and submits it. The ticket is created in a “Pending” column of the Kanban.
The help center is also available in Slack, where CS reps work on a daily basis for communicating between them and with other employees.
Kanban Board
The ticket lifecycle is pretty straightforward: from pending to in progress, then waiting on customer action or simply done.
Slack-based service desk operations
All tickets are visible on a Slack channel, where engineers and product managers - the service desk agents - can view what needs to be done and update each ticket status.
Reaching calmer waters
With the Service Desk in place, patterns emerged clearly. We began identifying the most frequent requests, the most time-consuming tasks, and operations with the lowest automation costs. When a task hit all three criteria, we had two paths forward: either build it into the product (which we did less frequently) or create an automated solution as a Python script.
We then built a Slack app that we called the “slack bot”. Each Python Script representing a business workflow became a possible “bot action”. CS agents started to use this bot on a daily basis, freeing up further engineering time.
This Slack bot option is particularly powerful. It let us automate business processes without traditional product development overhead - no UI studies, no complex interfaces, just simple, effective automation where needed. The fact that support representatives use Slack as the in-company chat solution helps a lot. They don’t need to login into a new system, learn how to use it, nor keep multiple browser tabs opened.
The screenshot below shows the Slack bot operated by CS agents. Each button is an automated business process.
Surfing the Ultimate Wave
While our Service Desk and Slack bot helped us navigate most operational challenges, some complex operations still threatened to pull us under.
For instance, we couldn’t justify building self-service Reporting into our product, since the requests weren’t frequent enough to be prioritized on our roadmap.
The diversity of customer reporting needs made it impossible to create a one-size-fits-all solution. Each unique request required an engineer’s time to build custom reports, consuming valuable resources that could be better spent elsewhere.
In this post, I explore how we’re shifting from engineering work to an AI-powered approach. Engineers now focus on reviewing AI-generated code rather than writing reports from scratch, dramatically reducing the time and cost per request. A simple report that used to take hours of an engineer time now takes less than 30 minutes if the AI doesn’t get it right in its first attempt. If it does, then the report is generated instantly and the ticket is closed within a couple of minutes.
We’re just catching the first ripples of what’s possible with Agentic AI. As these technologies mature, operational overhead - once an inevitable burden of growth - may become as manageable as riding a wave. The future of operations looks less like struggling to stay afloat and more like enjoying a surf session.