To build or to buy?
- Posted on
👤 Featuring Ravi Chandra & Angie Judge
Should you build your own analytics solution—or buy one off the shelf? In this episode of The Data Diaries, Dexibit’s CTO Ravi Chandra joins CEO Angie Judge for a candid conversation unpacking one of the most critical technology decisions facing visitor attractions today.
From total cost of ownership to technical debt, from customization dreams to capability nightmares, Ravi and Angie break down the risks, trade offs, and hidden complexities behind both paths. They share war stories, practical advice, and their deep product and engineering insights to help you make smarter strategic choices in your digital transformation journey.
🔍 Whether you’re a museum, theme park, zoo, or cultural institution—if you’re grappling with the future of data at your attraction, this one’s for you.
🧠 Learn how Dexibit thinks about platform design, scalability, innovation, security and more.
📌 Subscribe for more smart conversations at the intersection of technology, data, and the business of experiences.
Transcript
If you want go from gut feel to insight inspired, this is the Data Diaries with your hosts from Dexibit, Pierre Perez and Angie Judge. The best podcast for visitor attraction leaders passionate about data and AI. This episode is brought to you by Dexibit. We provide data analytics and AI software specifically for visitor attractions so you can reduce total time to insight and total cost of ownership while democratizing data and improving your team’s agility. Here comes the show!
Angie: Ravi, tell us about this. You’re probably the best person in the world for me to ask this question. How hard is it to build a data product?
Ravi: Maybe the best way to answer this is first to zoom out a little bit. Why do we want a data product for the visitor attractions in the industry for our business? I think it’s really this recognition that data and insights, it’s critical to running a modern business and in order to sort of clear that bog and improve visibility so that as operators you can understand where the problems are, see the opportunities to improve performance.
And with that visibility at all levels of your organization, you are equipped to take better decisions. And through those better decisions, you can improve the impact that every individual can make. So I think it’s, we’ve all realized that data and insights are critical and to me it’s, they’re our leverage that we have as leaders.
There’s a great quote by Archimedes, if you give me a lever long enough and somewhere to stand, you can move the world.
And we will get very excited about that. And I think that’s why we’ve seen so much growth and interest in data, in recent times. However, there is a little of nuance to this and I think we’ve also seen sometimes organizations take this a little bit too far in overreach and they end up in this sort of quagmire.
They think they’re doing the data and insights thing, but actually what they’ve ended up doing is getting bogged down, worrying about, building rather than driving impact through insight and answers. And because this is what we do at Dexibit day in, day out, we have realized through hard for real world experience that it is actually really, really hard to build a great data product and deliver a fantastic data experience where users and leaders at in all parts of an organization can see how they can use it within their workflows, within their day-to-day to make an impact.
Angie: Yeah. And it’s no surprise is it that the research shows, I think Gartner says what 85% of big data projects fail and you can kind of see why, like, for us, it Dexibit but it’s our life’s work to produce a great data product. But it is, it’s tough. It’s a hard job!
Ravi: That’s right. And I think the challenge, that you face is that. Really what people want and what delivers value is that pot of gold at the end of the rainbow.
But to get that and to deliver that to chase the rainbow requires so much work. And it’s that tip of the iceberg problem where a lot of it is invisible and it’s unknown to the end user or the consumer. And that’s why I think it’s easy to get carried away. and not realize what goes into building a great data product and to make this really real and concrete.
A big part of what we do is spend a lot of effort in plumbing, basically connecting all the pipes to ensure that data is flowing from source to destination. Just like the pipes in your house that you never really stopped to question unless there’s something wrong. It probably took a lot of planning and effort to put them into place, and it’s a big part of, building a data product that often gets underestimated. Then on top of that, there is the performance. Is everything running fine? Is it fast to load a dashboard? Does everything arrive in your inbox at the time you expect it to? When you log in to look at the data, how long do you have to wait?
Is it go make a cup of coffee or is it instant so you can start digging into it? The performance is a big part of what we invest in, and we are constantly trying to improve that side of our product, because we think it, it plays a big role in democratizing. Data for everyday users in a big part of the user experience.
Because what that means is if you’ve built an in-house data solution and it takes 10 minutes to generate a report, it really affects how you choose to interact with data at an organizational level. One of the things I’ve noticed is that organizations are very malleable and they will adapt to what they have to work with, and they then become that they internalize what data means for that organization based on what they experience, and they just become used to it.
It’s hard to know if you’ve gone the build route, whether you are actually at the forefront of what’s possible. Or you are actually behind the curve and others are doing it much better, much more efficiently than you are, and you are missing out on all of that value and impact that could have been, available.
Angie: If it’s gonna take you two years to build something, by the time it’s all said and done, where you’ll be at, then by the time everybody else has leapfrog over top of your position of where you’re planning for now. And it’s, funny you talk about, the performance thing. We get two types of customers who come and talk to us.
One is customers who have never had a data solution and they’re making that first time decision. The second is people who have tried or even have built their own data solution only to find that performance problem comes to bite them, or the innovation problem comes to bite them, or the cost problem comes to bite them and then they come back and say, Hey, it takes our, you know, our system, five minutes to generate a query and can you do it faster? Well, the reality is that our performance is more like one or two seconds to deliver the same result. So, it’s, yeah, I think they’re really real problems for people who are sitting out on this journey.
Ravi: And I think the problems don’t stop there. Once you’ve delivered that report, the next thing that you’ll almost certainly encounter if you want to get traction with data in your organization is the needs from a diverse set of stakeholders, all with their own questions, their own business questions to answer.
And one of the mantras we have at Dexibit is providing insight for any question. What that means when you’re building Euro, building it yourself is you often have a queue of requests that start to accumulate and how you respond to that in order to convert that into answers to feed the rest of your organization is actually quite a critical element that often gets overlooked.
Because you’re taking on so much more operational burden by building yourself. You’ve gotta keep all of that plumbing working, stop the leaks, think about performance and optimizations. But then on top of that, how do you find time to, to model and understand the domain that you are working with? And in order to answer, all of these different questions.
So for some real examples, you could have questions from. On the retail side of the business about, product sell through rates or come could come from marketing or around social media engagement. These are all wildly different business spaces, but they’re all part of a complex contemporary visitor attraction.
And if you have to model that every piece of data in order to build a report. It becomes a huge amount of work and these teams, they stop asking, and I think that’s the worst thing that can happen because you saturate your capacity that it turns people away from data insights. So it’s almost like the antithesis of the original goal that organizations start to trying to solve.
Angie: Yeah. If you’ve got one person in a corner office or in the basement. Doing the data for everybody else in a queue out their door of people with requests for, can you build me this, that, and the next thing? You’re, doing it wrong at that point, right? Like, we’re all about democratizing data and from our product that also means about self-service and, data literacy and supporting all of these sorts of things.
And we firmly believe that you’ve gotta have that to have the agility to make not only decisions on a real time basis, but to make the culture of it all work.
Ravi: That’s right. Have spent some time thinking about this problem. And what we’ve really come up with is, first of all, we’ve spent a lot of time in the industry speaking to customers, understanding their needs, and we have a very good understanding of the different domains within the business.
What we’ve tried to do is to bottle that secret source and embed it within our product, under the banner of what we call, our semantic layer. And that gives, most businesses a huge head start and leg up around what it means to be operating a business within the space and what their needs are in terms of data.
So on top of that. They can leverage what we built to then sprinkle in their secret source that’s unique to their business and customize our product so it meets their needs.
Angie: Yeah, that’s a really good point. And I think, in the visitor attraction sector, this problem is especially intense because they are really complex business models.
Your average visitor attraction. Sales tickets to the gate, maybe extras for exhibitions or events or, other experiences. And maybe they do tours and maybe they host weddings and maybe there’s corporate hire. And then on top of that, they’re running food and beverage and, retail and maybe a hotel even, some parking and everything else.
So they’re really complex when you start to bring all of these together. And then you layer membership maybe, or season passes and advancement and. What they’re doing online. And then maybe collection management got huge risk management to take on board and big operational and security teams. Like, it’s never ending.
And it’s different to running a shoe shop where you’re got a pair of shoes with a price and a data point that arises when you transact. And that’s about it. And so I think it’s a problem that’s especially felt by this industry.
Ravi: Absolutely. And I think it’s almost ironic because it’s that complexity that sometimes drives leaders to think that they are special and they do need a custom bespoke solution.
But actually in fact they really don’t, and they probably don’t have the resources and expertise in order to take that complexity. And realize that, so there is a spectrum, right? Between build versus buy because you could buy everything. You could buy something that’s customizable, you could be working from a bag of bits, some that you bought and some that you’ve built and be assembling things…
Angie: and essentially building…
Ravi: at that point, and essentially building at that point. Or you could even use off the shelf bits and be building everything from scratch. And I think with that nuance, there’s actually a range of solutions. So we’ve learned early on that businesses are complex and they need to be able to custom, we need to be able to customize our product.
And so we’ve baked that into our product experience. We are designed for you to plug in and bring your business rules, bring your special needs, and bring the obscure. Or the special data sets that’s unique to you and take it into our product rather than, have to do that from scratch at one end of the spectrum or say, no, we can’t support that at the other end of the spectrum.
Angie: Yeah, because thinking about all of those different domains that we were just talking about that, that you’d have to have that knowledge or be able to orchestrate that magic across that technical business barrier, which is one of the hardest parts of building technology. There’s also, then, when you get into the data space, there’s lots of different skill sets that you need, right?
Like there’s the Insights leader who can translate things into executive speak. There is the product manager who can kind of, keep a team on track and help execute vision down into operations. There’s the data engineers, the plumbers of the world if you like. The scientists who are experimenting and researching with different models, your analysts.
And so you’re talk, starting to talk about quite a big. Team overall of these different skill sets to build it up. And it’s quite easy to see how we’re not just talking about a six figure investment to, to build, we are talking about something in the realm of seven figures Plus when we start to get into all of these different areas.
Ravi: I think you’re right and you’re touching on the realities of what it means to do this. We know that, the Tran recently posted that there. A typical customer spends at least $300,000 per year just on their data warehouse technology, and that doesn’t include any of the labor costs to, to maintain that.
Angie: Is misleading with some of these, big players, they might sort of use the micro pricing when you’re looking at sort of $2 here for compute costs or something on a credit. But it adds up when you’re talking about the volume of queries and the data that you’re processing through some of these platforms.
Ravi: That’s exactly right. And to understand the nuance of how these. These pieces of infrastructure, data infrastructure come together. How they build, how to make the use of how to make the most of their performance and use them effectively and efficiently. It requires a lot of deep expertise and knowledge and comes forward with many unknown unknowns.
And it’s only really when you are knee deep in it that you start to, to see these challenges and gaps emerge data and insights. It seems to be an interesting space where it feels very easy to get started and if you’ve got people within your organization who are quite good with a spreadsheet or a little bit technical, you can see how it escalates from belief and with a bit of confidence.
You can see how it escalates into, like, we think we can do a bit more. We can take this on, but it’s. But organizations often sort of have this stunning Kruger effect, if you’ve heard of that, where you might think that things that you don’t know very much about appear to be easy, but you overestimate the effort in areas that you do know a lot about. And I think this is one of the classic pitfalls of the, to build versus buy decision.
Angie: And just to add to some of those costs that you were talking about before. When we’re talking about building out that whole team, I mean head of insights, we are talking what in the US north of 150,000 a year.
Product manager, maybe one forty data scientists, one forty data engineers, probably about that. Analyst, maybe 85 to a hundred. Like we’re starting to add up some very serious resources to be embarking on a project that we’ve got no guarantees at the end of, and a team that presumably have never come together before to do exactly this. So it’s all breaking new ground into white space, which is the hardest thing to do in technology.
Ravi: It absolutely is. And don’t get me wrong, I think it’s amazing to grow your team and take on more talented, people within the space. And I firmly believe that they could add a lot of value to your organization or any organization.
But I think what’s important is to ensure they’re steered in the right direction, working on problems that are valuable. And a part of that is using the best tools out there, not necessarily building your own bespoke tools, because that’s not going to unlock and drive value. And I think it’ll become hard to continue to argue for those budgets if you go down that path, spend two years to, to build. And don’t have those results to show for it.
Angie: And it’s, it also improves out in the numbers as well of the realities of the insides of some of these teams. Like I think embarking on a data project sounds. And feels very sexy from the outside. But get into the inside of it. And like you’re talking about data engineering being sort of the plumbing.
I had a trades person run at my house this morning, you know, unless there’s sort of a painter who’s. Leaving you with a beautiful house at the end of it where you can stand back and say, wow, that looks incredible. If it’s a plumber who comes in and fixes a pipe, I mean, it’s a very thankless job.
And data engineering, and keeping all of the things connected and all of the lights on and making sure nothing fails and cleaning up when it does. Is a very thankless job and like the average tenure of a data engineer on an in-house data project is under two years. It’s closer to one than it is two.
I think, overall in the states, some of the research shows that the average tenure for any data engineer is about 18 months. And it just goes to show like this is the reality of executing on some of these data projects, and that’s a real challenge. I think when we’re thinking about total cost of ownership, like there’s the time that it takes for you to get from zero to one and what you do beyond that, there’s the cost of all of these resources added up and all the different component parts, but then there’s also the risk.
There’s like the risk of will we make it, and then the risk of whether these people will be. Ones that stay with us through the course of, of the lifetime of the project. Even, you know, if it takes a couple of years to get there, that might be several generations of data engineers under those timeframes.
Ravi: That’s a real, very real risk. And with that, that turnover goes, the organizational intuition knowledge about a lot of these systems and about a lot of the plumbing. When you talk about plumbing it’s critical to keeping everything running. So it’s an underestimated and an undervalued risk, in my personal opinion.
One argument to mitigate that risk, which you see often is that there is a lot of, services and off the shelf connectors that can be used to avoid some of that plumbing. However, what we’ve experienced is that. They’re very general. And for our particular industry, a lot of the sources and systems are very bespoke and obscure and you just simply cannot find off the shelf connectors.
And often this is one of the ways where a build project starts to build steam because they can start with the easy stuff with some off the shelf connectors for Shopify. Or for Facebook for instance, very common. But then once it’s, once you get into the really hard problems of ticketing systems and football cameras and food and beverage systems and point of sale things [00:21:00] start to get a lot more tricky and complex, and that risk is not front loaded at all.
But it’s pushed at the back end of these projects, which is why they can somehow feel like they’re stalling. And I think that’s a failure mode that we’ve seen play out, a number of times, unfortunately.
Angie: Can we talk about one of the elephants in the room, which is, you know, that tech teams love to build?
I mean, you and I have had our careers in technology, so we. People who love to build things. And there is sort of two pathways when you get into a technology career where you can work in a product company. And build a product. You can work in a service company and essentially do consulting, or you can go in-house and you are constantly faced with this pull between buying things and watching other people build them or building them yourself, which is a very big temptation.
I mean. How do you wrangle with that yourself and for your own team? Because even within the software that we do build, there’s lots of decisions that we make to buy things or build things with the various components that make up that product.
Ravi: I’m an engineer and in my heart of hearts, I love to build things as well. So I’ve been bitten by this. Bug, so to speak. But I’ve spent a bit of time in, in academia as well, and one of the quotes that’s really stood out to me is, academics often to talk about standing on the shoulders of giants. And I really like that mindset to think about what we are doing in the engineering and IT space now.
And data and insights. Just because you’re not starting from scratch, it doesn’t mean that you’re not able to contribute in a meaningful way. I think it’s really just understanding and being cognizant of what you’re building and whether it is the right thing to be building and to be very honest, we’ve made mistakes at Dexibit as well.
I think there are a few decisions that we’ve taken that we now regret where we’ve. We’ve been thinking about the build versus buy spectrum and we’ve, taken a decision that we now regret, for example, to make this really concrete, we chose to build our authentication and authorization service within our product, and that’s largely under the covers for most of our users, but it’s responsible for being able to log in, being able to access your data and not having it accessed by other people who shouldn’t be able to. And when we were evaluating our needs, it felt like they were special and we could do better to build this in-house. What we’ve realized now is actually, this is really hard.
We have to deal with the after effects years down the track because now we can’t even remove it from our tech stack. It is so ingrained. The job and the effort required to remove it is actually very high. So we’re stuck with it, so to speak, but every day, every week, every budget. We have to account a certain amount for its maintenance and for the frustration that the engineers have to deal with in order to deliver additional value for our users and for our customers.
So I think if we had a time machine, we would definitely go back and change that decision. However, to be fair, you know, when we think about how this decision got made in the first place, it wasn’t due to any malice. But just genuinely not taking into account the total cost of ownership of the decision, the ramification that the decision would have across the rest of the product, and probably just underestimating our own knowledge of the space.
So we encountered many challenges, which I. Which for us at the time were unknown unknowns. That basically means we didn’t know that problems existed. We hadn’t encountered them, and we didn’t have the experience to draw from, to realize that there were actually things we didn’t know. We didn’t know.
We didn’t know those So that was one example. I can probably give you another one where, we’ve probably made I think, a better decision. So previously in our product, we used to do a lot of natural language processing. We ingest, customer reviews, feedback forms and surveys.
And, a couple of years ago we had our own data pipelines using machine learning and natural language processing techniques to break down, customer’s feedback into words and sentences and analyze sentiment and so on and so forth. At that time, it really was a state of the art and a great solution, but then came along, GPT and large language models and that really changed the entire, shape of what it meant to do this kind of work.
And so we pivoted towards buying. We realized that actually this was very hard for us to compete with. Actually we couldn’t add any additional value on top of what, was on the market. So it’s where we’re sort of learning from our mistakes, so to speak, and thinking about the builder versus buy decision through different lens and the entire lifetime of that product or that initiative, as opposed to just the build cost.
Angie: Yeah, it’s funny you talk about one of my biggest regrets and then one of our biggest wins at the same time, with those two stories. And I think it goes, it speaks to that sunk cost fallacy as well of like, it would be easy to look at that and say, well, you know, we’ve spent years developing this particular part of the product that dealt with freeform visitor feedback and that used all of this technology that we’d built out.
And it’s quite the swallow to, take that on the chin and walk away from it and start afresh with something that then overtakes it quite quickly. So it feels bad and good at the same time. I think, one of the things that was coming to me as you were talking about the identity management example, was a guy I used to work for at Hewlett Packard.
He would say “You should only build when it’s core to your mission, when it’s part of your unique sales proposition as an organization.” And for me in a visitor attraction that is things that are inherently part of the visitor experience. So if I’m Disney, for example, and I’ve got my magic band. That for me is an example of a visitor attraction, example where building the technology kind of makes sense because it’s something very unique to Disney, very core to its customer or visitor experience.
But for us at Dexibit being able to log in is not something that’s unique. It might be a necessity to support our customer’s experience, but it’s not the core of it. So getting really specific about how you sort of navigate that strategic decision. I think really comes to, to help, make that decision of where you buy versus build.
But it is a really difficult one, I feel to, to push back on. What advice would you have for people like me who are. Not engineers themselves don’t have the knowledge to understand, or the foresight to be able to know just how extensive a build was gonna be, how long running its ramifications would be down the road.
How do you push back or navigate that kind of decision space while still trusting your technical team?
Ravi: I think if you consider yourself to be a visitor centric organization, which I think a lot of you listening probably do, I imagine you would ask yourself, what value is this going to bring to the visitor?
And really think about, where your build initiative fits in and. Where instead you might be able to build something that sits on top of the shoulders of giants, for instance. Something like the dexibit and how you can extract even more value that’s unique and a unique proposition to, to your visitors and your business. One of the great quotes I’ve learned over the time is from a blogger called John Cook.
And a lot of leaders tend to think of building a software system as like, playing with Lego. And all you need to do is just. Click in different blocks of Lego together and you’re done. But in reality, and this is this fantastic quote, integrating two software systems is usually more like performing a heart transplant than hugging in lego.
If there’s a close enough match and the people doing it have enough skill. It’s possible, but the pieces don’t fit together. Trivially. And what’s worse? Failure is often never immediate, but it’s takes some signs before you see the rejection. And I think it’s an extremely apt quote and something that’s realized by a lot of organizations that go down the build path for the wrong reasons or with a lack of that knowledge around the total cost of ownership. And what this means in the longer term.
Angie: Yeah. I think one of the other things that I found tricky in that decision was, which I hear a lot from visitor attractions when they’re making a data build versus buy solution is, it’s really easy to fall into that trap of, but we have this one special thing. And to feel very unique in that space.
Oh. But we’re a museum that has special exhibitions and general admission, and we charge ’em as separate tickets or something. Or we’re a location based experience, but we do tours and they depart every 15 minutes and feeling like those are unique things and often that they’re not. And often there are great ways to work with problems like those.
For us in that identity management experience, it was, oh, but we have multi-tenant customers. And that was like the requirement that we hung our hat on and decided to build versus buy. What would be some of the things that you would challenge? A tech team with if they’re sort of coming to you with that one special.
But what about this thing? Often these things are, the little use case that’s quite rare to, to encounter too. So they’re not necessarily, the thing that the team comes across every day.
Ravi: I think it’s really just pushing the team to really think through the solution space.
And ask themselves whether there are other avenues to solving the problem, that can sort of mitigate that requirement. And I think that’s what we didn’t do. In that example, we landed on a very specific solution that didn’t exist in what was off the shelf. And we’d concluded that therefore we needed to build that piece of technology.
However, if we perhaps reframed the problem, we could have arrived at the same outcome using a plethora of choices of the shelf.
Angie: Yeah, it’s funny, I often find that you don’t know what you need to know until you get to that point that you need to know it. And it’s like if you sort of resolve the other 99% of the solution, then that 1% that you’re hanging your hat on saying, oh, but this is special because this, then becomes clear to you at that point because you have those shoulders that you’re standing on, that, that view that’s different from the top versus when you’re starting with a blank page and saying, oh, but this special thing, it becomes this mountain that you’ve gotta climb in this big edge case everybody focuses on. And that can then become quite sidetracked.
Ravi: I, I think so. To be honest with you. Another part of this was I feel like there was a disconnect between. How our engineering team, our tech team, understood the needs versus what the needs actually were from the business and customer side. And, we could probably have done a better job of seeing each other’s different perspectives to realize that they were actually probably quite different needs, but the way they were interpreted seem to result in this very special case.
Angie: …and that’s such a common problem, isn’t it? Especially in this example that we’re talking about where we’ve got a, maybe a tech and digital team who are perhaps quite departed from the realities of being on the ground and visitor services, or being embedded in finance or out with marketing, running campaigns like because of the diversity of the stakeholders and all of their use cases and the business domain knowledge that’s gotta go into all of these problems. Like that becomes a really compounding issue to maintain that bridge between technology and business.
Ravi: Exactly. And. We’ve seen this, I’ve seen this a lot where, sometimes the tech team and the engineers, they’re focused on moving numbers around. And so as long as a number appears on your screen or in the report, it feels like everything’s working to them.
But the business users who are actually looking at their report to them, although there are numbers there, they actually don’t make any sense because they’re so far away from what they expected. The business metrics that matter and when you’re not connected and on the same wavelength, it leads to these perverse decisions and misunderstandings.
Angie: I’ve got a couple of questions here from, some of our listeners. I’ve got one here from Kevin, the head of visitor services at a mid-sized history museum in Ohio. Hi Kevin. He says, “We’ve been leaning on spreadsheets forever. Now, there’s a push from leadership to in quote, get serious about data. The tech team in IT want to build us a custom dashboard in-house. I’m worried it’ll be months before we see anything usable. How do I push back without sounding anti progress?”
Ravi: Hi Kevin. That is quite a predicament that you’re in. I think you’re probably right to be worried and concerned. My suggestion would be to talk to your business stakeholders and get a better understanding of what value they get from your spreadsheet and what’s missing, and ensure that they look beyond just the build your own, do it DIY solution space, and see what’s out there on the market. What can be used. What you can really use as a lever to drive more impact. Because I think for example, with Dexibit in your hands, you will have so much more agility that you can do everything that your in-house tech team wants to do, but in a matter of days, and not just for this one data set that you’re talking about, but you have the ability to work with, plug and play integrations, but also upload your own bespoke data sets and spreadsheets and create all of those dashboards and reports.
Angie: Yeah, I would echo what Ravi said. You are right Kevin. It will take months before you see anything usable. Maybe a little bit longer. My advice in this situation would be, if you’re the head of visitor services.
You don’t need to be passive in the technology making experience decision experience, like, best case that should at least be a partnership between you and technology or the IT team. But. You know, if it’s not that equal partnership where you’re making that decision jointly, and it’s not about, in your words, what the IT team wants, I mean, at the end of the day, you are the person, you are the team who will be making the decisions based off this data and this data solution. So I would suggest to you that’s your decision to make. So don’t be afraid to step into that leadership, into that space and lead the decision of are we building, are we buying, and if we are buying what and why?
And. Provide a framework for your team and the IT team to work together to make those decisions and be able to challenge and push and pull within that framework to lead the team to make the right call. Rather than saying hands up in the air, this is the it team’s decision. And we’re just gonna go with whatever they want.
So that, that would be my suggestion. I know it’s tricky when it comes down to whose budget is it coming out of. But hopefully there is also that sense within the wider leadership team of who are the core stakeholders who are leading in this space.
And we have another one here from Leila, a marketing manager at a science center in Canada looking at buying a COTS data solution. So I presume that means commercial off the shelf data solution. “I’m struggling to compare the cost to what we already do with our ticketing systems reporting. Is there a framework to help non-techies understand the real cost of building versus buying? That’s a tricky one. I would jump in there. With the fact that one of the things we talked about today was lots of different data coming from lots of different places. And your ticketing analytics or ticketing reporting that’s in that system is just one piece of that puzzle. And there are lots of different data points and metrics or key performance indicators that you need to run your visitor attraction.
And let’s take one, like revenue for example. To get a revenue out. It’s not just gonna be ticketing. We’re talking about food and beverage. We’re talking about retail. We maybe wanna look at something like average revenue per visit and maybe we recognize visitation of footfall. Maybe we’ve got a food and beverage joint venture revenue share partnership with a local cafe operator. And so we need to take into consideration that that split as well. So we are talking about lots of different data sources already just for this one, KPI and lots of different automation requirements and lots of different things. Ravi mentioned all the stuff that’s happening under the hood in terms of transformations and business rules and so forth. As well as all of that coming together, plus we’re talking about all of those things of, and how do you visualize this and, you know, do we wanna look at per cap by day of the week or per cap when it’s rainy versus windy, and all of these sorts of things. So this is a much bigger problem than saying, how many tickets did I sell today? Out of your ticketing solution. And I would say the same is true for pretty much every system that you work with. Like Google Analytics, for example. Great place to go to get data about your website. Facebook. You can go and pull some data out of there as well. But what you end up with is that problem of like copying and pasting data into spreadsheets and circulating them in reports and lots of effort involved in data admin. And time and that’s all energy that’s not being spent on making great decisions. What would you add to that, Ravi?
Ravi: I can’t add anything more to that. I think you’ve answered that question extremely well.
Angie: maybe you could help me out with this one. Raj from a theme pack operator in Dubai. He says, “We’ve in invested in an internal data lake and we’ve got a strong engineering team in house, but I’m under pressure to demonstrate faster return. How do you balance what you’ve already built with the appeal of buying something that could plug in faster?”
Ravi: I think it’s a really great question to ask because it shows you’re really thinking pragmatically about how to deliver value and not just about working on a project because it’s fun and cool. There’s actually quite [00:42:00] a lot of different ways to integrate and in-house with an off the shelf solution. So for us at Dexibit we do this quite often because again, we can leverage the work that’s already been done to good effect and allow your team to focus on adding value and building on top of the combined software. So we can integrate with a lot of standard data warehouses.
Such as Databricks and BigQuery and Snowflake or SQL Server, and we can leverage all of that work. We can over time slowly migrate away from that. So then you are no longer burdened with the maintenance and the operational expenditure that comes along with keeping the lights on and keeping that performing well.
Or we can choose to leave it in place and continue to build new in our product. So there’s quite a lot of different pathways that you can take, and the best is the best way forward is really just to have a conversation with your chosen vendor.
Angie: Nice. Well, if you like the show, come and find us at Dexibit.com or send us your questions at info@dexibit.com.
Thanks for listening to the Data Diaries so until next time, this is Dexibit. Thanks, Ravi.
Ravi: Thank you.
If your goal is to get more visitors through the door, engaging and spending more, leaving happy and loyally returning – check out Dexibit’s data analytics and AI software at dexibit.com. We work with visitor attractions, cultural and commercial, integrating with over a hundred industry source systems across visitor experience and venue operations, providing dashboards, reports, insights, forecasts, data management and a unique data concierge.
Until next time, this is Dexibit!
Ready for more?
Listen to all our other podcasts here: