Hi, everyone. Welcome to today's event. Thank you for joining. I'm Paul Turner at Tray, your host for today's webinar.

This webinar is how to cut integration cost and triple developer productivity.

And more importantly, why you need to do this with all the AI pressures, that we're all facing, coming down the pike as well. We have some great advice lined up for you today, and I think you actually can find it a really, informative, hour.

So really pleased, to be joined by my better looking counterparts here, Alex and, and Tulasi.

Alex is a principal analyst with, Nucleus Research, and Tulasi Donthireddy, is a senior director by IT and business systems at digital presence leader, Yext.

To give you a little background on our speakers, before we get started, so Nucleus Research. Alex Wurm leads research coverage of iPaaS, data management, analytics, AI, machine learning, and provides guidance to IT leaders and providers. Did I miss anything there there, Alex? Was that was that all your coverage areas?

That's it.

Do you have a good time to sleep? Do you have a good time to sleep?

We got a couple hours in.

So, Alex, for the event here. So Alex is actually going to take you through the reasons that if you're in IT, or maybe just focused on delivering solutions for the business, the now's the time really to be focused on being more, agile and taking a close look at the the cost of ownership of your existing integration tools.

Because all the dual pressures we have existing business needs and all the emerging needs to deliver agents and, infusing AI into our processes, a lot of pressure points. And often integrations are the center of that as well. So, yeah, take a look at the tools you have and try to figure out if they're the right way to move forward. So welcome, Alex.

Awesome. Thank you for the introduction, Paul.

And then, over at Yext, Tulasi is responsible for implementing solution systems integrations, improving business operations, and he leads an applications team responsible for complex business requirements, turning into solutions, as well. Tulasi is going to take a deep dive, into the drivers of change at Yext, some of the challenges they faced, with the growth, their goals for technology transformation, and also they're going to share some best practices that you can take back with you, after the event. Welcome, Tulasi.

Thanks for the intro, Paul. Happy to share our story.

Great. And then, before I, hand over to Alex and to Tulasi, if you have any questions, please don't be afraid to ask. Just post them just post them during the event. And if there's a right time, we'll answer them, either during or we'll answer them at the end or so whatever works.

And, we'll also share some next steps for you at the end of the event as well. So some actions to take as well. So with that, I'm going to hand it over to to Alex.

So over to you, Alex.

Alright. Thank you very much. Appreciate the introduction, Paul. As you mentioned, I'm Alex Wurm, principal analyst at Nucleus Research, covering the integration and data management markets primarily.

As with any of them, we've had a little bit of mania as all of these different spaces have been reinvented by AI. So, naturally, I'm going to try to walk you through how this applies to iPaaS and some of the considerations we're looking at in our research.

At Nucleus, my research focuses mainly on delivering credible ROI analyses alongside customer driven insights drawn directly from our engagement with end users.

Now this approach is important to us because it ensures that our recommendations really reflect real world outcomes rather than just the theoretical predictions.

So today, I'm going to share a few key insights and takeaways from our recent research.

First, we'll look at the iPaaS market, the state of it in 2025, and how innovations like AI are really changing the scene.

We'll then explore some considerations that I have for investment teams, how they should prioritize their technology decisions, and what features they should look at when evaluating iPaaS solutions specifically.

Finally, I'll set the stage for Yext to illustrate the practical implications of our strategic technology decisions.

First, let me give you a quick introduction to Nucleus. Paul, I'm sorry. Can you just scroll back a few slides there?

Yeah. That's fine. Perfect. So Nucleus is an independent technology analyst firm, and we focus mainly on, value messaging and on real consumer outcomes.

We have published over a thousand ROI case studies over the past 25 years, each validating technology investments with ready metrics that are relevant for those organizations and for financial teams.

To this day, we are still the only registered firm with the National Association of State Boards of Accountancy, providing an extra layer of rigor and transparency to our research that allows financial professionals to trust the analysis that we deliver.

We also deliver advisory services to end users and vendors that build off of this research, following experts in the space.

Now let's, talk about research. There's a challenge to some of the research that we deliver, especially with the enterprise.

Enterprise buyers are really interested in findings that are tailored to their unique circumstances. They want personalization. They want individualization.

