Friday, five minutes to noon. Your most demanding customer approves the job, for the first time without a single reservation. No one in the team can quite explain why. Was it the new batch of substrate? Tuesday’s calibration? Or just a lucky day? Everyone has a theory. No one has data.
Nearly every print shop knows this kind of story, including its mirror image: the quality complaint that comes in even though every process step was followed correctly. The packing and installation team, waiting desperately for a reprint. The manual workaround that “everyone’s always done it this way.” The constant, minor irritation that gets discussed over coffee but never makes it into a ticket, a KPI, or a dashboard.
This is where the work begins. Long before technology enters the conversation.
The questions only customers can help answer.
Every product that aims to be more than an announcement starts with the same four questions:
| Four questions | |
| 01 | Market needs What are the actual market needs, and what requirements follow from them? |
| 02 | Pain points Which specific pain points of our customers do we need to address? |
| 03 | Value proposition What is our value proposition? |
| 04 | Practice How do we turn that value proposition into practice? |
These questions sound simple. They aren’t, because they can’t be answered behind closed doors. They have to be answered together with the businesses that will use the solution every day, from the machine operator to senior management.
And that brings up the far less comfortable follow-up question:
Can we answer these questions reliably, based on solid observations and measurable data? Or is it ultimately just gut feeling?
The fundamental premise: reliable automation starts with observable processes.
This is the core of our beta work within the Kyveris Beta Program: automation, industrial intelligence, better decisions. All of this requires that a condition, a problem, a pain point can be observed and measured repeatedly.
A recurring complaint can only be solved through automation once we know exactly where in the value chain the error occurs, under what conditions, and how often. A manual workaround can only be systematically eliminated once we understand which process state it’s compensating for. A good Friday can only become repeatable once we understand which factors, and which specific values of those factors, came together to create it.
For us, this leads to one of the most honest insights from the first months of the Beta Program: not every use case is ready for automation from day one. Sometimes we need to take one or two steps back before we can even talk about automation. The question then isn’t “How do we automate this?” but rather “How do we make this pain point reliably repeatable, visible, and measurable in the first place?”
What the first customer conversations revealed.
The initial interactions within the Beta Program confirmed this, while also painting a more nuanced, and at times sobering, picture. Some pain points repeat with surprising consistency across different companies, machine fleets, and countries. Others are highly individual, shaped by established processes, team structures, specific customer requirements, or other factors.
The common denominator lies elsewhere: making things visible at the data level is, in most cases, already the first hurdle, not automation itself. Before we can even discuss machine learning, forecasting, or intelligent workflows, a much more fundamental question arises: Is the relevant data even available in a form that can be observed, trusted, and analyzed?
And even where data does exist, a second, equally common pattern quickly emerges: the data is fragmented, scattered across different systems, machine controllers, MIS solutions, spreadsheets, or isolated standalone tools that rarely, if ever, communicate with one another. The result is classic data silos: they exist, but can hardly be combined into one consistent overall picture.
Even companies that appear, at first glance, to have impressive amounts of data often can only translate it into genuinely useful information with considerable effort, or sometimes not at all. Having a lot of data is simply not the same as understanding process states. There’s a significant gap between the volume of data and usable insight.
The outcome of these early conversations is therefore not a finished requirements document, but an interim status built on open, equal-footing dialogue. And that’s what moves us all forward.
To put it in the city-planning metaphor we used in our last post: every customer is at a different stage of their own urban development. One already has clean streets, traffic management systems, and monitoring stations. In other words, reliable, connected process data. Another has built many individual buildings with their own data sources, but no roads yet connecting them. And others walk the familiar paths they’ve used for years, because it simply works. The challenge isn’t imposing the same finished city on everyone, but meeting each business exactly where it currently stands.
Three domains, one common denominator: visibility.
The Kyveris modules introduced in our last blog post can be organized along this logic into three domains:
| Kyveris modules by domain | |
| 01 | Machine learning Ink Forecasting This is about recognizing and predicting consumption patterns, a capability that combines two things: making process states measurable and directly supporting day-to-day production work. |
| 02 | Connected data Durst Insight · Job Tracker Here, the focus is on measuring and visualizing process states, the foundation on which sound decisions can be made in the first place. In other words: the place where a good Friday stops being a mystery. |
| 03 | Conversational AI Durst Service Chatbot · Durst Analytics Chatbot This domain centers on directly supporting daily work, easily accessible for both operators and service teams. |
All three domains ultimately pursue the same basic idea: before we automate, we need to make things visible and measurable. The Beta Program is not a test of our tools on customers. It is a joint effort: these modules are being refined on our partners’ production floors.
Why become a beta partner.
Beta partners invest time and openness. In return, they get more than a test account:
Early access to real Kyveris capabilities. You won’t be working with a demo or a concept paper, but with the modules available at the beta stage that fit your needs, before they become generally available.
Co-creation, not consumption. Your production environment, your pain points, and your feedback flow into what we build next. You help shape the result, not just test it.
A direct line to product and engineering teams. Rather than being filtered through multiple layers, your input reaches decision-makers with priority.
Access to decades of production expertise. Kyveris builds on the experience of more than 4,200 Durst systems in operation worldwide, a foundation that you, as a beta partner, benefit from directly.
Visibility as an early adopter. Optionally as a launch partner or case study, if you choose to.
What we ask in return: use in real production and honest feedback, especially when it’s uncomfortable.
The city we build together will only be as good as the map we agree on. And that map isn’t created in a lab. It’s created through open exchange with you, on the shop floor, at the machine, in the day-to-day business. And the next time Friday works, your team will know why.
Running production you want to understand, not just guess? Join the Kyveris Beta Program and help shape it.
— Tomio Kiyose, October 2026
