Podcast EP 193 - Managing the Transition from Selling Units to Selling SaaS - Tsiki Naftaly, Co-Founder, Copilot.CX

EP 193 - Managing the Transition from Selling Units to Selling SaaS - Tsiki Naftaly, Co-Founder, Copilot.CX

Nov 13, 2023

Our guest today is Tsiki Naftaly, Co-Founder of Copilot.CX, a unique solution in the consumer electronics industry. Copilot.CX transforms occasional buyers into loyal, prime users. Through customer collaboration, they boost sales, enhance reviews, and ultimately elevate the overall customer experience.

In this episode, we delved into the challenges encountered during the shift from being a hardware device manufacturer selling units to becoming an IoT device manufacturer offering SAS subscriptions. We also talked about the benefits of incorporating automated customer touchpoints throughout the product's lifecycle, customer satisfaction and opportunities for upselling supplementary services.

Key Discussion Points:

  • How has the company's shift from hardware distribution to customer engagement platform affected its value proposition?
  • What is the process of using customer data to improve Salesforce, refine marketing, and potentially shape product development?
  • How do you see the tech services in your solution stack to bring valuable proposition to life? 

You can find him on:

Website: https://www.copilot.cx/

Linkedin: https://www.linkedin.com/in/tsikinaftaly

Subscribe

Erik: Tsiki, thanks for joining us on the podcast today.

Tsiki: My pleasure, Erik.

Erik: Yeah, cool. Well, I'm looking forward to this one. It's a bit different. Often, I've been interviewing very b2b industrial. So either the dirty companies, the ones that are getting grease on their technology in a factory or the very nerdy ones, the ones that are kind of buried somewhere up in the cloud and making some back-end process 15% more efficient. Here, we're doing something that's really touching consumers. So I'm really excited to get into this topic with you.

Tsiki: Yeah, happy to be here.

Erik: Before we get into what Copilot.CX does, tell me a bit about yourself. So you've been founder of a company called Zemingo for quite a while now. What is this? Going on 10 years. Then through that process also, you were co-founder and a board member of BoatBook. Then it was in 2018 that you co-founded Copilot.CX. So it's always interesting to me to understand out of all the things that a founder could be spending their energy on, why you chose this particular problem? What led you to co-found Copilot.CX?

Tsiki: I think the short answer is that I didn't choose that problem. The problem kind of chose me. You mentioned my previous company, which was Zemingo that I sold in 2018. When we started Zemingo, Zemingo was a service house. Actually, it is a successful company. There's a brilliant, young man that runs it until today, going really strong. It's a classic development service shop. We started developing mobile apps when the mobile app industry just started to boom. Quite quickly, we started focusing in more complicated mobile apps — apps that are connecting to physical devices, to security cameras and door locks, and what used to be called M2M, machine-to-machine. Today, it's called IoT.

Obviously, as the company grew, we started providing more services like developing the back end for those devices, for those that needed back end. One of the things that we learned over the years — it was quite a journey for 10 years — we learned that many companies are being pulled into the IoT so-called world. Sometimes it's reasons that are pretty straightforward. You sell your product in Costco, and the buyer in Costco calls you one day and says, "Do you remember that pathway lighting that you're selling? We need the same thing, but we just need it with an app." You don't think of this as a big transition from one world to another. You just say, "Okay. I need to call the manufacturer," usually in China and say that, "I need the exact same thing with an app." That moment is a really interesting moment where you don't understand that you're returning your company slowly from a hardware company into more of an IT company.

The place where it first meets you is where you used to sell a product, and the moment the product left the warehouse, you couldn't care less what happens with the product, as long as it's not being returned. Suddenly, the products that you already sold, you need to make sure that they support the new iOS that's coming up, or the new Android version that's coming up, or different router configurations and what have you, which is more suitable for a software company. But hardware companies are never used to that type of recurrent costs. Now I need the engineers, and updates, and IT, and so on and so forth. So we've seen that as part of my role as the CEO in my previous company. We started working with our customers on something that will balance that recurring cost. That is recurring revenue.

How do you create a recurring revenue for physical device? It all starts with data. So we started helping them manually looking at the data, analyzing it, trying to find ways to leverage that data to their behalf. Just as an example, we used the data in order to understand when is the right time to sell another product to that person. Or, if we're talking about cameras and subscription, when is the right time or what needs to be done? There's a whole story behind it in order to sell a subscription to the customers in order to improve from 8% subscribers to 20% subscribers, and so on and so forth. Again, we did that manually. We had data engineers, and analysts, and data scientists, and people that specialized in engagement with customers, how to send the right email, in-app message or push notification and so on.

After doing this for a few years, we thought like kind of a thought process that happens in many other companies. There's so much common functionality here and common processes. We should probably productize it just so it's easier for us to do our work. We haven't thought initially that that's going to become a product or, let alone, a company. But we started. We productized it, and it became easier and cheaper for us to do our job. At some point, this interjected an offer. We got to sell Zemingo as a company. We sold the company and spun off the technology to a new company. This is how Copilot was born.

Copilot is actually the same service that we provided manually. That cost in the past a lot of money to buy, only as a SaaS business. So we productized all those processes. We enabled today to our customers to do on their own exactly what we did back then just as a heavy lifting manual service. This is how we came here.

Erik: That's interesting. I think a lot of people, when they're thinking about this transition from a pure hardware company to an IoT company with both hardware and software elements, they think a lot about the technical challenges of how do we make sure that we're delivering the right service, that we have connectivity uptime, that we have a good UX. These are all challenges. But when I look at the companies that we're working with — a lot of the reasons for failure are not due to technical challenges. They're due to the business-related challenges of, okay, how do we then sell this. So now it's just a very different pricing model. How do we get consumers to accept that pricing model? It's a different sales commission model for the sales teams. It's a different marketing approach. It's a different relationship that we have to our customer.

It sounds like, on the one hand, you're supporting them with the technical issues. But as much as doing that, you're, I think, helping companies address some of the business challenges, of how do we move from a company that's basically sending out hardware to a distributor and then hoping that we chose the right distributors and that they're the right channels and that they're pushing that through to a company that is managing long-term relationships with customers, which is very different. It's just a very different operating model. So I'm really interested in hearing how you work through that.

I have a few questions that I want to dig into more about that topic. But before we get there, let's give everybody just a proper understanding of what exactly the company is doing more from a value proposition standpoint. You've already given us a good overview. Let's use an example. I'm a IoT company that's producing a camera, let's say, on a drone. I want to start generating SaaS revenue around this. What would be the benefits that I would be seeking? Then how would I be using your platform to actually arrive at those benefits?

Tsiki: Okay. In a nutshell, Copilot is an engagement platform specifically for IoT devices, for connected devices. Our platform enables our customers to engage with their customers or their end-users based on the way they're using the devices.

To take it down a notch, if you're a company that produces cameras, there are three to four main reasons you would start using something like Copilot. One reason is because you're trying to improve customer lifetime value. I can elaborate on that in a second. The second reason is, you're trying to reduce the number of returns or support calls. Returns meaning product returns to the store or support calls. The third reason is, you're trying to improve online ratings. In consumer electronics, online ratings have become more and more dramatic in order to grow your businesses, especially if you're talking about Europe and the United States. It's different in other parts of the world. We can talk about that. But in the United States, your online rating, let's say, Amazon — same goes to Europe. Same goes to Canada — can be the difference between you being a big successful company and you not being a big successful company. The fourth reason is overall customer satisfaction. These are the four pillars that companies are starting to use products like Copilot for in order to improve those four KPIs.

What we enable is in a really easy way, with no big integrations, with no high friction to get your data fully processed. When I mean your data, it's the data that comes from the users, from the devices, from the web interface, from the app, from any other interface that the user is touching, including the buttons of the device itself Orchestrate that data, and enable you to define processes based on that data.

Let's take one example that's really simple. If someone buys your camera and they bring it home, they're launching the app. Now they're trying to connect the camera to the internet. In many of those cases that the user fails connecting the camera to the internet. If you've ever tried to connect an IoT device, you know that in many cases, you will fail even if you're really tech savvy. Many of those cases, we know that the user is going to fail about 10 seconds before the user fails. Sometimes even before that.