And so an ROI model that might fit a high gross SaaS provider rarely maps the same way onto maybe a capital intensive manufacturer, a retailer, or a different type of business.

So importantly, we have to consider things like scale, process maturity, regulatory load, and what competitive pressures an organization faces in order to give a really nicely tailored, piece of research.

So to meet these expectations among enterprises, among organizations, we have two complimentary research tracks that you could see up here.

The first are broad surveys and value matrices.

These help us identify macro trends and present general vendor positioning across two of the most important areas, which are functionality and usability.

These are highly general in any ROI analysis, the solution that is going to impact the most of your users with the most functionality and feature set is going to drive a high return.

So these are good general studies. But how do we feature that personalization and drill into these individual organizations? We do this with ROI case studies and with customer research itself. This allows us to look into line item cost, industry specific measures, productivity impacts for certain roles, and really drill into how your organization could use a technology.

Putting these together lets us address both universal questions as well as situational questions.

The matrix may tell a CIO what platforms excel at usability, whereas an ROI study answers, you know, what savings can my organization realistically book within a time frame.

Combining these two equips decision makers with both perspectives to achieve current results and achieve big picture returns.

Now with that understanding, let's set the scene and review the iPass market.

Five years ago, the median enterprise juggled just over a hundred apps.

Today, that figure tops three hundred.

Every additional marketing automation tool, niche finance module, or AI assistant drops another endpoint into the mix.

Each one admitting data that must be captured, cleansed, and moved in near real time.

The stack is no longer a tidy pyramid of enterprise apps like ERP, CRM, and HR. Now it's more of a constellation with different stars drawn together and piece together.

As you layer AI on top of this, the velocity accelerates further.

Low code model builders using AI let teams and developers spin up new services easier. And all of this innovation transfers into greater traffic and greater application sprawl.

Without a modern iPaaS solution that could actually deal with this scale, you're going to encounter greater challenges.

This is why the market is gravitating specifically towards cloud native iPaaS solutions.

These platforms ingest streams, apply governance, and can scale horizontally the moment a new AI service goes live, so you don't have to rewrite or rearchitect your system.

In short, it gives the organization more agility to adjust to new services as they come live.

Now let's address what many teams have discovered the hard way over time.

The first generation of iPaaS simply hasn't kept pace with the way that we build software today.

Workloads arrive as real time event streams, updates deploy continuously, and AI services expect millisecond responses.

Yet, licensing for many legacy tools is still pegged to connector counts. So every new endpoint increases OPEX.

To plug these gaps and control costs, teams bolt together on point solutions. They add an API gateway here, a low code mapper here. And engineers end up integrating these integration tools just to keep their data moving.

In our research, we've shown that this patchwork alone drives 15 to 29% higher total cost of ownership relative to a unified platform. While siphoning 60 to 80% of the average IT budget into maintenance instead of innovation.

This hits and hurts the most in agility and productivity.

Every extra integration challenge pulls developers off road map work.

Release cycles slow, customer wait time stretch, and promising ideas stall because the plumbing can't keep up.

When dollars and developer hours disappear into upkeep, integration stops propelling growth, and starts blocking it.

This operational drag means that teams often become reluctant gatekeepers rather than partners for the business.

Now switching on to agents, Paul. Thank you.

AI agents have moved from a proof of concept over the past year to production, and this shift exposes two main pressures that are relevant to integration.

The first is API management.

Second, agent orchestration.

AI agents often depend on tool use, which usually means that they have and necessitate clear API documentation, valid secrets, stable endpoints, and reliable connectivity in order to do the workflows that they're assigned.

When any one of those is missing, the agent stalls out, and the user sees an error instead of an answer, completely independent of the model performance.

AI agents as they stand now are also far from fully autonomous, far from agentic AI as we're being pitched.

Most real world tasks currently involve several specialized personas or different roles of these AI agents that work congruently in order to complete a task.

Without a single place to coordinate these agents, tasks slow down and mistakes can creep in.

Modern iPaaS solutions form this foundation.

They keep every credential in one encrypted vault. They apply the same rules to every request, and they record a single log that everyone can trust.

They also are starting to include agent builder systems that allow teams to lay out personas, connect their steps, and run heavy workloads across MCP servers, across emerging A2A protocols, and move data straight between apps without additional middle layer.

