When 5x Growth Breaks Your Operations Team | Nornhill

In the past 18 months, a major client in the high-risk sector has grown quickly, which has really challenged operations. Since September 2023, our Payment Operations team has been handling five times more configuration and maintenance tasks.

If you grow by 10% or 20%, you can just work harder. But when the workload jumps by 500%, working harder is not enough. We have to change how we work. The payments team has reached a point where we can no longer "throw bodies at the problem" but must solve it.

Here’s how we’re moving Product Operations from just reacting to problems to a setup that can grow with us.

Product Operations Teams

To tackle our scaling challenge, we started by looking at the three main parts of our daily operations:

1. Payment Operations (PayOps) is our team of experts for setting up gateways, methods, limits, FX, commissions, MIDs, etc.
2. Monitoring keeps track of our systems using tools like Grafana OnCall and adjusts settings based on success rates.
3. The support team helps end-users by investigating transactions and answering any questions about money movement.

In the past, the Product Team focused on clients and end users, while the three operations teams handled all the complexity. Now, we’re treating these internal teams as key users too.

Delegation as a Strategy

Our Payment Operations team was getting stuck, not due to a lack of skill, but because they didn’t have the right tools or had too many micro tools. They were manually setting up features that merchants wanted to manage on their own. So, we created the Merchant Dashboard.

This is more than just a new interface, it’s a big change in who does what. By adding self-service features, we’re shifting about half of the PayOps work to the client, including configuring payment methods, merchant IDs, routing, and the appearance of the payment widget.

• In 2025: Merchant requests a limit change → Ticket created → PayOps manually updates config → PayOps notifies Merchant.
• In 2026: Merchant logs in → Merchant updates limit → Done.

This 'Configuration as a Service' approach lowers error rates, helps merchants launch faster, and lets our PayOps team focus on more complex work instead of routine tasks. I hope this works out, since it can be tough to convince clients that taking on these tasks themselves is actually a benefit, not a drawback.

Beyond Configuration

Real Product Operations means the software helps take care of itself. We’re bringing this idea to our Monitoring and Support teams too.

For Monitoring, we’re moving past just watching what happens. The payments team built a central dashboard to manage all gateways, payment methods, currencies, and MIDs in one place. Now, the monitoring team can respond to and update clients in minutes, rather than handling each client and project separately. We’re also giving clients a similar interface, so they can react to Grafana metrics right away and switch payment methods by MID or country in real time. Some mature clients are interested in this because they have their own operations teams.

For Support, we connected our product directly to Jira Service Management (JSM). Automating transaction lookups and status updates means support staff spend less time searching for answers and can help users faster. With less routine work, our team has taken on more tasks and is now focusing on fraud prevention. That’s been great. This isn’t AI, it’s just making daily work easier through automation.

Focus in 2026 to make Operations as an Enabler

We’re changing PayOps from just managing configurations to helping the company grow. By giving clients more control and automating the tricky parts of monitoring and support, we make sure our costs don’t rise as fast as we grow. Some projects are already finished, and the results are encouraging. That’s why the Payments Product Team keeps rolling out the Merchant Dashboard and other tools to automate daily work.

One More Challenging Idea

While the Merchant Dashboard helps clients handle more on their own, I’m also rethinking how we manage complexity and planning to move to the so-called 'Hybrid Configuration' model.

I was inspired by Thought Machine's simple and effective 'Smart Contracts' for core banking, and I want to use a similar approach in Payment Operations. Yeah, these guys are far beyond payment hubs, but the way they deal with times more complex products is truly amazing. So, back to our core infrastructure, here is the idea.

• For Merchants, we’ll offer a simple, self-service interface to handle 60-80% of their daily tasks.
• For PayOps, we’re moving from clicking through lots of forms and checkboxes to using Configuration-as-Code. This means PayOps will handle complex setup, like routing, through version-controlled files in YAML or JSON, instead of working through the back office.

Here is just an example of possible config files to better understand what "Configuration-as-Code" is.

# CONFIGURATION: MGM Entertainment (Brazil)
# PROJECT: "The Biggest River"

currency: "BRL"

# 1. PROVIDERS
active_providers:
 - "PagBrasil" # Primary for PIX
 - "EBANX"     # Primary for Cards

# 2. LIMITS & SEGMENTS
# VIPs get higher limits; New users cannot use Credit Cards (Risk)
user_limits:
 new_user:
  max_amount: 500
  allowed_methods: ["PIX", "BOLETO"] # No cards allowed
 vip_user:
  max_amount: 100,000
  allowed_methods: ["PIX", "BOLETO", "CREDIT_CARD"]

# 3. DEFAULT ROUTING
# Automatically manage traffic without waking up an operator
routing_rules:
 - rule: "Performance Failover"
   logic: |
    IF PagBrasil.success_rate < 85%:
    THEN switch_traffic_to "EBANX"

 - rule: "Cost Optimization"
   logic: |
    IF payment_method == "PIX":
    THEN route_to "PagBrasil" (Lower fees)

Will this change really transform PayOps, or will we get stuck halfway? I’ll share more about it later.