How do we know? We just look at all the permutations of other users that failed. Sometimes it relates to what type of Wi-Fi is your phone connected to — 5 gigahertz versus 2.4. Sometimes it's other parameters on your phone: location services turned on or off, geographic location, your Wi-Fi strength, and many other reasons. When we find out that the user is going to fail, we enable the manufacturer to define what happens then. What do you want to do? Do you want to pop up a message in your app asking the user to turn on location services? Do you want to offer them support call? Do you want to wait until they fail and then say something? Every manufacturer has their own processes, but we have a visual studio, a graphic studio, that enables them to literally draw those processes on a canvas saying, "This is what I want to have happened when a user hits that roadblock," or, "When they see that opportunity, this is the message I want to send the user," and so on.

Erik: Okay. Got it. One key area of the solution is ease of onboarding. Then I guess there's other user frustration points throughout the user journey where having data from a larger set of previous users can help to troubleshoot those actions.

Then there's this area around improving understanding of the user. I'm actually really curious about this, because I think quite similar discussions but with very industrial companies. For example, one of our customers, they produce lifting equipment for construction, or planting trees, or whatever that might be. Their experience, on the one hand, they're a very, very different industry from a consumer IoT device. On the other hand, they probably have some of the similar challenges. They send their equipment to a distributor. The distributor sells it. The customer never sees it again. They have no idea who's using it, where they are using it, how are they using it. Are they using it to plant trees, or lift rocks, or whatever? They would love to have that information because then they can better target their marketing efforts. They can better structure their salesforce. They can potentially design products that are specialized around particular use cases that they had never imagined before or didn't know were so important. And so I'm looking at this a little bit from that perspective. Explain to me how this works, this process of taking this information and then filtering it back to the sales, marketing and, potentially, product development teams.

Tsiki: That's a great question. I love the example from the manufacturing side. When we chose our focus, we chose not to focus on the analytics per se part. There are a lot of platforms that enable just learning more about your customers in order to infuse this information into the marketing team or the product team, in order to build better product. We're not there. When we chose our focus, we understood — again, from our customers — that in order for our product to be valuable for them, everything we do needs to be connected to something tangible on their end.

Maybe I should pause for a second and tell you about our industry, because it's highly related to those decisions we made. Our industry is consumer electronics companies, usually, traditional companies. There are companies that are 100, 150 years old, amazing companies that were built over the years. Even the younger companies are 20 years old or 30 years old. This whole idea of engagement based on data is new to them. This is something you see not just in the company's processes, or values, or DNA but also in type of people you find in those companies.

In my previous business, I used to talk to a lot of product managers. In many cases, a product manager is someone that is working off of data and so on. They understand user communication and engagement and lifetime value. Those concepts are their day to day. With the companies that we work with, today, in many cases, the product manager, in some cases, they call them the product category manager. He's the person that's in charge of several categories or a category of product. He's a person that deals with manufacturing of the product with the hardware. In a lot of those cases, they're an electronics engineer. This entire idea of having things in the cloud constantly updated, launching a version once every couple of weeks are new to them. When talking about managing the lifetime of a customer and the customer journey, et cetera, it's a whole different world for them.

So when we prioritized features in our product, we prioritized features that are connected directly to their revenue. Just as an example, if we know that for a specific company there's a linear growing number of support calls, we will guide them how to focus on reducing those support calls using our system. We learned when we started. Obviously, we had that concept of you want to know what your users are doing. You want to know how your customers are using the product. In many of those cases that we saw that we're pure failure for us, with new customers, we saw that they got into what's called analysis paralysis. They got a lot of data. Think of millions of devices, pouring a lot of information, a lot of permutations of different things that people are doing with those devices. But they didn't know what to do with that data. It was always kind of, "Oh, that's really nice to know. That's really interesting to know that our users are doing XYZ. But what does it give us exactly?" This is where we navigated into the world that says, "You want to improve your online ratings? Perfect. Here is the engine. We have an online rating engine in the system. Here are the steps 123. This is what you need to do. This is the groups of customers you need to communicate with. Those are the struggling ones. They're going to give you one star. This is how you prevent them from giving you one star — you give them another outlet. These are the happy ones. They're going to give you five stars. This is how you encourage them to give you five stars. That's it, and then the result is really tangible. It's connected to ROI.

