In this episode of Mastering CS: Candid Leader Insights, Irina Cismas sits down with Alex Frunza, Head of Customer Success, Enablement and Support at Otera, a company automating complex enterprise workflows across systems. Alex brings a background in technical and operational roles, and that foundation shapes everything about how he thinks about customer success today.
He shares why CS can never be a siloed function in enterprise environments, what it really means to own outcomes when the work is delivered through partners, how enablement differs depending on what you’re trying to achieve, and what it takes to balance startup speed with enterprise operational discipline.
What You’ll Learn
- How a technical support background shapes the way Alex approaches customer success leadership
- Why CS can’t operate as a standalone function in enterprise automation
- What breaks first when CS is isolated from the rest of the organization
- How to think about ownership and accountability when delivery happens through partners
- What enablement actually means and how its definition changes depending on your goals
- How to balance startup velocity with the slower pace of enterprise decision-making
- What skills will matter most for CS leaders as AI continues to reshape the industry
Key Insights & Takeaways
- Tech support is the original customer obsession. Being at the front line of customer problems early in a career builds a foundation that no amount of buzzwords can replicate. It puts you in genuine service of the customer before you even know what CS is.
- CS is an ambassador role, not a spotlight role. The job is to bring others onto the stage, not to shine yourself. That means building close relationships internally and externally and constantly bridging the two.
- Isolation is visible from day one. When CS is disconnected from internal teams, customers feel it immediately. Trust erodes fast and is very difficult to win back.
- Partner success is a different game. When delivery goes through a partner, you have to understand how that partner is being measured and what success looks like for them too. Everyone in the engagement needs to win.
- Enablement starts with defining what you want to achieve. Whether it’s growing pipeline, consolidating a technical ecosystem, or identifying new use cases, the goal determines the entire approach.
- Enterprise scale is not about headcount. In enterprise CS, scaling means adding the right support roles around the CS function, not just adding more CSMs. One customer can mean ten legal entities and ten times the complexity.
- AI won’t replace experience. Knowing how to use AI tools is not the same as being a strong CS professional. The skills that will matter most are the ones built through real enterprise experience, not two prompts and a well-articulated answer.
Podcast Transcript
Intro
Irina (0:06 – 0:26)
Welcome to Mastering CS – the podcast where we dive into the world of customer success with industry leaders. I’m your host, Irina Cismas and today I’m joined by Alex Frunza, Head of Customer Success, Enablement and Support at Otera, a company automating complex enterprise workflows across systems. Alex, I’m really happy to have you here!
Thanks for joining!
Alex (0:27 – 0:30)
Thank you for inviting me! I’m excited for the conversation.
From Technical Roles to CS Leadership: What Carried Over
Irina (0:31 – 0:44)
You started in technical and operational roles before moving into CS. Looking back, what has the biggest impact on how you lead today?
Alex (0:46 – 2:20)
I think there are a couple of components that definitely shaped the direction in which I went. I can’t really say that at the beginning, when I was starting my career as a tech support engineer, I had this vision of at some point wanting to do customer success. I wasn’t really aware that customer success was even a thing back then.
But I think some of the things that come from having that early customer-facing time is definitely an important element that will shape any professional in this direction. It puts you into that position of truly understanding what is the mission, the goal, and what the company is trying to achieve for its customers.
There are a lot of companies and speakers out there that talk about the voice of the customer, or being there for the customer, being in the service of the customer, customer obsession, buzzwords and so on. Tech support, I think, is the definition of being customer obsessed, because you always need to provide answers to customers. Each time there’s a problem, you are the first one that will hear about it. Being at the start of your career, you also have this feeling of importance because you need to go back to the client and say, I know there was a problem with the product, these were the issues we identified, and our colleagues are working on it. Or you do some sort of debugging.
So I think it’s not a clear path from that point onwards, but being in front of the customer is, I think, what makes it in this journey, in this career.
Why CS Can’t Be a Standalone Function in Enterprise
Irina (2:22 – 2:41)
Across your roles, CS has never been just a team. It’s been enablement, it’s been support, it’s been partners, pre-sales, delivery. At what point did you realize that treating CS as a standalone function just doesn’t work in enterprise automation?
Alex (2:44 – 4:06)
If there are people out there that still believe that CS should be a secluded space in an organization, that’s completely wrong. If somebody asks any CS leader out there what their main role in the company is, the answer is: I’m sitting somewhere in between the clients and my organization.
You are the ambassador for your clients internally, because you always need to collect all the feedback, try to understand their pain points, try to understand their strategies, and go internally and negotiate with your colleagues to be able to build the things the client needs. But also the other way around. You always need to stay in contact with the internal teams.
It’s more a matter of having close relationships internally and externally than actually having the spotlight on yourself. It’s not about being there and shining on a stage. It’s more about bringing somebody else onto the stage to shine and do the kind of work that the client needs to benefit from.
I think the entire CS role is changing and adjusting. Of course, all roles out there are changing and adjusting. But being in a collaborative environment is even more important nowadays in this CS function.
What Breaks First When CS Is Isolated
Irina (4:07 – 4:12)
What usually breaks first when CS is isolated for the rest of the system?
Alex (4:14 – 5:44)
It’s the relationship. The customer will see it. They will see that you are isolated and you don’t have the information they need, or that you are not fully enabled. The trust element will break there. You need to come up with other ways of bridging that gap or fixing that situation.
I think that’s the most important thing, because when you are working with clients, you don’t want to come across as selling into the client. The client will see you as a seller and will always treat the entire conversation with different gloves, let’s put it that way. You want to be more like a trusted advisor. And in order to advise the client, you need to always be up to speed and up to date with what’s happening in the company and also in the industry.
I’m having so many conversations with my clients currently that in most cases do not relate to what we do internally, but relate to what is happening in the industry. Being in the AI world, we’ve seen that things are being developed and shipped on a regular basis. You always need to be up to date with what is happening there.
It’s a mix of everything, but when you are in a disconnect position with your internal teams and with the industry, that is visible from day one to the customer. And it’s very difficult to retain the trust, or to win it back.
Owning Outcomes When Delivery Goes Through Partners
Irina (5:48 – 6:23)
I think there’s a flavor that I want to bring to our discussion because I don’t often talk with people who are also doing the partner’s success, I would say, not only the client. I want to ask you, how do you think about ownership in CS when you don’t control the people actually delivering the work? When the work is done through the partner, how can you do the partner’s success part?
Because I think it’s a bit different than when you are interacting with the final client.
Alex (6:23 – 9:26)
I think ownership is overall a big topic in this role. My personal view is that the CS leader or CS owner of the account is responsible for the business value that customer account is getting or capturing from working with your organization, including through third party components like partners and so on.
That’s the ultimate thing. That’s what you own as a CS, in my view. All the other things come more as elements of control. You want to be in control of how the implementation goes, or how a digital transformation initiative is going, or what the client is bringing in terms of vision or strategies. You want to steer them in the direction that will bring the most business value for them.
Working with partners is even more complex because you have another group of people who, beside the fact that they want the common customer to be successful, also want themselves to be successful, because they are coming from a consulting agency, an implementation SI, whatever the company is. It makes it a bit more difficult to navigate, to bring all the goals and KPIs together, and to understand how that organization is being measured and what you can do to have them be successful as well.
Customer success is not always just about the customer being successful, despite the name. I think the success part is more important. Everybody needs to be successful in their own way in that engagement. How do you navigate and combine all these things together? That requires a bit more experience. But you never want to be put at the intersection of the customer and the partner just to mediate between them. You need to have your own position. If the partner is not doing what it’s supposed to do, this needs to be addressed. If the customer is not doing what it’s supposed to do, this needs to be addressed.
From an effort standpoint, managing an enterprise customer with partners takes close to two times more effort than with internal resources. But then again, even with internal resources, you don’t really own the people doing the implementation. You have a feeling that it’s our own department, but right now I’m part of an organization of around 70 to 80 people, and the implementation group still has their own goals and objectives as a department. Each individual has their own objectives. It’s not fully owning that just because we are part of the same company. We are pushing in the same direction, but that question still stands regardless of whether it’s a partner or not.
How CS and Implementation Are Structured at Otera
Irina (9:27 – 9:47)
You brought an interesting thing to the table and I realized I didn’t ask, how are you guys are organized? Because you said that implementation is another thing. What does CS own and with whom do you interact in order to make the whole customer journey, an enterprise customer journey, smooth?
Alex (9:48 – 11:25)
Basically, our company is made out of two parts. There’s the go-to-market function, which focuses more on the pre-sales side of things: reaching out to new people, trying to get them in the pipeline, doing demos, POCs, and trying to close the deal. That’s the journey they focus on.
My organization sits on the post-sale side of things. Once the customer has been signed, there is a handoff from our go-to-market colleagues to us in order to start onboarding that client and identify what needs to be done. In some cases, there are clients who want to self-implement, so enablement is an important component there: getting them up to speed on our practices, what they should do, what they should not do, and so on. If there’s a partner, we start nurturing that relationship as well.
I’ve seen it in other organizations where the CS function was more part of the go-to-market structure. It made sense back then. But today, what I’m seeing more often is that this function fits better on the post-sale side of things, because ultimately I need to care more about the clients we already have, how we retain them, and how we make them happy, than identifying opportunities outside of the organizations we already have as customers.
What Enablement Actually Means and How It Changes by Goal
Irina (11:27 – 11:46)
Tell me more about the enablement part that you mentioned, and what does it mean in your case, in your line of business, and how do you treat it? You mentioned that enablement is important for the customers, or at least for the ones that decide to self-implement themselves. What does it cover, the enablement?
Alex (11:47 – 14:12)
I think what’s important to define as an organization around enablement is: what do you want to achieve with it? Because enablement is more about yourself as a vendor, at least at the beginning when you start to set the foundations. It’s important to define your objectives.
Do you want to sell more? Then maybe you need to spend more time enabling the right players to do POCs, demos, sales pitches, competitive comparisons, those kinds of things. Do you want to consolidate your ecosystem of technical people that implement and build solutions? Then we’re talking about a different type of enablement. Define your objectives, define your timeline, and start building towards that goal.
In my current role, it’s more important to have customers and partners enabled to know how to identify a use case. I still need to focus on what we can do more within the current customers we have, in the sense of identifying new use cases, meeting new people, getting introduced to new board members or C-level people, and trying to explain to them what we do. But you are just one person, so even for that you need a smaller army of ambassadors. Trying to enable those people and equip them with the right tools and messages is also important.
In the post-sale side of things, it’s more important to have people aware of how to build solutions than how to sell the solution. And this is just my universe today. In the past, in previous roles at UiPath for example, it was more important for me to grow the pipeline through partners. That meant more pre-sales enablement, more enablement around how to do POCs, how to identify use cases, how to pitch to new clients. At a high level it might not sound so different, but in reality it’s a completely different world.
Irina (14:15 – 14:26)
You… Not sure if it’s a privilege or a curse when you are serving enterprise customers, because it comes with goods and bads.
Alex (14:26 – 14:27)
Yeah, exactly.
Balancing Startup Speed with Enterprise Discipline
Irina (14:27 – 14:41)
But I’m curious, how do you balance speed and innovation with the operational discipline enterprise customers actually need? What can you do? This is why I said it’s a blessed curse.
Alex (14:43 – 17:57)
If you are coming from a startup and you need to deal with enterprise environments, there is a cultural clash from the beginning. Inside your organization, you will most likely hear that we need to do this fast, next week we need to see real progress on this topic or initiative. But if you shift into your customer’s organization, you will see that the planning happens in three months, we will just start with the planning. Or in six months, we will start considering it. So there is a gap in terms of how startups operate and how enterprises operate.
Typically at the beginning of an engagement, things move faster if you are part of the innovation group, because most of these organizations have innovation groups and those people are just looking for tools, looking for technologies, and trying to fix things on their own. But that is just a way in and will only give you a glimpse of what is happening internally. With that group of people, things tend to move a bit faster.
When you go into the real business problems that the board has, the top five things that keep the CEO awake in the middle of the night, those can in some cases move fast, but they require more planning than a startup might be ready for. Implementation time has been reducing with all the AI tools out there, but if your implementation takes four weeks, planning might take four to six weeks, and integration with their existing systems might take three months. The entire project is not necessarily delayed because of your tool or your practices, it’s more about their ongoing ways of doing things.
What we started seeing at Otera was to try to define the big problem we want to fix and then split that problem into smaller pieces that will be delivered fast and demonstrate business value early in the process. This way we can keep the business engaged. IT projects in the past were, okay, this is the budget, this is the problem, fix it, I’ll see you in six months, hopefully you will nail it. But now we are shifting that and making faster releases and small iterations in order to measure and show business value much faster.
There is a change in the entire way of working with enterprises, and we are seeing them start to adjust as well. But let’s see how fast these things will actually come around.
What Scaling CS Really Means in Enterprise Environments
Irina (17:58 – 18:23)
If you look across automation and AI platforms in general, what do you think leaders underestimate about scaling customer success in enterprise environments? What does scaling CS mean in an enterprise environment?
Alex (18:25 – 19:58)
That word enterprise actually makes the whole difference. When you are dealing with enterprises, on paper you might say I am working with this company, but in reality there might be 10 different legal entities sitting under that umbrella. So you might actually define your work as 10 different companies.
The way the CS role evolved came more from this angle of, maybe you have a certain ARR or budget that you handle through your customers, or maybe you have this number of customers, or this number of users spread across however many customers. That was the way capacity was defined in CS in the past, and there were reasons why people were doing this. But in the enterprise world, that doesn’t really work like that.
Today, you might have one customer that has barely been moving for the last three months, but starting tomorrow you will have five new entities that showed interest and you need to ramp up and speed up the entire process with them in order to capture use cases, people, and ideas as quickly as possible and start working on those.
So scaling is less about adding more CS individuals and more about adding support roles around the CS function. That’s how I see it.
The Skills That Will Matter Most as AI Reshapes CS
Irina (20:00 – 20:12)
And in the era of AI and with all the things that changed lately, what skills do you think CS leaders will need more of, and which ones will matter less?
Alex (20:15 – 21:36)
I was mentioning earlier that the full ownership of CS is closer to the business value. But I think moving forward, the CS role should also become a bit more technical. There are companies out there that are defining their CS organization as a technical organization. They don’t necessarily do implementations, but they are still quite close to the product, quite close to the projects, and they understand architectural concepts and those kinds of things. I think that is one skill set that will make a difference moving forward.
But then again, you are mentioning AI. Whenever I’m talking to somebody that starts a question with AI, I have a feeling that the question comes more from the angle of, I have access to ChatGPT, I have access to Claude, so can I call myself an advanced CS? I would say not really. There are practices that you can learn from those tools, but ultimately it’s still the experience and the drive that sits behind being a successful CS individual. These are not things that you will learn from two prompts and a two-page answer that seems well articulated. Those are things that you will discover and experience on your own while doing work in enterprise environments.
Irina (21:37 – 21:57)
Alex, thank you for the conversation. It was great seeing how you think about CS and enterprise in general. To everyone listening, thanks for tuning in.
Until next time, stay curious, keep learning, and mastering customer success.