The result is just much better organization, observability, and visibility into processes that currently lack all three.

Integration becomes the operating layer that keeps AI innovation fast, safe, and scalable.

In other words, modern integration platforms act as this facilitator for AI rather than just another layer of infrastructure to manage.

So here's a checkpoint question that every architecture review should start with.

Is our iPaaS actually ready for AI?

The iPaaS that wins tomorrow will not be the one with the biggest connector catalog like some might market, but it's going to be the platform that best supports expanding AI services.

Integration now sits on the critical path for every AI feature.

Agents can only act as fast as they could hop between different systems. And if the integration layer lags, the agent stalls no matter how smart the model is.

We expect two factors to really separate the leaders in this next stage of iPaaS from the laggards.

The first, as we previously mentioned, is real time orchestration across agents, bringing together these different roles.

The platform should broker calls between different agent personas. It should handle retires and route messages based on live context.

The second capability is dedicated monitoring and visibility.

Platforms should provide unified tracking and usage analytics showing exactly what each agent is doing across apps. So teams can spot issues, optimize performance, and see when a human is necessary within the workflow.

When these pieces come together, they allow you to go into production in much shorter of a time with new features, especially AI features.

Next slide, please, Paul.

So all of this comes back to a single question. We have a lot of value. We have a lot of innovation, but we can't just be making reckless bets. How do we fund this innovation without taking on unnecessary risk?

First, I would like to make a clarification, one that I think is important for iPaaS. Traditionally, these tools have been, sort of nice to have. They piece together systems, you can do it manually.

They automate systems, you can do it manually.

Now it has become a foundational technology, an enabling technology that will provide additional value with time, to a greater degree than it had before.

So what do you have when you have a foundational technology? You have rising opportunity cost with time. If you wait one quarter, the opportunity may decrease the value that you're able to see.

Forecasts are fuzzier than ever, but you have to act quicker in order to capture the, early lag of this value.

Integration itself is a multicycle asset, so you have to live with your choice of today's integration platform longer than you would for a lot of different apps.

Because of this, we want organizations to view their technology decisions specifically with foundational technology as continuous.

Remember that foundational layers rarely get swapped without pain, and a flexible iPass unlocks additional revenue streams with time.

The future value should likely be attributed a lower discount rate. What you're looking for in these solutions are ones where the magnitude of the value expands with time. Typically, with iPass and with innovation, this is hard. There are new paradigms that come up that decrease the value with time, and specific point solutions are typically designed for a specific integration pattern.

Adopting the solution that is specifically ready for AI is going to allow you to avoid this rip and replace and avoid the unnecessary costs that come with choosing an improper platform.

Now by contrast, when organizations do have to rip and replace, it usually signals poor decision making and poor processes in evaluating solutions.

Investing in dedicated process and collaborative decision making can significantly cut these costs and improve the value that these solutions deliver with time.

Now let's let's review.

Foundational technologies like iPaaS deliver immediate savings through their ability to cut costs and reduce the operational overload.

But their deeper value lies in on not in unlocking new revenue paths and agility with innovation.

As flexible modern iPass solutions make launching services faster and less risky through reusable connectors, governance, and monitoring, and now agent orchestration and management, innovation becomes simpler and organizations can adapt faster.

Because switching foundational layers is hard, selecting a vendor with clear AI roadmaps and open extensibility is critical.

Ultimately, your integration choice today determines how quickly you'll be able to adapt when market conditions or technologies eventually shift.

When evaluating candidates, you should ask, one, will this platform accommodate the next generation of AI and agentic models without major rewrites?

Two, does it support modular upgrades to avoid forklift migrations?

Three, can it scale economically? Does the value of this solution expand with time as event volumes spike, as integrations increase, and as the number of applications needed to integrate and agents needed to integrate increases?

Answering these questions upfront ensures the integration spine becomes a long lived asset rather than a short term patch.

In other words, your iPaaS platform will become a part of your strategic advantage, not just another tool to piece things together.

With that, I invite Tulasi to share how some of these examples come into fruition with real stories.

Thank you, Alex. And, that was great research and, well put, just, you know, single word. We have to build for what's next.

Having said that, before I dive into the transformation journey, let me briefly introduce Yext.