Erik: Super interesting. Okay. Based on your analytics of how a user is using the solution, you can get a sense of their satisfaction level. Then you can decide what path to put them on, whether it's trying to improve the satisfaction level or whether it's directly asking them to give a review and then some mechanism there. That makes complete sense, especially for this market where a lot of the success of the product is related to their performance on the marketplaces.

There's a question that — I don't know if this is something that you engage with personally. But again, it's something that we've confronted a lot, and I imagine some of your customers are confronted, which is this question of, we're moving from a product that was basically 100% of the revenue we got was from selling a piece of hardware. It was one-time revenue. We're moving to some mix of hardware revenue and software revenue. What balance should we aim for? Should we aim for the hardware revenue just paying for the bomb, basically just getting us to a breakeven, and we make our profit on the software?

I think a lot of these decisions are related to consumer behavior on how does a particular consumer group want to pay for something. Do they put a lot of value on the hardware, and they're willing to pay a premium for it? Or, is it better to price the hardware as low as possible in order to just get more devices into the field and increase your user base? Then you can have value-added software that really has a high-value and a high-sticking point, and people are willing to pay for that. I think this is something that your customers are thinking about a lot. I don't know if it's something that your information is being used directly to support them with. But is this something where you have insight, or will you provide insight to customers around these pricing topics?

Tsiki: Yeah, definitely. We're taking an active part in the strategic discussions, even for those really big companies that are going through that transition. I think before giving the full answer, it's important to understand that most companies don't wake up one morning saying, "I don't want to sell just the hardware anymore. I want to sell software." This desire comes from a place of distress.

Many of those products are being commoditized. If 10 years ago, you had specific distributors you could buy security cameras off, today you can buy a security camera for $1,499 off of Amazon. To be fully honest, it's going to work fine. Maybe it's not the highest quality, but for a lot of US homes, that's probably enough. Then the game starts to become: who is able to create real lifetime value out of their customers, not just be supported by the transactional value of selling the product, again, from the point of necessity?

For some products, I fully agree that subscription, selling the software on top of the product, that's kind of the holy grail of that industry. Everybody understands that. Unfortunately, there are many types of products that tried and failed creating a subscription model. Light bulb is the first and foremost. There are a lot of light bulbs that are connected that have a recurring cost but no recurring revenue, vacuum cleaners, think of all the robotic vacuum cleaners and smart door locks and thermostats, et cetera.

There are other products that were able to make that jump. Usually, thanks to one or two companies that paved the way for them. Camera is one of them. I think Ring had a big help to that industry in introducing their monthly and yearly subscription. If you look today, most companies that are manufacturing consumer cameras have an option to buy a Cloud subscription. Some of them still keep the option of having an SD card. Some of them kill the SD card, and the camera is virtually useless if you don't buy a Cloud subscription.

That being said, even for those companies with cloud subscription for cameras — GPS tracker is another thing. If you go to Amazon and search for GPS trackers, the two best sellers on Amazon on our customers is LandAirSea and Tracki. You will notice that the price of the tracker is really low. The reason is simple. Those companies like camera companies are basing a big part of the revenue model on this subscription, cloud subscription, not on the hardware margins themselves. That process of turning from a company that the entire company is geared towards counting transactions and selling as many units, as many boxes as possible pushing out of the warehouse to a company that cares about what happens from the day the user touched the product is a long and tedious process. Where in many cases, a dramatic part of that process.

Just to give you an example, there's a concept that's called breadcrumbing. Breadcrumbing basically says: take a group of users that are behaving in a certain way that's desirable. Take the opposite group of users that's not behaving that way. Try to create a breadcrumb trail for those users that aren't behaving — for example, subscribe to cloud services — and understand what made them to subscribe. That's the process we do every week with many of our customers. Not just for subscription. For other desirable actions like giving a good review or a high net promoter score, and so on. When it comes to subscription, because it touches revenue directly, that's a big thing. That's an important process.

