"Capturing client experiences starts with being genuinely present in every customer interaction."
The promise of a smarter world through IoT depends on a hidden layer of coordination: ensuring that sophisticated technical infrastructure aligns perfectly with the strategic goals of the business. While the technology handles the transmission of data, a Technical Account Manager ensures that this data serves a clear purpose and survives the transition from a controlled lab to a complex, real-world deployment.
Manuela Schlereth, our Head of Technical Account Managers Team, thrives at this critical intersection. She acts as a vital link between the LORIOT Network Management System and the global customers who rely on it for their daily operations. By navigating the technical nuances of LoRaWAN and mioty networks, she helps customers transform raw connectivity into a reliable engine for business growth.
In this edition of #LORIOTVoices, Manuela shares her perspective on the "reality check" organizations face during implementation, her process for translating client friction into product innovation, and why acting as an internal advocate for the customer is essential for scaling IoT operations successfully.
A Technical Account Manager (TAM) in the IoT space sits at the intersection of technology and business. Think of me as the bridge between our company's main technical product, in this case, the LORIOT Network Management System, and the customers who rely on it to run their operations.
On one side, I need to deeply understand the technical landscape: how LoRaWAN/mioty networks function, how gateways and devices connect and communicate, how data flows from sensors to the cloud, and how our products fit into a customer's broader IoT architecture. On the other side, I need to understand the customer's business goals, whether they're building network coverage across a certain region with the intention to sell this coverage to their customers, managing internal use cases or providing an end-to-end solution where the LORIOT Network Management System (NMS) is integrated, and make sure our solution is actually delivering value toward those goals.
In practice, that means I'm involved across the entire customer journey. I help new customers onboard successfully by coordinating server deployments and support with resource migrations in cooperation with our operations team. I provide technical oversight to prevent problems at scale. I advise on best practices for the usage of our LORIOT NMS. And I act as the customer's internal advocate when they need something from our product or engineering teams through feature improvements. I'm also watching for expansion opportunities, if a customer with networks across the globe struggles managing it effectively, I work to show them what else is possible, for example by integrating our Network Insight Platform.
What makes the IoT space particularly interesting is the complexity. You're often dealing with on-premise deployments, hardware constraints, connectivity challenges, and integrations across multiple vendors. So the TAM role here requires more hands-on technical depth than you might find in, say, a pure SaaS environment.
"Capturing client experiences starts with being genuinely present in every customer interaction."
Whether it's a kick-off deployment call, a support escalation, or a quarterly TAM meeting, I treat every touchpoint as a source of signal, not just a task to complete.
In the IoT space specifically, clients often can't articulate what's wrong in technical terms. They'll say something like "less data seems to be processed than expected" or "the lifespan of a device's battery is shorter than assumed." My job is to dig beneath that and translate it into something actionable. That means asking the right probing questions, reproducing the issue in context, and then framing it clearly for the internal teams who can actually fix it, whether that's DevOps, product, support or embedded team.
For structured capture, I rely on a few habits. I log recurring themes from customer conversations in our internal platforms, flag patterns I'm seeing across multiple accounts, and bring those patterns into cross-functional meetings with product, sales and engineering.
"A single complaint might be noise, but when five customers in different verticals hit the same friction point, say, difficulty integrating our network server with a specific application server or gateway, that's a product gap worth escalating formally."
I also close the loop with customers when their feedback leads to a new feature implementation. That builds trust and encourages them to keep sharing openly. Customers who feel heard become your best source of honest, ongoing feedback.
In an IoT context, this is especially valuable because the use cases are so diverse (smart agriculture, industrial monitoring, smart cities, etc.) and each vertical surfaces different needs. Staying close to those experiences is how you help shape a product that works across that diversity.
The first surprise is reality setup vs. lab conditions. A gateway and device that performs perfectly in a controlled environment often behaves very differently once it's deployed on a production server in the field. In LoRaWAN specifically, customers are frequently caught off guard by coverage gaps and interference, which can only be detected in the real production environment.
"What looked like a simple deployment on paper becomes a network planning exercise. The need for a test server where the production use case is replicated is becoming increasingly important."
The second is device/gateway management at scale. It's easy to connect ten devices in a proof of concept. But when you're rolling out thousands of gateways and sensors across multiple sites, remote access, provisioning, and troubleshooting become a significant operational burden. Many organisations underestimate how much infrastructure and process that requires.
The third is the management and maintenance of on-premise deployments. Deploying the network server within the client's infrastructure is often a requirement for customers within the smart cities vertical for municipal utilities. Owning such infrastructure requires a handful of expertise - such as an Infrastructure Engineer, Cybersecurity, IT Systems Admin, IoT Solutions Architect and Traffic Analyst. It's like a house of cards. When one piece is missing, everything falls apart.
And finally, integration complexity across multiple vendors surprises people more than expected. It starts from picking the right gateway that is fully supported by the stack and ends at the application server where the sensor data is fed in. Organisations need to plan every component of the stack and ensure its compatibility with the rest. Hardware and software all need to fit together like pieces of a puzzle.
In IoT projects, that gap between technical teams and business stakeholders can be particularly wide. Engineers are thinking about network architecture, network monitoring, network performance and stability. Business leaders are thinking about operational costs, compliance deadlines, and ROI. Neither side is wrong. They're just operating at different altitudes. The TAM role puts you right in the middle of that tension, and I find that genuinely energising.
One specific dynamic I find most rewarding is turning technical constraints into business narratives. For example, when a customer's engineering team flags that their devices are in a rejoin loop on the LoRaWAN network, that's a deeply technical problem. But the business stakeholder needs to understand what that means for their reporting frequency, their SLAs, and potentially their compliance obligations. Translating that accurately, without oversimplifying or alarming, and then presenting a solution path that both sides can act on, is something I take real pride in.
The reverse is equally rewarding - translating business urgency into technical priorities. When a customer has a hard regulatory deadline or a board-level commitment riding on a deployment, helping our internal engineering and product teams understand the real-world stakes behind a feature request or a bug fix can completely change how it gets prioritised. Being the voice that carries that context internally matters.
Building the bridge between technical constraints and business outcomes requires constant adaptation and deep empathy for both sides of the equation. How has your organization managed the balance between technical requirements and business stakeholders in your own IoT journey? Share your experiences or questions for Manuela in the comments. We would love to hear your perspective on turning technical signals into business results.