Paul, next next slide, please. Yext is the leading digital presence platform for multi location brands. It helps organizations manage and scale their brand presence across every digital touch point to be it in search, social, chart, listings, local pages, all from a single platform.

It brings together AI powered capabilities, everything from generating SEO optimized local content to handling reviews at scale. With generative AI, the platform ensures that companies show up consistently, accurately, and effectively everywhere their customers are searching. So, companies would not lose a customer, if they're searching for their brand. So that's the worst thing that should happen to the companies, and that is where we help companies, get connected with their customers. In short, Yext turns digital presence into a true differentiators, powered by AI, unified by one platform.

In my role, as a lead for IT and business applications, so my focus, is on modernizing enterprise systems, to drive agility, visibility, and scale, so that the business teams can, move faster with automated workflows and, AI powered workflows. So that is where I'll walk you, through how we transformed our integration landscape, to unlock, automation at scale and accelerate innovation across the organization.

With what Alex mentioned in his research, why we should look for a modernized, enterprise system, which includes iPaaS. IPaaS is this key key platform, I feel connecting all these business applications, so that they can seamlessly, automate the workflows for your business users.

So let's dive deep into what we have done in that journey.

Let talk about challenges. What warranted us to move to Tray and pursue this transformation journey. Like many other organizations, our integrations evolved, actually one team, one system at a time. We ended up with multiple tools across departments, with no centralized monitoring and heavy reliance on custom built reporting using BI and data warehouses and our integration engine, the previous one, it technically worked, but the logging wasn't effective. We had to route logs externally to understand if there are any issues. Troubleshooting, used to be cumbersome, when those broke.

And there was no real time alerting which I feel is an important feature. So we built it ourselves into the platform.

And with IT, owning one part of the flow, analytics, another, and then there is operations, used to own another piece of the tool. There was no end to end accountability. Workflows across, across platforms and there are there are manual handoffs especially for logs, error handling, meant we we were constantly firefighting, I would say. So which, yeah, is a high, operational overhead.

Paul, can we go to the next slide?

Now the next challenge is innovation.

So, like, again, it resonates with what, Alex presented. Our previous platform was technically strong, but, I feel it was operationally rigid. For minor updates, it required deeper developer expertise. Adding a new business system, which happens in the transformation journey for any organization, the new tools are coming up. We need to keep, up to date where to address, the business pinpoints across the, tech stack. So if you want to introduce a new business system meant long lead times, you have to customize the scripts, and you need to handle a lot of manual change requests.

So, through reusable, connectors, I think, they existed, but modifying them, without breaking something else was too risky.

So most automation was locked behind the integration team, creating a backlog. So empowering, business users was basically out of question.

And, this wasn't a tooling issue. So it's more of a delivery model.

The platforms were enterprise grade, but they are not, agile. They were heavyweight, but not fast. So innovation basically slowed, not because lack of ideas, but because how hard it is to implement them in that platform.

Paul next slide.

Now growth challenges. As we expanded, we made an acquisition last year, and, we might do some acquisitions as a company, eyeing growth, and compete in the space we are working on. So the architecture struggle to keep up during this M&A or integration processes. So we couldn't scale elastically and tooling costs grew linearly with the data volume and environment counts.

So increased pricing or cost if we need to expand our scale, was a big challenge. And there was no out of the box, centralized audit log or a health dashboard.

So when we onboarded more departments, the complexity grew and, we didn't have the visibility we need to manage the day to day operations.

To keep these things running, we leaned on work around scrapes, middleware patches. But, that only compounded the problem. So we were using enterprise grade tooling, but maybe solving, the problems with duct tape.

So now, next slide, Paul.

Question, Tulasi. Making a making a move from an existing from your existing API management platform. It's no small task. You've shared some of the challenges around your growth and you had obviously fragmentation, visibility issues, and just the need to move faster. Was there a moment where it went from thinking about it, to okay. Now we need to make a move. What was that what was that exact pressure point? Was there some trigger triggering moment?

Yeah. So, it's a continuous practice. As an IT leader, you look at the platforms that are high performing and what is your goal, that you set for your department for next two years, five years? And, what's happening in the industry. Talk of AI and your business goals.

