n8n 為何要讓自動化團隊走出服務台模式

In the first article of our n8n on n8n series, Romina da Costa, our head of internal AI and automation, explains where the service desk model hits its limit. She also shares the four principles her team now follows to help every team at n8n build and own its automations.

What does success look like for an automation team? Workflows shipped, tickets closed, backlog cleared? TLDR: none of that is actually what makes an automation team successful.

Every centralized automation team solves a real business problem: automating routine tasks, freeing up time, and taking on work that doesn't actually need human judgment. But solving that well is exactly what lets the rest of the organization lean on you to keep solving it, instead of building that capability into how the organization actually functions. You're not fixing the bottleneck. You're shifting it downstream.

This isn't a mistake unique to n8n, and I don't think it's really a mistake at all. Most organizations, especially at the enterprise level, are going to arrive at some version of this same realization. You stand up a centralized automation team. You clear the backlog. You free people from routine work. All of that genuinely works, for a while. What you're left holding afterward is a problem nobody budgeted for: who actually maintains everything you just built, and whether the team that solved the first problem can carry the second one indefinitely.

There's a bigger shift happening underneath this too. Building, workflows, agents, internal tools, is getting radically more accessible to people who aren't engineers. You'd think that makes a central automation team less necessary. I think it makes the job more important, just a different job. The scarce skill stops being "can you build this" and becomes "should this be built, how do you know it worked, which tool actually fits, and who owns it when it breaks." Easier building raises the stakes on judgment. It doesn't remove the need for it.

So here's what I actually think is the job of the Automation team, and why I've spent my first months here trying to change what success looks like for my team.

The automation team was working. But the model had reached its ceiling.

The Automation team was built to solve a real problem, well before I arrived. n8n's teams were drowning in manual work, and nobody was joined-up enough across the org to fix it systematically. So the company hired engineers to build workflows: connect tools, eliminate repetitive tasks, free people up for higher-value work. That was the right call for where the company was at the time, and the team did exactly what it was asked to do, and they did it remarkably well.

By the time I joined earlier this year to lead the function, I found a team whose own success and the company's growth had quietly exposed the limits of the model it was built on. We have somewhere north of 12,000 internal workflows and no team, however good, can build and maintain all of that. If "build more automations" were still the job description, I'd be running the very thing standing between the company and the outcome I was actually hired to accelerate.

That's the trap I'd flag to anyone stepping into a role like mine. It's not a failure of the previous team or the previous model. It's just where this function ends up if you let it run its natural course. That's fine, even expected. At some point, though, it becomes the job of whoever's leading AI and automation to step in and interrupt it, deliberately, before it goes too far. That's especially true if what you're actually trying to build is a highly automated, AI-first organization that's ready for how work is changing.

The reframe: From building automation to building an automation culture.

The question I've been sitting with isn't "how do we build more automations?" It's "how do I build a company where every team can think and act like automation engineers?" They sound similar, but they have completely different repercussions for how we approach the work, and what that work actually looks like.

Under the first question, success looks like throughput. Under the second, it looks like how many teams stop needing us at all. I've spent these early months trying to make that second answer the reality. That means figuring out what it actually takes to earn it: not just changing how my team works, but how we're perceived, and how other teams choose to interact with us in the first place. It sounds like a small shift on paper, but it changes almost everything about how we spend a given week.

In practice, that's turned into four principles.

1. Build the builders, not just the builds

The highest-leverage work my team does isn't the workflow they ship this week. It's the enablement that means a team doesn't need us the next time something similar comes up. That happens at a few different levels.

At the individual level, it looks like one of my engineers spending time this quarter not writing an automation for a stakeholder, but sitting with her while she debugged her own: reviewing why it failed, showing her what to change and why. The workflow got fixed either way. The difference is she won't need us next time.

At the team or department level, it looks like training sessions, reusable workflows other teams can start from instead of building blind, office hours where people bring a real problem and we build alongside them, and a network of technical champions: one person per department who understands their team's processes well enough to describe them clearly, and who owns the tools that team actually uses day to day. They don't need to be engineers. They need to be the person who can tell you why a process works the way it does, which turns out to be the harder skill to find.

Having one champion per department is a real starting point, not the end state. It's also useful in a way that goes beyond enablement: when a department doesn't have an obvious champion yet, that tells us something, both about where to focus next and about what we should actually be hiring for. The honest goal is bigger than one person per team. In an ideal world, most people would be able to act like a champion for their own function. We're not there yet. But we have to start somewhere, and one clear owner per department is a reasonable place to start.

At the company level, it looks like efforts like the AI fluency framework we are creating: shared standards and a common baseline of judgment about responsible AI use that don't depend on any one team to hold up.