What we do is, our system actually analyzes those group of customers and says, okay, I recognize a specific feature or specific criteria that everyone that subscribed, the 95% of the people that subscribed, have used that feature a week before subscribing. When I look at people that haven't subscribed, most of them haven't used that feature. If you find that specific gold nugget in this — you probably understand there's not a single one. There are a few of those — then you can start having a discussion about, okay, let's get everybody to use that feature. Maybe it should be part of our onboarding process. In three days or a week after using that feature, let's offer them 20% off of a yearly subscription. Because we know that now there are more likely to buy a subscription. Now they're ready to buy a subscription. As I mentioned, that's not part of the DNA for most of our customers. It's a process that you need to take them through which involves, in many cases, hiring new people to the company that deal only with those things. There are people that are dealing only with customer experience, only with subscription, and so on.

Erik: Okay. Let's talk a bit about how you make this happen. You already mentioned that you work closely with your customers. I don't know if this is part of your revenue model, your pricing model, but it sounds like it's part of your operating model — that you need to really understand their business processes and their goals. It's not just them installing your software, but it's also a re-occurring set of conversations that you're having with them around how to use this. So that seems to be part of it. I know you have a front end. I imagine you have a lot of integrations, predefined integrations, around different business processes. How do you view, let's say, the solution stack — tech plus services that you've built up — in order to make this value proposition that you've been describing into a reality?

Tsiki: Maybe let's talk first about the dream. Our dream as we built the company was that, our customers will go to our website like any other company — SaaS company or most SaaS companies. They will sign up. We had that option, self-serve, and start using our product. That didn't work out. The reason it didn't work out, as we analyzed it, is that this goes back to the DNA. Those companies that we're targeting our ICPs are not in the mindset of setting up a product like Copilot, starting to use it. Even if we convince them that this is what they need, they wouldn't know where to start. This is why in the past couple years, we invested heavily in those quick-start guides.

If you're an average company, let's say, you're a company with 2,000 employees and you're selling a couple of million devices a year, when you start working with us, the first part is integration. I think you touched a really important point. We understood over the years that friction in onboarding for our customers is not less significant than the value that they're eventually getting. If the friction is high, it doesn't matter how much value they're getting. They might not be there to see the value. So we invested a lot in pre-integration. We're integrated into all major IoT platforms. We're integrated into retail stores. We're integrated into the Apple Store, and Google Play, and Shopify, and some other integrations. The idea is that, in many cases, the setup of our product for our customer is really, really quick, which is one problem solved.

Let's assume you're a company that's using a famous IoT platform, and you're using our plugin to fetch all that data from the platform. The first thing we do — we're lucky to be in a specific industry that has a lot of common characteristics between those companies — we look at our guides. We have guides for almost any product out there. Do you sell cameras? Perfect. These are the KPIs. We go over the KPIs for cameras that worked for us in the past that worked for our customers. We guide you through the process of tackling those KPIs. So if you're trying to reduce the number of support calls, perfect. There's a clear guideline of what type of data you need, what we recommend the success criteria to be. Because even selecting that KPI or OKR, whatever you use to work with, sometimes it's not easy to find what is the success criteria. How do I define success? And only then start building those, we call them campaigns which is actually the workflows that are tackling that KPI — if it's subscription rate, or if it's onboarding issues, or support calls.

Erik: Thanks for walking through that. I think that's a really important point to keep in mind for anybody that's building a software, a b2b software product. It's that there might be a vision for this perfect future where a user downloads it. You never talked to them, and you have just a great operating margin because of that. The reality is, before you get there, it's going to be a lot of effort to define these processes, do these pre-integrations, and probably a lot of also human communication with your first 100 or your first 1,000 customers. Maybe you'd never reach that point, which is fine. You can build a great business by just trying to get 70% of the way there or 80% of the way there, and still having some work that needs to be done in person to get people onboarded properly.

What does this mean for your business model? When you price, do you also price in a setup fee that includes more people coordination and support, or do you still price around software and just say we have a certain cost-related to getting our startups, our customers onboarded? I would also be interested in just understanding what is a starting price. Where would you say, below this, customers are not going to be our customers? Maybe there's other solutions they can use. But what would be the baseline starting price for a potential customer over, let's say, one year?