So are you able to support these goals with your current tech stack and how fast you are turning around these requirements that you are getting. So this, basically encouraged us to define the problem. So what are your current painpoints with respect to cost, inefficiency, risk, and lack of agility.

And then we tried aligning that with the business goals. And, we decided, hey, we should, go and look out for a tool that can give us this business benefits that we are looking for, and then we started this, journey.

Thanks Tulasi.

So, again, speaking of the goals maybe it's an extension to your earlier question, so what do we want from this platform?

Basically we needed to pivot. I know what our pain points are, we discussed the challenges, from being tool centric, to outcome driven, and, our North Star became clear. I know integration should enable growth, it should not limit it. Which meant unifying the architecture across the business units, enabling self-service for business teams, hyper automation for repeatable workflows and reducing IT friction to let ops move faster.

This aligns with what we are seeing across modern enterprises. We refer to a number of researchers like what Alex presented. A shift towards democratized automation, not just connecting systems, but empowering people to build with confidence.

A quick question Tulasi. I guess all these aren't created equal, these goals. Going back to some of the areas where Alex shared as well, there's efficiency aspects, getting your arms around and getting to a more cohesive integration architecture. And then obviously decentralizing so your your business teams can build. Cost savings. Was there a key goal, like an an overarching goal? The the the big one? That you're like, this is the must have goal for the project to make the move?

Yeah. So the bigger goal is hyper automation. So where you want to automate the repeatable tasks again with efficiency, and how much, faster you are turning around the requirements and focus on strategic initiatives.

So freeing up some bandwidth, for the developers so they can focus on building what's next rather than trying to troubleshoot issues. The bigger goal I would say is are we building for the future? So are we planning for the future, the hyper automation, which includes this rolling out AI agents, rolling out automated workflows for all the repeatable tasks to bring business efficiency.

So indirectly as a business applications or an IT org what you are impacting is the faster product rollouts, and, the customer facing teams would be able to perform their jobs with ease and without much running into many issues. Be it your sales teams, finance teams. In the back end, our teams are empowering them to make their job with much efficiency. Having an integration platform and doing what I mentioned around, in future we are trying to roll out IT agents, which I will speak about in a bit and then hyper automating all these repeatable workflows.

It was need of the hour if I have to mention.

Speed and velocity was a key goal?

Absolutely.

And, I'm curious. I I know you touched one of the challenges being the backlog. A backlog request. Were you seeing that backlog in the building, or where was the demand coming from on the backlog? And then how did you see that growing with AI and those areas of new business demand?

Yeah. We are planning for our teams, I think, the different business units have a roadmap of items that they want to roll out. Be it changing the strategy or changing the selling process or changing the finance models, pricing, NPIs, new product rollouts. So there is a constant transformation happening on the business side, and we have to support them at the same pace. So these requirements keep coming to us and they stay in our backlog. And we have to address based on prioritization there are screens and, stuff like that.

If we fast forward, there are some requirements which the users can build by themselves. A simple flow like alerting when a new deal comes in or a deal for this. So these sort of small workflows, the business users can develop themselves. You have a connector to CRM. You go, log in and, pick an alert. There is a component that tells you how to build a flow. So these things, the users can do it themselves. They don't have to wait for the integration developers to come and help them.

So, that actually freed up some bandwidth, and we can focus on the larger initiatives and, help, build those automations or integrations, which are critical to the business systems.

That way, I think, there was this efficiency that we brought into the picture. Overall, does that make sense?

Yeah. Another thing you mentioned, and Alex touched on as well is future ready. Is the stack is the technology you've got today the right fit for the requirements you've got coming down the pike?

And obviously, every IT organization, every business is looking at AI. Whether it's with agenetic or infusing AI into business processes or RAG or those kind of areas. We're curious obviously, how did you see your iPaaS as an enabler to help facilitate some of the AI projects you saw coming down the pike?

Yes. That's a very good point, and that's definitely happening. Discussion everywhere. Not in our organization, but whomever I talk to in my peer network.

So the agents are already here. I think some companies are adopting them in a much faster fashion. But, so the iPaaS platform is key, what I feel, to enable those agents. So I'll take a simple use case, and, I think Tray, also implemented an ITSM agent, an IT ops agent, which can basically solve some of the issues that your IT agents, the human agents, resolve like access provisioning issues or deprovisioning or troubleshoot some of those errors.

