Episode 6: Ramon Icasiano meets with April Campbell, Stripe, LinkedIn, and SAP Ariba Alum, to discuss different partnerships when evaluating business systems, integration strategies, and delivering performance intelligence to front line employees.
April is the former Head of Go-to-Market Systems at Stripe, a financial infrastructure company and payment processor. April has 15+ years building exceptional, inclusive teams and business systems for companies like Stripe, LinkedIn, and SAP Ariba .
Episode 6: Ramon Icasiano meets with April Campbell, Stripe, LinkedIn, and SAP Ariba Alum, to discuss different partnerships when evaluating business systems, integration strategies, and delivering performance intelligence to front line employees.
April is the former Head of Go-to-Market Systems at Stripe, a financial infrastructure company and payment processor. April has 15+ years building exceptional, inclusive teams and business systems for companies like Stripe, LinkedIn, and SAP Ariba .
Ramon Icasiano 00:28
Hello. My name is Ramon Icasiano. And today, we have a distinguished guest, April Campbell. Before I get started, I'd love to just go through our backgrounds. I'm a 25-year CX veteran, helping companies like Verizon, Zynga, Netflix, and now Chief Customer Officer at Pathlight. I grew up as a frontline agent, and so I'm hooked on these headsets. So it’s my pleasure to introduce April Campbell. She graduated from UC Santa Barbara with her computer science degree. Was an engineer at Neuro Data, a Technical Director at New Moon Systems, Director of Engineering at Tarantella, Director of Sales Support at IPLocks, Database Marketing Manager at SAP Ariba, and then wow, at LinkedIn for almost eight years as the Global Director of Sales Systems. And most recently, former Head of Go-to-Market Systems and Sales Marketing and Support and Legal Systems at Stripe for almost four years.
So April, I loved your background. It's obvious that we need to dig into your tools and support of frontline teams. I think where we have a major overlap is that we're both, I guess, shared services. You provide the technology. I provide the human support to big brands and companies. And so before this call, I was thinking of just as a buyer of your offerings, I've played three roles. One is the person, the buyer that says, "Hey, I can do this myself. I've got the technical team. I know what I need. I'm going to build this myself," kind of role. Then the middle role of, "Hey, I have experience buying platforms and services. I know what I want, and I'm going to give you some general guidance around what my needs are." And then the third level would be, "You're the expert. I don't have an opinion. Just come back and make me happy." So what are some of your thoughts around those three buckets?
April Campbell 02:56
Yeah. I also find myself on the other side of that. So you've had that experience where you find yourself in each of those three groups. I've also on the technology side been there as well. So it's funny. You think that like, "Oh, this company, they always buy or they always build," but it's not usually that cut and dry. A lot of times, you will actually find yourself in those three buckets at the same company depending on who your customer is. So as far as completely building... So I think of it as what... How I am hearing you is that it's like you have the, "Let's build everything," "Let me buy something," right? And then the last one is, "You make the decision." Does that sound right?
Ramon Icasiano 03:49
Yeah. And I can share... I know my conviction around building something, and I look back at those times. It was something where the company was so narrow in terms of what we were delivering that it made sense. But then looking in hindsight, that decision may not scale as the company expands. The middle portion where I've come to someone like you, to me seems like the best outcome where I work in tandem with a technical business partner like yourself, and then just give you the guardrails of what I'm looking for. And then the last situation where, "Hey, just build it for me," I can tell you that that's almost a recipe for you and me being disappointed, right?
April Campbell 04:45
Absolutely, so in the first scenario, I would say that sometimes maybe when you're testing things out, you might want to build a proof of concept that you could do it. But there's probably a time where you have to go back and reassess like, "Do we want to pour more resources in this or do we want to look to see if there is some 'off-the-shelf' type of solution that we can implement for our needs?" And so I think that you have to reassess that. And one of the things I like to think about is, "Is it a value-add? Does it give me a competitive advantage for the company to build it ourselves?" And if so, if it's going to give you that competitive advantage, then maybe you do pour those resources into that initiative.
But the things you have to think about is that engineering resources are scarce. And so if you have a big engineering team and there's some other initiative that's maybe product-focus, those resources might get funneled over there. And now you're starving for that initiative. And I totally agree with you. I think the best scenario of where you are my customer is that we actually have responsibility of the project's success together. And I agree. I think it rarely works if it's, "Throw it over the fence. Let me implement it. And I'm going to come to you three months later with something." I think in my career, sometimes when you do that...
Let's say I'm trying to build you the coolest thing that you've ever seen like, "Don't worry, Ramon. I know what you mean. I'm going to build it for you." My team goes, we build it. And we come back to you. And well, you really needed to be part of the input to that, right, the contributors to that. But then your team will feel like, "Oh, this is not something that we built together. It's like, this is something the systems team is doing to us versus for us." And so that's where I like to take the temperature. Does the people who are going to use the system day in and day out feel like, "Oh, we are doing things for them to make them more productive and successful," or are we making them do things that they don't want to do and they want to get their job done?
So I totally agree with you, which is number one, the first bucket makes sense sometimes to do that, especially when you're testing. The second bucket, if we are going to implement systems... I mean, that's actually true whether it's out-of-the-box or engineering-based, you really need this close partnership. So that's why it was so interesting for me to talk to you about this, because the recipe for success is close partnership, where we both win when it's done correctly versus fingers pointing opposite.
Ramon Icasiano 07:41
And interestingly, you're making me think of a situation which I think is becoming more common now with the advent of just SaaS and all of the empowerment of business leaders to choose their own software that meets their needs. I found myself as a shared service acting almost like an internal consultant to people even though they were going to make a decision based on their needs, but I made sure that I provided them the data, the context, my experience to help them make their best decisions. And more often than not, because of that role I played as a consultant laying, empowering them, the business owner to make those decisions, they actually came back to me and said, "Actually, I'm going to buy from you as well." Right? Because I think that they don't have the context of the complexity and all the nuances of really of a shared service like a support, or even a tool or internal tech. Have you found that business partners are being more empowered to make those silo... not silo, but their own independent decisions around software that they're buying and you've played a consultant role to that?
April Campbell 09:03
Yes. I've seen that often. And it's more easy to do it nowadays because it's so easy to purchase. We've made it really easy to purchase new solutions. So I've done roles where it's a periphery application and maybe my team helped more from a security review or does it fit into the existing sales workflow? So we can act like a consultative partner. There is a time where... And this is my opinion. There is a time where the dependency on that tool is so great and so much part of the workflow of the team, that it might make sense to centralize the management of that tool. And I would say, because as more people adopt a platform, there is going to be some administrative tasks. And do you want your sales or people who should be agents in front of customers spending their time administering the platform, or should they be doing their day job, and then offloading the support of the application to more of a systems team or IT team?
And then the other thing to think about, what I like to think about even earlier in the discussion is, is there going to be sensitive information stored in this system? And what is the risk we want to take of that being in another third-party system? And so if there's a lot of sensitive information, maybe I would advocate bring us in as partners where we will manage it to make sure that the data stays secure and new people into the company and people who are exiting the company have the right access. So that's another view, a different lens that I look at it too.
Ramon Icasiano 11:00
So April, thank you for that perspective. I think it's so important, the expertise that you bring as the technical owner of tools, to help business partners mitigate risk and setting up systems to make sure that there's no long-term problems that pop up, right? But assuming that everything's implemented and all the technical boxes have been checked off, how do you recommend the business to interact with your teams and people like you in the organizations for new features, maybe possibly even other things that they want in the future?
April Campbell 11:35
Yeah. I think there's two types of asks, at the very least. One is how do you... That our team gets... Is small modifications to existing processes. So things that already built, "Oh, there's a new team using it. We're going to need to make some changes." What I'd like to do is set up a way every couple of weeks to be able to hear their asks, prioritize them, execute them. So you can think of them as quick wins. So how do we make sure there's an input way where they can ask us these things? I work with someone on the business side to help prioritize it because there's always going to be so many more asks than we can do. And then we'll have a model where we can execute those quick wins.
And then you have the more strategic things or things that will just take longer because it's more complicated. My team wants to be brought in earlier so that we can help be part of that solution because we might... More heads are better than one, and that we maybe have seen it done at different companies, where maybe we know of an application that does 80% of what you want to do, or we've seen customers built it, right? So what's better is to bring us in so we can help be that consultative partner versus bringing us in at the end where we're more of an order-taker like, "Okay. We've gone through all of these things and now we want you to implement A." And then we're going to still have to... And you guys are all ready. Your team's ready. We're going to go. Let's go. My team has lots of questions. Then it might feel like we're delaying the process. So if you bring us in earlier, we can help tease those details out so that when we're all ready, we're all ready to go at the same time. Does that answer your question?
Ramon Icasiano 13:30
Totally. And what it brings up is the listeners might be saying to themselves is, "I don't have an April-like person on my team. I'm as a business person accountable for results. I'm trying to drive the efficiency through tools." How do you recommend that business person approach the procurement of something like a SaaS tool?
April Campbell 13:59
Right. I guess it depends on what kind of tool it is. So if the business person wants to pilot something, then they need to, of course, carve out time to do it correctly. And then usually if it's a new SaaS product, then the provider of the SaaS will help you actually do the implementation. But it's like a lot of pilots. You do a pilot and everyone's, "Cool, let's do it and open up to everyone." And you're, "Oh, hold on. I need to make sure it's staffed accordingly."
So if there's going to be a burden of some type of management, your provider should be able to tell you that. In typical installs, if you're like this and this, you're going to need someone 10% of the time, and then you could decide, "Is there someone on the business side who wants to raise their hand that likes technology to do it?" But really not try to kid yourself, as in actually, you just bought Salesforce. It's going to be managing over 100 people. Then we actually need someone's day job to be to manage it. Now, does it have to be 100% of their day job? Maybe not, right? And then you make those decisions, which is like, "Am I going to absorb this as a business? And if so, do I need a technical person that sits on my team that manages it?"
Ramon Icasiano 15:29
So looking at not only the setup, implementation, the technical stuff, but also the ongoing, and that may change the decision in terms of how supportive the SaaS provider is in terms of the implementation and the ongoing support. That's important. So what questions do you have for me? We're both shared services. I'm probably a typical buyer. And so maybe for the audience, what are some questions you could ask the "buyers" that are listening? A question from your perspective.
April Campbell 16:05
Thank you so much for that opportunity. I would really like to know, based on your history in this field, what is an example of a really good partnership that you had with systems? If you could recreate that partnership so that you can go, go, go, what makes that partnership special or work?
Ramon Icasiano 16:28
Yeah. And I think my approach... And again, what has helped me build amazing cultures, brands, right, and customer experiences for my clients, is I want the tools, the data, the team, the culture, to help make an emotional connection with our people we serve. And so if a tool requires a significant amount of expertise for a frontline person to really feel what the customer's feeling, I'm going to push back a little bit in making sure that the tools actually do the opposite by highlighting what that consumer's gone through from their experience with your brand. So has it been painful? Has it been great? Am I someone that is just avidly using the service or someone who's using it periodically? So just from a interaction perspective, I'm a frontline person and I immediately get a feel for how I can help you.
So I'm skewed way towards the frontline experience, having run and managed teams like that. To me, all of the data, the systems, the tools really should be focused on frontline success. And so I'm going to push everyone in terms of the business partners, the analytics, and all of that, to help me... People have said this, but help me rub against the soft underbelly of the company every single day so that I know that there's continually work we need to do. I don't care what the NPS scores are, if they're high, CSAT's high, I want to hear where the problems are, and the tools help me. So I think to answer your question, for me, it's lining up requirements that lend the outcome to be towards that.
I mean, I understand that tools all bring different things, but I just want to make sure that at the top level, that it's really driving that frontline engagement and success. And so that might be an oversimplification of the ask, but it's the check box that I'm looking for, because I'll think a lot of stuff is geared towards senior-level kind of things and the workflows are important for them, but for me, it's really the other way around. It's inverted. I don't know if that helps.
April Campbell 19:02
Yeah. Totally. It really resonates. It's basically, you're like, it's all about the customer. It's all about the customer. So if I'm in the back office and we're configuring this stuff, we're like, "It's okay, Ramon. You just have to press these seven buttons and open up four extra screens." But now the company has the data that we need to March forward and you'll be like, "Oh, wait. Hold on. That experience is taking away from the time my folks have with the customer." So that totally resonates with me. It's a failure mode because we keep thinking of things as a technical thing, and you're thinking of it as an emotional thing. So that's why the partnership is so important.
Ramon Icasiano 19:39
Totally. And so what can buyers do to balance that perspective out? We're not technical, typically, and there's a lot of technical stuff that waves over us that we can't overcome for good reasons. How should we couch the customer-first experience with teams like you that are more technical?
April Campbell 20:10
I think that's part of... You do a project kickoff or even discovery. Is this a project at all? And be as bold as you are now. You could solve all the problems of the workflows in the back end, but if it takes away from the customer experience, then it's still a failure. You can be that bold so that we're like, "Okay, well, so this is what happens in the back." It's like, "It's only four extra clicks," or, "It's only four extra windows that they have to build up. It's fine." And I might come to you and say like, "It's only four windows," and you're like, "Fine, but in three months, that needs to be one window." That's okay. We can do that negotiation because sometimes on the backend, we want to iteratively provide you relief and also still be able to answer what the business itself needs to run a company. So we might have to have those discussions. But all of us are locking arms and understanding what the end goal is. The end goal is a seamless experience where you can give the best personal experience or automated experience.
Ramon Icasiano 21:22
It's so true because when I think back, when that has happened, where everyone was tied to the end outcome of amazing customer experience, both the technical and the business teams were celebrating the success of that. Everyone was like, "Yeah, I know I was part of that outcome." So let's transition to close this out. Looking ahead, what should folks be thinking about on... And I'll share what I'm thinking on the business, maybe from a technical side. What should be on the back of their mind in terms of the future of tooling and technology?
April Campbell 22:05
Right. Well, I'll steal from some of your messaging in the time that we're talking today, which is, wouldn't it be amazing experience that the business, the company, is able to get all the information they need to run the business, to forecast, to market, to operate, without changing the workflow at all with the people that are using the tool? So the holy grail is like, "Let them work, do the things that they do best, and we're going to capture this information in the background in order to make good product decisions, staffing decision, all these things." Right now, what you'll have is you have something in the middle, which is some of these things can't be automated. So we need people to update status. We need people to do blah, blah, blah. But really, if we can understand those or infer it based on their day-to-day, then the experience from the end user is just their job. And in the back end, we still have what we need to be able to make a successful business.
Ramon Icasiano 23:14
Yeah. I love that. And I'll close out with, from a business perspective, I don't want people to ever forget that it's always a people business. If you've got a frontline team, performance is involved. That means coaching, making emotional connections with your people, good one-on-ones, interacting that way at a human level. So the performance. And then really, what you're highlighting here for me, April, is intelligence, how maybe connecting data points that weren't normally connected, like metadata, to actually provide you a deeper, more cross-functional look at the customer experience, and maybe making decisions on how and where that issue is routed to, right? And to your point, have the systems work through the intelligence using the right information to curate that. So from a workflow perspective, I'm a frontline person. It's resolve, resolve, help, help. And I don't have to be an expert in saying, "I got to click these four screens to get to the thing that I need." Good design, I guess, good data will help you figure out what to and what not to present to the frontline.
So with that, we're going to share April's LinkedIn information on LinkedIn. What a valuable resource she will be. My contact info will be available as well. And to wrap it up, thank you again, April, for joining me on the CX podcast, the podcast for operators, by operators. So that's simply put, but powerful, and we're available and here to help anyone that's listening. So thank you.
April Campbell 25:11
Thank you. It's been fun.