Tsiki: We do have a setup fee, and that makes it clear and transparent both internally but also externally. The setup fee is being charged for the labor that's being done as part of the setup process. Some customers are, for example, selecting to have a workshop with their team if they have a big team that's going to be involved. In some cases, we actually do a workshop and fly over there and have an on-site workshop. But we do totally separate the license for the software from the manual work that we're doing, whether it's a specific service that we provide or a setup service and so on.

To your question about the minimum charge per customer, if you're a small startup and you're just beginning, you're going to pay the minimum which is about $10,000 a year. Below that, the overhead cost of the entire operation just doesn't make sense. Obviously, we have customers that are in hundreds of thousands because of the size of their database, their user base and device base. But we also have a long tail of customers that are just starting up. Sometimes it's a big company. But all of their devices are not connected, except for a couple of skews that are IoT. They usually start with about $10,000 a year.

Erik: Once you get into these scale cases, is there a one-size-fits-all in terms of you have an equation, how many devices, or how much data? Or, do you say, well, some companies have a lot of small devices. Some have high-value devices, maybe like a car, and then define a different pricing model based on the business structure of the customers. What have you found to make sense to your customers here?

Tsiki: That's a great question. Because we've been through a lot in terms of finding the right pricing that works for us and works for the customers. What eventually we found out is that our pricing should be fully aligned with our cost structure, not the customer's cost structure. It's true. You're saying a car might spit out the same amount of data like a light bulb, but the manufacturers are making much more money on the car. To be fully honest, it's not our business.

What we did find out is that if we align our pricing to our cost structure, what happens then is that for manufacturers that are selling products in thousands of dollars per unit, those manufacturers usually consume more services on top of the product itself. So the invoice at the end of the month is bigger but not because the license is higher. The license is always attached to the number of devices that are running in the system. Because this is how our cost structure works.

At the beginning, we thought about the different types of pricing we could have. I know that many companies select to price their SaaS services by throughput, or the number of events that are being sent, or the number of queries that are being done on the system. When we started asking our customers — I'm talking about three, four years ago — about the different options when we started talking seriously about different types of pricing, going back to that DNA, almost everybody we spoke to said, "Listen, I have no way of taking this into my numbers. I need something clear that is easy for me to understand." They understand number of units, so we charged by the number of units. If you have 100,000 units connected to our system, you're going to pay X. If you have a million units, you're going to pay 3x or 4x. Obviously, economies of scale works here. The bigger the server is, the less it costs us per unit.

Erik: Got you. That's a great way of thinking through it. That's right. What kind of structure that makes sense for your economics, and then if somebody has a big, high-value item, they're probably going to want to build more services around that? Then you can also build a business around providing those services.

One other complexity here or topic I'm interested in hearing your thoughts on is this topic of which regions you play in. Because the customers that you're working with are certainly selling products around the world. And if it's just a pure hardware product, that's fairly simple. Once you get into data, then you're dealing with different regulatory compliance topics in Europe or in China for that matter versus the US. You might also have different customer dynamics in terms of what is somebody willing to pay for hardware versus software in these different markets. Are you guys today, more or less, 100% focused on the North America market, or you were already into the European or the Asian markets or other markets globally?

Tsiki: We have three markets. We're operating in North America, South America, and Europe. You're right. There are different regulations. Even within the Americas, there's different regulations in North America and different regulations in South America. There's a lot of common concepts. I think a lot of countries, states are deriving their regulations from GDPR. Even in Europe, there's GDPR. Then in Germany, there's GDTPA which is another slight version of GDPR that has some other things that you need to consider.

We haven't started selling in China yet, nor in the Far East or Southeast Asia. The primary reason is that we're just focused on a specific market. We started with North America, and then we started having customers coming in from Europe. Usually, companies that are global that spread out to subsidiaries in Europe and then other companies in Europe that are in business with those companies that are reaching out to us. We don't have an office in Europe. We have an office in New York and an office in Tel Aviv. Same goes to South America. We didn't go after that market, but that market came to us. These are probably the first two places that we're going to open new offices — in Europe and in South America.