So these things can be implemented now. When you have the right data and right API connections and you have a tool that can, support that integrations to different platforms in a seamless way. So these are becoming reality now. The same integration developers can use those components and build an agent in conjunction with any of the AI models that you are using.

So we can call the API of the agents and then build an agentic framework to basically build an actual agent which can think and troubleshoot and also action on a question. So, there's a difference when we talk about agents. For the first part, the chatbots which provide the right answer or right data which we have rolled out.

Again, apart from the IT agents, and this is becoming much more common practice within the business units. Earlier, you would have to refer to a bunch of folders in a Google Drive. Now what we can do is you can connect that Google Drive to a chatbot, and you can ask a question.

The bot can just look at all the documentation and give you a specific answer, that you need.

So that you can extend it to to build an agent with some action where it can go to a connect to an application and perform a business logic and throw you a outcome in a Slack channel or in your email.

We're already working on it with a few of the models that Tray has built into the platform.

Yeah. That's a great point. I think some of the areas that the folks often don't think about when they're building agents beyond just knowledge, taking action is really important. So it has to be more than just simply search. In ITSM, for example, you take action creating a service ticket or a password reset. Actually acting on behalf of you and actually performing the task.

I think that there are other endpoints as you mentioned that you might have an agent, but, ultimately, you got to integrate the agent with a user interface whether it's the website or a Slack channel. Your users have to be able to interact somewhere conversationally or towards a triggered agents.

And, obviously, data as well. The agent's only only as good as the data. If you're going to ingest a partial source or a narrow set of sources your agent's not that equipment necessarily for the right answers, as well.

You'll jump onto outcomes, Tulasi? Obviously, I know you've been real busy over there. Yes?

Yes. I think we, spoke about a few of them, but just to quantify, the outcomes the transformation was tangible and we reduced our build cycles, from three days on an average to one day.

The business users could build their own, workflows now without filing tickets and waiting for the developers to respond.

We eliminated some redundant tooling and cutting some licensing and operation costs, which brought in 60% cost reduction. And, we see it's compounding, every day and every now and then when we, roll out some cool features, like say, these IT ops agents, so on and so forth.

And most importantly, the adoption I would say it's exploded. The nontechnical users, they became a kind of automation builders for simple straightforward tasks. And, IT shifted to architecture strategy, rather than, debugging workflows. So, basically, it was, not just a tool upgrade, but, like I said, it was an operating model shift for us, which brought agility into the team, and then the framework.

Curious on that final area where you're growing your builders by empowering business teams to build. How important has that been for you to reallocate your developers to other tasks? What's that meant for Yext? So rather than building integrations and enabling business team to build and then, obviously, your developers can then obviously focus on other things.

Yes. That's, a very good shift or, observation which, we are experiencing now.

The freed up bandwidth, based on the initiatives we are working on, we actually need more, bandwidth now to tackle those tasks. For example, these IT agents, I think, there's a lot of focus on building those. Now just we just spoke about one example, for IT operations. So there are a lot of business operations where we can replicate those agents and solve some problems with these agents, take care of some of the repetitive tasks with the agentic framework.

We need a lot of hands to build those robust frameworks and also, learn these models. They are evolving every day. There is something new that is coming up, be it, Gemini, OpenAI, or, Claude. So we need to keep up to date with those frameworks and leverage any new capability that they are rolling out.

So there is, a lot to do. And then, for the business users, again, it's, while we are saving bandwidth, for the developers, the business users, again, they are finding more ways. Sometimes, they might see, they might be doing those repetitive tasks and might not translate into the requirements. Now with the tool available they can just experiment and build a simple workflow for them so they can automate those repetitive tasks. So it's a, win win on both sides for us.

That's great. Just some outstanding results. I'm wondering how long it took you to build those hundred plus integrations originally, and it's pretty impressive for a hundred plus integrations migrated in three months.

Three months. Yeah. That was, even, in my experience, I think this is the first migration project that we delivered before the timeline. I can say.

Yeah.

You always see some issues. We cannot plan a hundred percent perfect timeline for any of these migration efforts. But once the developers got the feel of the components and the workflows, they were building those, super fast flows and migrating them, over to Tray.

