Tech Spotlight:
What Client Service Actually Looks Like | Finworks

Plenty of companies can win a new client. Far fewer keep one for fourteen years. So we sat down with four experts who work with clients every day — Brian Diboll, Head of Account Management, Marc Hoogstad, Head of Product Management, Darren Goodman, Senior Support Manager,  and Vladan Dugarić, DevOps Engineer to talk honestly about what client service actually looks like at Finworks: the wins, the pressure, and the moments that didn't go to plan. 

Darren: We're very quick reactively, but we're also knowledgeable proactively. If something comes in, we're on it, and we keep the client updated. We're also good at thinking ahead of what they might need before they ask.  A good recent example is the work we did for one of our government clients, where we identified a better way to serve them and brought it to them ourselves, rather than waiting to be asked. 

Vladan: Owning up to our errors, even though that might seem counterproductive at first, actually increases the client's trust in us. If an issue is on us, we don't try to hide it. We say "it was us," and then we work on correcting it.

Brian: It's also about relationship building, the core foundation of good service. I like to think about a day in the life of the customer: what their challenges are, what they're dealing with day to day. We deliver above and beyond because we've built that relationship. We don't just stick to the contract all the time.

Can you share a moment when your team went above and beyond?

Marc: One that comes to mind is the search delivery for a government client over Christmas, a tight, stressful deadline, but we hit it, and it got seen by leadership on their side. It's now become a core part of their service.

Darren:  I'd also point to a release for one of our long-standing government clients. It was a go-live on a Sunday, and we hit a serious sticking point that could have panicked people or forced us to pull the go-live entirely. Instead, the team jumped on a call, took their own time to work through it, and delayed the go-live by three hours rather than let it fail. It didn't fail, and that was hugely appreciated by the client. 

Vladan:  We normally try not to call in backup crews for weekend or night deployments unless it's critical. But when it is, we do. Every time, we found and fixed the issue rather than rolling back to the old system. That's why our deployment windows extend to midnight, so we can overrun by a few hours rather than revert. 

What's one of the biggest service delivery challenges you've faced recently, and how did you solve it? 

Vladan: The V5 migration was a major one. It introduced new architecture, including infrastructure changes that come with some unavoidable downtime, something you can't simply impose on a government client, especially during sensitive periods when approvals tighten further. Every time we detected a conflict between the new architecture and what the client's SLA expected, we worked to find a solution acceptable to both sides.

Government approval processes are another recurring challenge. With one client, we don't control the domain infrastructure. Government-controlled systems have to authorise changes, and that process can take weeks. We've had to explain clearly why a delay on their end will delay their own go-live plan, so they escalate internally and get it resolved.

Has something ever gone wrong with a client? What did you learn?

Vladan: A few years ago, while troubleshooting an unrelated issue, I discovered that backups for one of our systems weren't actually completing. A legacy tool had silently stopped working after a cloud provider deprecated an old API it relied on. There was no data loss, but it could easily have become one. I ended the meeting I was in immediately, this had to be dealt with there and then, and spent the next few days fixing it across every environment. Afterward, I added a backup-verification check into our automated morning checks, so this specific failure is now caught automatically going forward.

Darren: That automation means someone like me, who isn't as technical as Vladan, can run the daily check now, and it means we're looking at what's changed, rather than getting lost in manually assembling the information.

How do you prioritise client needs when things get busy?

Darren: We have a priority system built into how requests are raised: P1, P2, P3. With newer clients, we make sure to explain, supportively, why something they've flagged at one priority is actually another, and over time they get into the rhythm of raising things correctly. The hardest moment is when everyone has a critical issue at the same time, that's when you have to work out the actual pecking order.

It's difficult to promise a fix by a specific time, but we can always tell a client we're looking at it, or when we'll next look at it. One of the most useful tools is getting a workaround in place, that buys time and takes the pressure off a specific issue, so we can shift focus to whatever else needs attention, always with the client's agreement.

What's something our platform allows you to do for clients that differs from other platforms?

Brian: We're very agile in how we deliver. I was genuinely surprised, coming into this business, at how much faster we turn things around than companies I've worked at previously. A lot of companies just use ticket systems. We're happy to jump on a call and go into detail. You're talking to a person, not a ticket queue, and that goes a long way to build trust.

Vladan: When a client gives us a very detailed spec for a feature, we'll often propose a better or more maintainable alternative, even if it's more work for us, rather than just building exactly what was asked. If they push back and want it their way, we do it their way, but we always offer the better option first.

Marc: There's real value in the service beyond just delivering it, because we know our clients' processes so well, from the relationship we've built.

Why do clients choose Finworks, and stay for years?

Brian: It comes back to trust and honesty, and the fact that clients can see we have the knowledge to handle complex challenges. What's really hard is getting a customer to choose Finworks in the first place, but once they're in, they stay. One of our government clients has been with us for 14 years. Another government department, 3 years. A client in aerospace, roughly 12. Clients become reluctant to move away, partly because of the depth of customisation we've built for them over time.

Darren: The real question is what keeps a client here once they've chosen us. It's the product, but it's also the people, and the way we work.

Marc: I'd add that we facilitate change without disrupting their operations. One government client's search service now publishes reports in far more formats, at much higher quality, because the underlying system has evolved with them. I don't think another provider could have delivered that same evolution without disruption.

Brian: Empathy. Knowledge. Responsiveness.

Vladan: Dependability, or reliability. Responsiveness. Transparency.

Darren: Efficiency. Collaborative. Supportive.