I think the Chinese market is super interesting. To be fully honest, I'm not personally familiar with the purchasing patterns of the people in China, et cetera. And if we do want to start selling our product in China, I think the first step would be to find a partner in China that understands that industry intimately. What integrations you need? Are people paying subscription there or not? Are people buying more online or offline? I know a lot online, but I think there's a lot more than just saying, yeah, I want to sell in China or India. Again, I think it's a fascinating market. Obviously, it's a huge market. We cannot ignore it forever. At some point, we need to tap into that market as well.

Erik: Yeah, sure. I could see a lot of value for your business in China, India, Korea, Japan. Because it's a lot of additional complexity for IoT device manufacturers to manage the integrations and so forth. But of course, that's also a lot of complexity for your team as well, right? So you have to take it step by step.

Tsiki: We have partners in China. Sorry. Go ahead.

Erik: I'm sure you're working with Chinese companies. I mean, if you're working with IoT device manufacturers, you're definitely working with Chinese companies.

Tsiki: Yeah, for me, personally, that's an experience on its own. In my previous company, I haven't worked with companies in China. Now we're working hand-in-hand with device manufacturers and IoT platforms from China. That's one of the reasons it's fascinating. Because there are so many types of companies and emerging markets in China. Obviously, it's a huge market. That's definitely something that, at some point, we need to address professionally.

Erik: Great. Well, last question from my side. For you, what's exciting about the future right now if you look at your business? Do you have new products that are coming out? You already mentioned a couple of new markets that you'll be setting up offices. So there's this expansion going on. Are there other things, more generally, in the ecosystem, in the market, changes that are exciting to you? Aside from running the day-to-day business and continuous improvement, what is keeping you occupied right now?

Tsiki: There are quite a few things that are keeping us occupied. I think the interesting things that are going in the industry after years that this IoT industry has been growing and opening up to new markets, there's a big discussion around something that's called Matter that's going on. If you haven't heard about it, there has been attempts throughout the history of machine-to-machine or IoT to consolidate protocols, especially for the consumers. Think whatever product you buy, if that product is able to connect to the internet, it's going to connect to the same protocol. You don't need to download the manufacturer's app. You can use Apple's app, or Google, or Amazon, Alexa, et cetera to set up the product and control it, et cetera.

The idea is that, especially in smart home, in the future, with any type of product, you're going to have a single interface that controls that product. It was always a dream. It was a dream when they invented ZigBee and Z-Wave and other common protocols. It seems like for the first time in years, that dream is becoming a reality, or it starts to become a reality. It still has a lot of challenges. One of the things that makes us think that it is becoming a reality is that the big companies are already behind that association. Apple announced that they're supporting Matter. Actually, the new iPhone is already supporting Thread, which is also a protocol that's related to Matter. Amazon is supporting that. Google is supporting that and Samsung, et cetera, which makes everybody in the industry excited about this.

Again, there are a lot of challenges. But if I was looking to start a new company, I would definitely look into that. I think any other new, coolest kids in the block with a lot of challenges, you're going to have a lot of opportunities to build beautiful businesses around Matter. So that's one thing. We're, obviously, with our hands deep into that, helping our customers to navigate this. Because again, it's not straightforward. There are a lot of risks involved for our customers, for the manufacturers with those opportunities. That's one thing.

The second thing that I think most companies in the industry are looking at is generative AI. AI made that leap. It seems like almost overnight, although it's not overnight. Everybody is looking into how can I build a better product for my customers using generative AI. So we already started implementing that into our product. When you build a workflow today with Copilot, you can use generative AI to build the right messages and images, and so on and so forth. But I think there's a lot more that you can use generative AI in order to improve your business, especially if you're in the business of analyzing huge amounts of data or understanding what we need to tell a specific customer, what a specific product in a specific point in time. That's also a big thing for us. We feel a lot of opportunities in the IoT market in the next five years. A lot of things are going to change.

Erik: Cool. Well, you'll be busy. But it sounds like you're building a great foundation here to keep growing on. Tsiki, thank you so much for taking the time to walk us through the business today. I think it's, for myself, very educational. So I trust also very interesting for our audience. Appreciate your time.

Tsiki: Thank you very much, Erik. I had a great time.

test test