I think it's a great segway, obviously. It's one thing whenever you're in IT and you're tasked with the migration. There's a a small amount of sweat, a little stress around that. And, make sure it goes smoothly and that, you've met the requirements. And there's no mismatches between the tool you had and the tool you moved to. I know you've learned some lessons along the way as well. I think best practices will be ideal for our audience here. There's some things to think about when when you make that move.

Definitely. Because, we were not just doing a lift and shift from one platform to platform to another platform. We're utilizing that opportunity to learn and do things, differently and in a better fashion than before. So what worked for us while we were doing those migrations is I think reusable components. I would give your top priority whether it is a fresh implementation or doing a migration try to identify those early in the stage and develop some templates which you can reuse later. Or, we were talking about enabling the business users to automate their own workflow. So these templates can become handy when you are doing some training or providing or creating an enablement program for them. So focus, when you are, designing, your workflows, integrations, identify those reusable components and, that would come handy in your journey.

And the second one is, early engagement, with the business users. I think this is your opportunity to engage them again, to understand, the actual requirements.

There would be an opportunity to streamline some of them, optimize some of them, and improve some of the, integrations that you might have developed, many years back. So, take this as an opportunity so it will help, for the future engagement as well. So involve business users, early in the stage.

And real time monitoring, we have beautiful out of the box dashboards and, the alerting mechanisms. So visibility, wasn't a afterthought. It's basically a requirement. So when you build some integration, I think you should be able to monitor and identify any metrics or it should be easy to troubleshoot.

And, the logging is critical for being a public company. We want to keep the logs and for any SOX compliance or audit, you have to retain them and use it for any evidence or, for any, audit and testing to some of the controls.

I'm curious on the reusable components aspect. Obviously, a big focus here at Tray, composable development. And we have building blocks so you can reuse. Obviously, it helps with the maintenance. And also, ensuring that these templates are certified, you know they're strong, they're proved out integrations that your business teams can then take. Do you consider yourself forming of a center of excellence? Do you have a center of excellence kind of thing on the delivery side of things?

Yeah. Now we are working on a structured enablement program where we created role based onboarding and reuable templates, some support and governance, like co building workshops.

Basically, you need to create that process so that the business users are not completely on their own. Like you mentioned, maybe we can call it as a center of excellence. So there is a team that is available, and there is some artifacts, documentation, these templates, and playbooks they can always use before actually reaching out for some co building workshops or, any other help. So definitely, these things would be helpful once you create those structured enablement programs for the business users.

Got it. I know. I think six of the best practices here, Tulasi

Continuously optimizing the workflows, especially when you are adapting a new tool, you keep learning while you build over a period of time. It becomes as a part of your rhythm. The best practice I would say, again, not just during the process of migration, I think every quarter we, review and clean up any inefficiencies or any unused workflows so that the system is always clean.

And, self-service, like we spoke about creating those structured enablement program, will actually bring in more power, to the platform. And we we spoke about democratization of the automation platform. So that's the self-service piece.

And cross functional ownership, now with breaking the silos, the IT ops and data, there's a lot of collaboration. Now it's more of a shared goal, rather than hand off. Earlier they all work together on bigger initiatives and, outcomes.

Next slide. We have ten minutes. So next steps, I think, having, made the, move, to Tray and, like, we spoke about while answering some of the questions, I think, the major next step would be getting, into a intelligent integration platform, which can support building IT agents for specific use cases, and then, expand. I know that Tray adoption across the departments, when we, finish this enablement program so we can roll it out to all the business users. And, yeah. Few of them that we listed. But what, I can summarize is we are laying the groundwork with clean architecture, observability, and modular design.

That's what will let us plug in into AI meaningfully, and it can become a multiplier for our future road map.

Perfect. That was a great, summary, Tulasi. Thanks for sharing your experience running through this at Yext. I think you've been pretty busy by the looks of it.

We are. We are.

It's not just me. I think in my peer group, in different companies, I think with AI everybody's looking at future, building for what's next within the business organization or within IT. So how we can get those benefits, to business users and then thereby providing that best customer experience, using our products. So it's a great place to be in, with what's happening in the AI world versus the business systems and combining, the best of both worlds. It is a great learning for everybody, in this in this area.