Build vs Buy: Evolving the Post-Sales AI Solution Stack
Companies are asking the important question of whether to build or buy AI solutions. Building lets you customize to your exact needs but also requires significant resources. Buying leverages core competency and AI domain experts but may raise concerns about the need for customization. In this session, we’ll dig into the tradeoffs and hear from leading companies who have pursued both paths and will share what they’ve learned in the process.
You Might Also Like
We're going to talk about build versus buy,
evolving the Post-Sail solution stack.
This is a really big topic, obviously.
We've been hinting at it throughout the day.
Companies are facing a tough choice,
because I think inherently,
there's an instinct of we're going to go build this AI solution.
We have a lot of smart people,
we have data scientists, etc., etc.
They'll go back.
Hold on. All right. I've got it.
So there's a lot of important questions that are faced about,
what are the benefits of working with
a packaged solution, best-of-breed solution?
Do I trade off core competencies and time to market?
Where does initial cost,
where does total cost of ownership play into this?
So while we've been scratching at the surface of all of
these important questions today,
we're going to go deep on this right now.
So I'm really excited with the panel that we have,
because we have some incredible experience,
both on the operations side and Post-Sail CX,
in customer success and support, digital channels.
Then we also have the representation from the office of the CIO.
What we've found is that often these investments have to take place together.
CIO working in concert with a Chief Customer Officer,
SVP success, and so on,
because there's a functional need,
and then there's a business need,
and that collaboration is so critical.
So I'm going to call up the panel now,
and first I'm going to call up Alvina Entar.
Please join us. Give her a round of applause.
So Alvina is a CIO and an advisor,
and she is currently on the board of couch base,
and also an advisor for Signal and Ola Kai,
focused on the security and AI space.
Alvina was most recently the CIO at Octa.
Previously, she was the CIO at Zora.
That's where we work together.
Seems like yesterday, but it was quite a ways ago,
and in IT leadership roles at Dell Technologies.
So welcome Alvina.
>> Thank you for having me.
>> Next I'd like to call up Ashuk, Ganesakaran,
and give her a round of applause.
Ashuk.
>> Thank you.
>> Welcome. Ashuk is currently the SVP of customer success at Excel data,
and Ashuk was previously at NetApp,
and prior to that at Informatica for a long time,
many years in post-sale, CX, and digital leadership roles.
I will mention that Ashuk was instrumental at Informatica
to build their own in-house customer sentiment solution
that they used for many years,
and then as part of their process of evolution,
they decided to partner with support logic.
So we'll talk through some of the decision criteria
and how you went through that change management,
which was a big factor.
So thanks for joining us Ashuk.
And then finally, Vimal Bastudevan.
Vimal. Welcome.
So Vimal--
>> Thanks for joining us.
>> Vimal is head of digital parcel, USA at Corber Supply Chain.
And previously, you were many years at Siemens Logistics
in product and technology roles.
So it's great to have all of you with us.
Thank you so much.
So I'm going to show just a couple slides here.
I'll go back to the panel slide for Gartner, the CIO priorities,
just to set the stage.
You see on the right, this is basically a split
of commodity items to the left,
differentiated items on the right,
which I think everything that we're talking about
in the categories of AI and OCLCX are today.
And you see the focus on innovation and product roadmap,
as well as TCO as important factors.
So that's something really to keep in mind.
And then you can see the state of technology
employment or deployment in terms of AI
and the generative focus and also low code, no code.
But we're not really going to get into that today.
So I think it's a good backdrop for us
as we talk about build versus buy.
I'd like to open it up on the panel, just ask you all,
what do you think are the most important factors
to consider for companies today when assessing whether you
should build versus buy AI technologies?
Why don't we start with you, Alvina?
Yeah, thanks for having me, Joe.
I'm excited to be here.
So just build versus buy.
I mean, back in, I don't know, 10 years ago,
we talked about this in our time at Zora.
And it was at that time thinking about cloud technologies
and the emergence of the cloud in the 2000s.
And here we are, it's 2024, and we're
having a conversation on build versus buy for AI.
And it's the same question, right?
It's in the same answer.
The reality is you purchase and you
invest in technologies that are best in class, that
are truly differentiated and that are critical to your business.
And you invest in building those that
differentiate your business, that are part of your IP.
And that is as simple as it is, right?
And that's what we've done back for the last 20 years,
plus with cloud technologies.
And that's what we will do with AI, is what I'm seeing.
And so the need to be able to ensure
that we partner with technologies,
like support logic, that are really
differentiated in having depth of expertise in an area
that, for customer experience, customer sat,
the number one priority for most employees,
or most companies, are loving their customers.
Putting customer focus, or customer first,
is the number one priority.
And so how would you not invest in providing and investing
in solutions that are truly best in class capabilities
that support your focus on customers?
I love that priority.
I think everyone here can relate to that.
So thank you, Ashut.
What about you?
Absolutely.
That's one important aspect that, as I've pointed out,
to me, when I look at it, I have done it both.
Joe knows it better.
So from what perspective that we look at,
especially from a tech company,
be it my time with Informatica, where it was responsible
for all the customer facing, as well as the internal
applications that we were building,
it is very important from two aspects.
One is the complexity and the depth of the use case
that you have.
So it all starts with the use case,
what we are trying to change in the business model.
So back then, it was like four or five years back.
We looked at it from the maturity of AI
was not to the level where we are today.
So we had to look at the depth of the use case
that we want a complex health score.
For example, derived back into time,
there's not a lot of options in the market
in terms of maturity, of taking the data
and making it meaningful for your business.
And really, the differentiation was like,
how deep you want to go in your business,
like the data that's specific to your domain,
your industry, or anything that's very specific
to your business process, then it makes sense
for us to build, right?
But at the same time, if you look at it from kind of,
as you pointed out, that industry leaders
are having more data, they have more trained data models
that can bring a better version of customer sentiment
or whatnot that we, the machine learning models
that we have to develop from scratch,
then it made sense not to build,
rather we would buy from somebody, right?
So it truly depends, that's one of the factor.
And the second factor is truly, if the time,
and as you pointed out, Joe, it's a cost of ownership, right?
And I would give an analogy to close to,
kind of you want to buy a home,
then you either buy it, you build a custom home
or you buy it from a builder who is building track homes, right?
Both has its advantages and disadvantages.
If I'm, ideally, I may want a custom home,
but you have to spend a lot of capital on it, one,
and the time that you get to construct
is going to be very long,
and then you are going to have very specialized way
where you are going to engage with an architect,
or a designer, and a builder, and a contractor.
And the responsibility falls on you
to make sure that project goes per plan,
you have to coordinate between multiple people
and all those stuff, yes, the end result may come,
but it will be a very long time to value.
Versus you go, you buy it from a track builder,
so you get a templatized version
that they have done the construction forever,
so they just do it faster, you will get a basic home,
you still have a way to swap your floors,
your countertops and whatnot, what is important to you.
So you still get it in three to four months
rather than a year or two years, right?
So it depends for you what is more important
at any point of time,
and at this time everybody wants to show value faster.
Nobody wants to wait for years to show an initial use case
in the promise of AI,
so I think there is a natural inclination,
the current maturity of AI
that people are trying to kind of buy first.
>> I think that's right, in terms of the current situation,
we'll come back to that, like the analogy, by the way.
Vimal, what's your perspective?
How are you thinking about this trade-off?
>> I take key factors.
>> Thanks, Joe.
I take a very simplistic view of these things.
I agree with some of the points.
For me, the fundamental unit is job that needs to be done.
Job that needs to be done is a fundamental unit,
and then like digital twin,
it comes with a twin, which is one is a problem statement,
and the second one is value proposition.
Combination of these two will make,
will give us a clear picture,
whether it's a buy case or a build case.
So my view is just revolves around these three parameters
to make the decision.
>> Fantastic.
I'm going to go back to Ashok.
So as you built it, built a solution for sentiment analysis
inside Informatica, you have a great perspective on this,
what level of in-house AI and machine learning expertise
are required to really build it and build it well?
>> Yeah, I think one main reason, as you talked about Informatica,
many of you know Informatica, and I think there are folks
from Informatica here as well, if you want to learn more.
But it's a data integration.
So basically, you sit on top of wealth of data.
So we help customers to realize the value of the data faster.
So each your own dog food, the build was not,
buy was not an option.
First we have to try what's the capability that you can build
with the data that we have around about our customers.
So it was a very good use case for us to start thinking,
build first, right?
So from that perspective, we still having just the tools alone
is not going to be enough.
You need to have the cast around it.
So you need to have a data scientist for sure,
which is very hard to find a good data scientist these days.
When I say good, it's not just about building ML models,
training the models and deploying models.
That's a typical ML operating model.
But the data scientist, a good data scientist,
we need to have a good subject met knowledge about the business process
that you're trying to automate.
So it's not purely statistical and analytical,
but you also need to know what you're solving for so they can come up
with the better models and better sentiment scores,
what makes the most sense, what does it mean.
So good data scientist is foundational.
But at the same time, a data scientist cannot do everything to build
that data together.
We need a data engineer, which is very hard to find skillset again,
that you need to have a data engineer looking at all the pipelines
in their enterprise.
You look for the sources of data from working with IT
and getting the IT data sources.
You work with the product devops team and get the product usage data,
which is again very regulated.
We cannot get the customer data in what you're getting
and what you cannot get, right?
And then deriving the PIA information,
you need to work with the Enforse
with the flurry of applications that you have and the data you have,
what data need to land in what persona, in what business process,
which business process are we trying to disrupt.
So the business architect or business analyst need to,
or business operations person, need to really make sure you connect the dots
in terms of what we are trying to solve for and where we need to integrate that
is it a sales force or any of those things,
which business process is invoked in what system.
That was one learning for us that when we built initially,
we didn't have an integration that touched the people in where they are
operating
on a daily basis.
What support logic gave us was that opening, right?
So you do all good models and everything,
but you just throw it over the wall and think that they are going to use it.
It's not going to happen.
So we took support logic because even though we built some great models,
reaching the end users in process on when they are attending a customer call,
what they need to be aware of and what signals are important.
Those were hard things to build everything.
So it was easy for us to make a decision on why the same model worked better
when we used support.
Appreciate that.
A quick follow up to that with generative AI, which has really just been here
a short time.
Do you see in general, do you see this as changing the calculus for build
versus buy?
Any different than when it was just the other AI technologies?
>> You want to go?
>> Yeah, back to your progress.
>> Yeah, the generative AI, well, so I look at the AI use cases broadly
fall under the, I think you also called out three different areas.
The AI is a predictive AI and other areas that traditionally has been
there for a while and generative kind of touched upon every aspect of AI,
especially it is really this kind of big shift in generating content.
So that not only just made the gen AI side of accelerated value faster,
but also made predictive AI and bringing the personalized AI experience
to your end customers also an accelerated path.
So looking at from the evolution and growth, I believe gen AI use cases
that's kind of tapping the platform.
You already have the data, forgetting about the data complexity and what you
need to bring, that you need to, what I talked about bringing a data
engineer and everything.
If you are contained with the data that you have in your CRM system is good
enough for you to derive some value and generate content faster,
be it case summaries or count summaries or email compilation,
those are some low hanging fruit that we can get faster to value than what
we would have otherwise built for months and years in the past.
Perfect.
Thank you Ashuk.
I'm going to turn to Vamal.
So Ashuk mentioned integration challenges.
You have a very interesting business.
Like you'd share a little bit about it.
It's a blend of hardware and software, but what I want to ask you is what are
the
common integration challenges that you have to deal with in the complexities
in your business?
So it's a very good question, correct?
So we have a broad spectrum of components all the way from south to the
north.
At the south, it's real machines, which is really working on the field.
And one of the important challenges, some of them are air gap systems.
There's no way that you can take the data out.
Or even if it is giving data, it has high noise.
So when we, like in the spirit of the title of this panel discussion
build with us by, there are various data products we need to create across
from south all the way to the north.
Certain areas, we made an informed decision that we need to build because
when a machine is producing data, of course, if you go to an outside
vendor, hey, we can grab anything and we can filter anything.
But our responsibility is to make sure the data is very low entropy because
it has very less noise and it sends the data what it matters most to the next
layer.
So some of those kind of data products, we invest our R&D and we make sure
that we innovate in-house.
And then as the chain goes up and up towards north, we tend to relay on our
partners to take this kind of data or in sometimes data plus AI product
to deliver the value like work order generation and chat bots and other
things, we relay on partners.
So the integration challenge, what we do is we take the heavy lifting
shifting at the very bottom level and then at the same time we are not so
expert at the north level, we relay on the partners to handle those things.
Gotcha, core expertise.
I'm going to turn to Alvina, so you bring the IT and the CIO perspective to
this, right?
How do you think about the trade-offs and the framework of build versus buy
and specifically the long, balancing for short term and long term for the
company?
Yeah, what I would say is the time to market is critical.
I mean the point that you made on the need to be able to actually have the
business realize value and iterate and deliver value in an iterative
fashion is critical.
And especially as it relates to areas that are essential to your business,
like going back to making decisions around where is your core differentiation,
which is exactly what we've been talking about, investing in R&D and in
RIP, but then ensuring that we are making the right decisions on who
are our partners, not vendors, but who are our partners.
And today, I mean there's a ton of effort across many organizations in
rationalizing software.
Like, there's a ton of cloud out there.
We went cloud happy and we bought a bunch of technologies, many of which are
not integrated to your point, and we're using base capabilities of those
technologies, and we're really not leveraging the full feature capability of
these technologies.
And so many people in my seat are looking at these, looking at our ecosystem
and our architecture and saying, you know, who are our partners, you know,
who are critical, mission critical to our business.
Have we fully leveraged the full feature functionality as SaaS partners
continue to extend and grow in their capabilities?
Have we kept up with the expansion of capabilities and are fully
leveraging their capabilities?
And then who is actually more complex than serving our business?
And that's where you're seeing a lot of rationalization and churning where
companies are at risk of losing their customers because they're only talking
to them at point of renewal, and they really haven't kept up with making
sure that their customers are leveraging full feature functionality of their
technologies.
And so I would say, you know, the whole decision around build versus buy is not
just buy, it's do you continue to buy?
Do you renew?
And how do you ensure that you are putting your customer at the center of
everything that you do and ensuring that you understand the evolution of your
customer and what their needs are and how, you know, your capabilities align
to their needs?
And so, yeah, I mean, I think the real decision around buying is
do you want to invest in a partner who's going to provide real, immediate,
time to market value, maybe not immediate, but to a value where you can,
you know, that is truly differentiated for your business and how critical is
that to your business?
And what I would say is with CSAT and customer support and customer sentiment
being the number one priority for the majority of our, you know, for most
companies, you know, ensuring that, you know, the difficulty of actually
landing a customer is a huge leap, but ensuring that you're able to not only
land but expand requires depth of expertise in CSAT and support.
And the evolution of the experience has dramatically evolved.
You know, people, employees expect a different experience.
So do our customers.
They don't want to wait for a support agent to give them an answer.
No matter how quickly they'll respond to them.
They want to be able to solve their problems themselves.
And so we've, you know, we need to stay ahead of that.
And our customer's expectations, you know, we need to stay ahead and ensure
that we are able to provide our customers what, you know, what they expect at the
time that they expect it.
I like how you emphasize the domain expertise.
It being so critical.
I'd like to go back to an earlier point you made around time to market.
And I'd love to hear a show and Bill Mill's perspective on that too.
How does time to market push, you know, change the calculus and, you know, are
at the risk of
asking a leading question, do companies underestimate the importance of time to
market?
I can go first, time to market as I talked about it's very important, like,
according to what I gave us an analogy as well.
But keeping that aside, I have now worked in the last three years with Inform
atica,
then NetApp, and then in the start up right now.
So my perspective on this has changed a lot in terms of what is the time to
value. Each company perceives what they want in days versus weeks versus months, right
So it is very apparent, but nevertheless, the business view of time to market
is very
different than even a CIO perspective, right?
The way that in my experience that I have seen is business wants a point
solution,
a point problem to be resolved today.
If I'm a support leader, I want, why is this escalation coming so many?
I want to solve that problem.
So it's very easy for me to pick a solution that solves that problem today with
the level of breadth and depth of data that we have.
But where we also look at it very holistically is, if I'm a CIO head,
it's also looking at not just solving that one use case, going back to your
point,
that time to value is kind of, yes, incrementally it gave x value to one
business and one line of business, but how can I add the same platform if they
are getting the so much data like the signals that you talked about from your
product roadmap, how can it broaden to more use cases that can solve problems for the
same
usage data that you are getting, how many other use cases that we can solve.
So it's more about like what is the time to value on the first value versus we
also see collectively for an enterprise, what are the capabilities that this
platform can
provide over time in the next six months, 12 months.
So it's very apparent in different line of business, look at it differently
than how
centralized CIO looks at some of these investments.
>> Perfect, Vimal, how about yourself?
>> This is an important, great question actually, because I have seen
traditionally in
industrial, sometimes the post-cell support is kind of an afterthought process.
It's not a first principle or a native topic.
So sometimes that puts in a position that how are you going to leverage what's
outside
instead of scrambling at the last minute.
So the time to value, it's a critical decision and they have to make it in a
shorter time in some cases industrial product.
So the technology like which is readily commercially available, which can
empower the front line workers at a faster pace will be most preferred one in that case
>> Gotcha.
I'm going to go back to Alvina.
So what's your advice for managing the AI investment portfolio to ensure
governance and security across?
>> Yeah, I mean that's a hot topic.
In that talk about shadow IT, there's shadow IT is now exponential with the
amount of shadow AI across enterprises, especially within the enterprise itself
right, within across every part of the business wanting to leverage these AI
capabilities, whether they're enterprise expansion, enterprise capabilities,
that also have AI capabilities or capabilities that are being built in house.
And so being in a position where you actually have, there's many organizations
that are building AI councils that have representation across legal and
security and IT and business functions to ensure that not only is there awareness,
but that you actually have monitoring capabilities where you understand what's
actually the same way that you understand the cloud technologies that are
deployed within your ecosystem, understanding AI technologies and how it's
using your data, because data is gold.
Your data is gold.
Your data is your IP.
Your data is your customer data and employee data, PII data.
Just making sure that, and that's one thing that we haven't talked about as it
relates to building versus buying.
>> It's a perfect segue.
>> Let's talk about the data.
Instead of investing in deploying a solution that you have a best in class
capability for, focus on cleaning up your data and ensuring that your data is
trusted and that you have transparent data and that you actually are in a
position where you can govern your data.
And I think that there's a ton of focus now on data governance and data
strategy
and data catalogs.
And because without trusted data, whether it's your product data and having
that product data combined with customer data to provide deep telemetry
and utilization of your customers, all types of data are critical and ensuring
that you're in a position where you focus your energy on that, I think is key.
>> That's a great thought.
I know Ashok is getting on this.
>> Yeah.
>> He's been at several data companies.
>> Correct, correct.
>> Sure.
>> So your perspective on this.
>> We are seeing that as a trend.
It's good and bad in the sense like A has opened up so much opportunities to
your previous question.
There is a general tendency in enterprise IT and the AI governance teams
forming what is right to open up versus what's not.
There's not enough tools and others to really -- there are tools, but it's kind
of
spits, yes or no.
But it is up to business to kind of stage it up to some of these governance
and councils to say how good of the data that they have and the scope of the
data that we are going to use for a specific model and stuff.
So it's up to the business and the data engineering and others to come up with
that process to see what we want to because once you say AI and you're going
to get a customer experience better, everybody connects the dot and say like,
hey, where is the customer data coming from?
Is it governed versus not governed?
And there is a general reluctance to approve anything in some of these places.
So it is more precise and governed and as Salvin pointed out, if you are very
clear on what you're asking and the span of your data that's going to be used
for
a specific use case, you tend to get a better acceptance and approval rates
rather than
especially with customer data.
On the other hand, generative AI is always -- that's on the structured customer
data,
but generative AI is very powerful with unstructured content.
Sometimes people confuse between content and data as well.
Content is data as well, but content may be just your knowledge articles.
The content can be a power point and PDFs.
As long as you have right checks and balances that you're not inadvertently
exposing your customer data in those content, that's where some of the
enterprise search engines and others are continuing to be under this
scrutiny that we're not exposing some of the customer data outside of it.
So generative AI by itself has a lot of potential that without taking customer
data and putting in front of the customer something, if we are taking it as a
staged approach to just do an internal version of account summaries or case
summaries
that you're doing, then it is an easy way for you to kind of get some value to
start with before boiling the version with a broader ask that I want to take a
digital
customer experience orchestration where I want to automatically generate
content and push to the customer where you are likely to have more stops.
>> Thanks, Ashok. Vemel, you shared before some of your unique challenges.
You talked about air gap solutions containing data in certain points.
Would you say you have a higher bar in terms of where data quality needs to be
in terms of getting insights or how are you thinking about the overall approach
to managing your data?
>> See, this is a bit of multiple aspects of the data.
So I have some interesting facts to share.
The source, we focus on the data quality on the machine we produce, the data
which has more signals and less noise.
So that's a default product requirement for our ongoing rollouts that we
produce
data with low entropy.
That's the first level.
The second level is data enrichment at various levels with partners or without
partners.
Once it gets enriched at each level, we tend to focus on the data ownership at
those areas because we do see that they add value to the data on the enrichment side.
But then where that line.
In terms of policy, last week I was in Austin to part of the house
AI select committee in Texas.
They are in the process of drafting the policies.
Some of the things were centered around ownership of the data and also who is
responsible for this generated AI generated content.
Yes, in terms of simplicity call, rebooting your modem, it's a simple thing.
But in terms of medical field and insurance decisions, these are all very
complicated decisions.
So how human in the AI loop has to be established and who is responsible for
this decision made by generative AI.
These are the topics which we are currently in, mean various association
touching and in personally the product line what we are rolling out.
These are the three topics where we really focus on the data point.
Thanks very much.
We are running the accelerator business, especially going against a lot of
these use cases where you don't know where is your data.
What is your quality of your data and then put policies around it has been kind
of
the fuel in some of these areas of data observability and other areas where a
lot of customers are realizing that their AI can be only as good as their data.
And it's like not like a garbage in garbage out, it's more a garbage in and
disaster out.
It's what?
I'll see.
I'll see.
I'll see.
It's a disaster.
What is your current health of your quality?
Quality of your data is something that everybody is asking question to be
answered.
Everyone has to think about the data and it's an important part of the process.
I want to shift a little bit to cost.
We've touched on it, right?
TCO being high importance among CIOs, but there's also the trade off with short
-term
costs and internal, right?
People count, especially if you're starting to build versus application costs.
I'll start with you, right?
How do you think about that?
Maybe one thing to add is what are some of the hidden costs that companies may
overlook?
Yeah, I think I briefly touched upon that the hidden costs is people don't
realize the people cost, right?
So in some companies where initially we had was the people cost were under
support cost, for example.
We had a very high support margin, so it's always never looked bad when you
hire one or
two data scientists that you can build yourself based in Bangalore or something
So it is something that part of our technology initiatives, be it people or
tools that we
buy, we always have a way of kind of carving part of the support budget into it
So said that that's not a luxury that many companies may have, right?
Because support delivery is different than an automation and what you're
spending on
tools and stuff.
So, but we managed not every company when you go into a public company, you'll
have a lot more scrutiny on what is Cog's versus Ops and all those things.
So one is the people cost, be it, you start small, but now it's not easy for
you to get
good data scientists, good data engineer, good business process person and
everything. And then there's a shared cost from IT and others, right?
Where they have to still continue to the enterprise data office, they need to
get the
foundational data quality for the different data domains, be it your customer
data, product
data, they need to invest to get the data pipelines created.
If we are not as a business going to own it, then it adds always no pun
intended, but
IT costs are higher than business cost.
If you have to hire those people.
It is a hidden cost.
And then you are talking about governance and people around it and business
process side,
you need to have a business process, ops person who is going to be sitting on
these meetings and governance.
So there's a lot of layers of people that you need to have, but predominantly
from a technical front, you're still going to end up having a few data scientists, a
few data engineers, integration specialists that are going to work with multiple
applications
to integrate and any sort of automation that you need to have your own
developer to bring
some of these things together.
Makes sense.
Tim, or anything to add to that?
One of the topics I showed already, Tash, is the total cost of ownership.
That is a very important aspect to calculate all this hidden cost.
You see a total cost of ownership second is the technology debt, because you
can have a great partner with a great technology and it's all good, but if you don't have
a proper skill set in your team, you will end up again spending more money.
So your technical debt is a very important thing because most often, a lot of
cases,
the buyer and the user are not saying.
So there's a huge gap between the decision makers versus actual user of the
product.
So those that may not translate into a cost, but it can become a cost.
Makes sense.
Did you want to add anything?
I had a different question.
I just wanted to add on.
The cost is not, I think you were mentioning, so the cost of maybe implementing
the initial
use case or the initial concept may be minimal.
But the reason why we talk about total cost of ownership is really, once you
decide to
build, you need to invest in enhancements and sustainment and extending and you
need to realize and think long term on that decision as opposed to just thinking short
term in
terms of the business need now.
So that's one factor.
The other is just the cost of, we talked about the evolution of the support
experience.
And today, in the past, we tried to drive down cost of support through just off
shoring
and having centers of excellence in lower cost locations or contracting it out,
having
contracting teams that have capabilities for support that are much lower cost
than investing in full time employees for support.
So because the support experience has dramatically evolved, the expectation is
no, we don't want
to have to throw people at the problem, even if the people are lower cost.
We want to have technology that can solve the problem with AI that can provide
the
customers the experience that they want at their fingertips.
And so that should be part of the assessment on the business case of investing
is the
impact that that has on the support costs long term.
So I just wanted to --
>> That's a great perspective.
Thank you.
I want to stay with you and I want to ask, we have a great group here because
we have a mix of sort of the functional and line of business expertise with CIO and IT
leadership.
So Albina, from your perspective, I think it's safe to say we've heard from a
lot of
people who are in the functional leadership role say they struggle to work with
their CIO,
their CFO, right?
The steering committees that are going to get these projects have proven that.
>> So there's some truth to this.
So Albina, what's your advice for people out here who are like Ashuk and Vimal
for how to work that process better with their CIO counterpart?
>> Yeah.
I mean, it's all about -- I mean, I don't want to sound cliché, but it really
is about partnership.
And it is a joint decision.
And you can try to build around and eventually, you know, when you need the
enterprise data
and you need -- you know, it needs to be a partnership.
And, you know, for --
>> Did I hear shadow IT?
>> And the reality is, you know, the evolution of the CIO and the office of the
CIO and IT is dramatically evolving even with, you know, it evolved dramatically with the
cloud and
now with AI in that we don't want to be the office of no, right?
We want to be -- we want to say yes.
We want to, you know, serve the business.
We want to deliver business outcomes.
We want to partner with the business and prioritize those things that will
truly move the needle.
And so having clarity around the business case and the reason to invest and why
this is, you know,
a priority and jointly coming together to be able to ultimately implement, you
know, on behalf of our customers, I mean, that is -- that is, you know, what is
needed to be able to drive the evolution or any transformation that you're looking to drive
within the company.
>> Well said.
All right.
We're winding down and getting the warning.
We have closing thoughts.
Let's start with VIML.
What advice would you leave for other CX leaders about how to --
be better at driving this build versus buy process?
>> See, for me, build versus buy process is so personal because across the
company, Siemens and
Carber have built several process -- several project products and made it
commercially successful.
So I would -- I would say two things.
It was just a movie from Netflix.
One is AK-47.
And then the second one is the buy who harnessed the wind power.
Those two movies say some fundamental truth about build versus buy.
AK-47, the government had all the missionaries and all the partners to make a
perfect weapon.
But then this one end user, there was a big disconnect between the buyer versus
user.
And he felt he compelled to build a perfect machine gun which will work
properly.
So that's one example.
And the second one is the buy who harnessed the power of wind.
The windmill was so much advanced and everybody already built it and perfected.
But that particular customer, their economy and the use case, the product
outside does not fit their
economy at scale for their economy.
So he was supposed to build it.
So when you make the decision, so I would say the need and the economy of your
business unit
or your company should be also an important factor to make the decision.
>> Thank you, Vamal.
>> Sure.
>> Yeah, my perspective is always customer experience driven from my career
because always it's
about customers, right?
So what does it mean to your customer and your customer experience?
And then kind of wind down to what business process that you're trying to
automate here
and go from the business process to the tooling, right?
So it's always about, in the past we have always bought tools and then tried to
put it in front of the business
and trying to make it work here in a very different situation right now where
we have plenty of tools
available.
So you need to just grasp and say like what business process you are trying to
automate.
And the second part of it is AI is, as I said, AI is just an evolution.
It's a tool being a little pessimistic on that.
It's just a tool.
You have to use it in the right place, not that you have a hammer and
everything looks like an nail to you.
So right now it's here at a place where everything looks like to be solved by
AI.
So I would say like put your business hat, put your business process, which one
you need to automate.
Some may not require an AI, some may require a low code, no code, some may
require just a CRM upgrade or whatever.
So look at it from purely from what lens would make the most sense for your
business and take the right decision.
>> Thanks, Ashok.
Do you want to wrap this up?
>> Yeah, I mean actually just to feed off of you is, you know, I think that if
you think about the priorities of the business,
it's always centered around your customer and your employees, right?
And the opportunities that I've seen from the get-go on AI are related to
support experience, specifically tied to customer support and employee support
experience.
And so there's an opportunity to really, you know, if you look at these AI
councils that we've talked about,
they're looking for use cases that are going to drive real differentiation with
the power of AI.
And the two biggest opportunity areas are customer support and employee support
, right?
And so just being able to, again, focus on measurable business outcomes,
focused on, you know, your customer and really identifying,
you know, what is the experience that you're looking to serve?
And how is your current experience, you know, you know, the issues of your
current experience and what is needed to be able to drive an evolution of your
experience? And then identifying a real partner to invest in that can, that you can
actually, you know, ultimately achieve your outcomes.
I mean, that's what I would say is your biggest priority and your biggest goal
in achieving success.
Thank you. Good point to end on. Thank you, Alvina, Ashok, Vimal.
Thank you very much.
Appreciate it. Good discussion.
[APPLAUSE]