The AI-Powered Manager: How to Automate Your Own Job

By Robert Hajdu, Country Manager at Joom Marketplace

The Expanding Scope of a Country Manager

I joined Joom four and a half years ago to manage the Hungarian market as a Country Manager. My job was straightforward: localizing the website and the app, finding local bloggers, managing collaborations with influencers, doing translations, and setting up customer support for the region. Country managers were the people who knew the local culture and could advise on marketing strategy and tone of voice.

Over time, our internal structure changed. The team of eight European country managers shrank to just one, and I ended up overseeing operations for most of the European Union and English-speaking countries overseas. I quickly realized that without automation, I simply wouldn’t be able to handle the workload.

I still have the title of “Country Manager”, but the reality of the job is now closer to an “Automation Manager”. When you are drowning in operational tasks without a dedicated development team, your only way out is to automate your own job. This is the story of how I became an AI-powered manager — building some much-needed new internal tools from scratch.

When Standard Automation is No Longer Enough

We had automation long before the AI hype. Our former dedicated developer team built systems for estimating delivery times, sending tracking links, and auto-refunding items if there were quality issues. But our automation was based on a mix of rigid rules and financial considerations — usually, straightforward requests went through automatically, while more complex cases were checked manually by an agent.

Then our catalog shifted. We started aggressively selling apparel, sneakers, and expensive electronics. You can’t auto-refund a €2,000 scooter based on a simple price rule. These cases require technical knowledge, deeper insight, and real brain power from our support agents. The old rules became irrelevant, and we needed a way to free up our team from repetitive tasks so they could focus entirely on these high-value tickets.

However, we were limited by our internal CRM. Originally, it was envisioned not just as an internal tool, but as a standalone product we planned to sell on the market. But as company priorities shifted, those plans were shelved, and there were no longer any dedicated resources solely dealing with the platform.

If we wanted to speed up our agents’ workflow, I had to figure out how to build these tools myself. To be clear about the scope: I don’t modify the CRM’s core functionality, refund rules, or customer-facing features — those major developments are handled by a dedicated engineering team. My focus is strictly on building external automations and agent-facing extensions that surface relevant information and help our team work more efficiently.

Learning to Code on the Way to Work

I started using ChatGPT when it first came out. It was a gradual progression: asking basic questions, writing Google formulas, then moving to Apps Script, JavaScript, and eventually Python.

Around six months ago, my colleague suggested trying Cursor to build actual features for Babylone, our internal CRM built specifically for support. I started using AI as a brainstorming partner. While walking my daughter to school, or walking home, I would talk to ChatGPT on my phone. I asked what was possible, what the risks were, and how to eliminate them. By the end of my walk, I would ask it to summarize everything so it was ready on my computer by the time I returned to my desk.

I asked Cursor to explain our existing internal CRM codebase. I read the code, asked what changing it would require, learned how GitHub, pull/push requests, and developer documentation worked. We broke projects into small parts, tested each part, and then pulled them together.

The workflow became surprisingly rigorous for a non-technical manager. Today, my code goes through multiple review stages: a local review on my machine, automated GitHub code reviews, and then I tag a real Joom front-end or back-end developer for a human review. Only after it passes our testing environments does it go to production.

What We Built and the Hours We Saved

We focused on eliminating manual routines. First, we looked at how we handled data. We managed to automate a manual reporting task end-to-end. Instead of managers manually downloading data from Holistics, transforming it, and formatting it, a script now does it all and publishes the final report to Slack. A biweekly report that used to take eight managers up to 24 hours a month is now fully automated and runs in the background. Another daily supervisory task that took 15 minutes a day was reduced to zero, saving us up to 2 hours every week.

Next, we looked at agent workflows. Previously, if agents needed to consult another team, they had to manually gather data from our internal CRM, format it nicely in a Slack message, and send it to the relevant channel. Using Cursor, I built a frontend and backend for a Chrome extension that automatically pulls this data together. Agents just add their comments and choose a channel with one click.

To make it user-friendly, I registered a Google Developer account so it could be distributed as an official Chrome extension for our team. That single tool saves from 27 to 40 hours of work per week. It is basically the equivalent of one full-time employee.

But we didn’t use this to cut headcount. Those saved hours were redirected to handling the complex €2,000 scooter tickets and branded apparel inquiries that actually require human judgment.

Learning to Fail Safely

When non-technical people start writing code, things will eventually break.

My team works with customer requests, and they asked for a feature: a placeholder for quick-replies to auto-fill the email used by the user when placing the order. I built it, released it, and the next day InfoSec reached out: “Hey Robert, you have hackers in your team. Some data is being downloaded an awful lot of times.”

It turned out my code downloaded the data in the background every single time a ticket was opened. It wasn’t displayed to anyone, but the unusual download pattern triggered our security alerts.

We fixed the bug immediately and updated our workflow. I recommended adding a check to the code review process for non-technical contributors. InfoSec approved it, and the alerts stopped.

This highlighted an important challenge for the company: how to let non-technical people safely develop code while protecting our systems. It also made me realize the long-term risk of “citizen developers” creating technical debt. If we all build separate coding projects over time, we could easily create a mess. To prevent this, I started writing strict instructions for myself and for the AI models: always check existing mechanisms first, try to reuse them rather than reinventing the wheel, and rigorously explain the reason for any new approach.

Shifting the Work Upward

As we automate more, people worry about losing the personal touch in customer support. But quality depends entirely on what a company prioritizes. AI can be highly effective, or it can be a nuisance.

I recently dealt with a personal banking app where I interacted entirely with an AI bot. It was highly effective. It understood my problem, addressed my concerns perfectly, and most importantly, it knew exactly when it had reached the ceiling of its knowledge and seamlessly transferred me to a human agent. On the flip side, I’ve dealt with another bank’s bot that simply spammed me every five minutes asking, “Is your question still relevant?” while refusing to actually help. That is the difference between good and bad automation.

At Joom, we use AI to shift the workload upward. Automation does the repetitive reporting and data gathering, our agents handle the complex issues that require empathy and intelligence, and non-technical staff write basic code so our actual developers can focus on serious architecture.