From the outside, building for someone and building with them can look identical, especially if all you're counting is workflows shipped. Yet they're completely different jobs. Getting my team, and our stakeholders, to actually understand that difference has been most of my work these first few months.

2. Require a baseline before you build

This one came from a mistake I watched happen in real time. One of our AI agents generated a genuinely impressive result: six figures in the pipeline in a month. It felt like an obvious win, until I asked the question that actually mattered. Compared to what?

It wasn't that we had nothing to compare against. We had real numbers on what our human SDRs produced. The complication was that the comparison itself wasn't clean. The agent runs around the clock and never takes a break, and by that point our human SDRs were mostly handling the harder, escalated work the agent had already filtered out for them. Stacking the agent's raw pipeline number against the human SDRs’ wasn't actually comparing like with like, and figuring out what a fair comparison would even look like took real work.

I've since made it a hard requirement on my team. Before any new automation project starts, we ask the requesting team what today actually looks like: how often the work happens, how long it takes, how many people touch it, what it currently produces, and what would actually count as a meaningful improvement, even when the answers are only guesses. A guess is still more useful than nothing, and asking the question is often the first time anyone's thought about it at all.

3. Choose the tool for the problem, not the tool you're comfortable with

Once you actually know what you're trying to improve, the next question gets easier to answer: what's the right tool for this? We don't build for building's sake, and oftentimes, we push for a buy decision rather than building ourselves. This is the one that surprises people, given that we are n8n. As a general rule of thumb, if a proven, specific tool has existed on the market for a year or more, it's usually the better call over building internally, and the reasoning goes beyond which option works better today. Building it ourselves means taking on the maintenance burden and the security surface indefinitely, while a dedicated vendor team keeps shipping against their own roadmap while our V1 stops keeping up. A SaaS tool comes with an ongoing cost; building it ourselves just trades that for a different, less visible one: our own team's time, doing maintenance, upkeep and improvements, for as long as the thing exists. The real question isn't only which option works better right now. It's what we actually want to be responsible for maintaining and improving years from now.

The same discipline applies to agents versus workflows. Not every process needs an LLM in the loop. I've seen automation requests land on my team where the actual task was, functionally, "forward this email to James," dressed up as an agent, when a plain email filter would do the job with zero chance of getting it wrong. The discipline isn't avoiding agents. It's refusing to reach for one out of convenience or hype when a simpler, more predictable tool already solves the problem.

4. Make what we build resilient

Every workflow my team ships is a commitment, not a one-off favor. It needs an owner, documentation, error handling, and a plan for what happens when the person who built it moves onto something else, because eventually, they will. A clever automation nobody understands six months later becomes a liability.

This part is still aspirational. We don't have a single documentation standard the whole team follows yet, so one engineer's notes look nothing like another's, and that's a real cost the day someone has to pick up work that isn't theirs. We're working on a shared documentation template now, something every workflow gets measured against, and we're aiming to get it in place in the coming weeks. The harder part won't be writing the standard. It'll be actually enforcing it, making sure every workflow gets documented to the same bar instead of just the ones someone happened to make time for.

Transforming our model to transform the organisation

I don't want my team to be a service desk, a team that takes requests and delivers outputs on demand. I want us to solve the right problems in the right way. Sometimes that means building something. Sometimes it means teaching a team to build it themselves. Sometimes it means telling a stakeholder that what they've described isn't actually an automation problem yet.

That's the intent. We're not fully there. In practice, my team still functions like a service desk more often than I'd like, and the reason isn't really about process. It's that shifting culture is slow, and it's genuinely hard for people across a fast-moving company to find the time to learn how to build and own automations themselves. My team saying no more often doesn't fix that on its own. It takes real buy-in from leadership and from other functions: making AI fluency part of how people are evaluated, setting goals that get specific about how each function uses AI and automation, and building a culture where every team expects to own some of this, not just request it from us. That part isn't mine to solve alone, but it’s one I am working crossfunctionally to influence.

The switch in mandate

None of this makes a central automation team pointless once building gets easier for everyone. It changes when and why we get involved. My team should still own the problems that are complex, risky, or shared across the whole company, the kind of thing you don't want a dozen departments solving a dozen different ways. Everywhere else, our job is building the foundations, standards, and judgment that let other teams build responsibly without our direct involvement.

Giving people the ability to build is becoming the easy part. Every tool, including ours, is making that true faster than most of us expected. The harder part, the part our jobs are evolving into, is building an organization that knows what's worth building, how to build it well, and how to own it once it's built.

Romina da Costa leads Internal AI & Automation at n8n. Since joining, she has been restructuring the function from a workflow-building team into an enablement engine.