Dogfooding as a Test for a Knowledge-Centered Platform
Hahn PRO is developing an AI platform for maintenance and production. So why are we building our own CRM on the same basis?
The short answer is: We want to make ourselves the most demanding user of our platform.
We are not developing a CRM because we are giving up our focus on industrial maintenance. Nor do we want to compete with established CRM providers on standard functions.
The internal CRM is a practical test.
We are examining which building blocks of ADAM can actually be transferred to other knowledge-intensive processes and where our platform is not yet good enough.
This principle is often referred to as dogfooding: A company consistently uses its own product in its everyday operations.
Why Another Standard CRM Doesn’t Fully Solve Our Problem
Classic CRM systems are strong in managing contacts, activities, sales opportunities, and tasks.
However, our real problem lies less in missing data fields. It lies in knowledge transfer.
In a technical sales process, information is generated in many forms:
- Meeting notes,
- Emails,
- Technical requirements,
- Objections,
- Project ideas,
- Presentations,
- Offers,
- Research references,
- and personal assessments.
Some of this is captured in a structured way. Another part remains in heads, mailboxes, or individual documents.
The central question is therefore not only:
In which phase is a sales opportunity?
But:
What knowledge do we have about the customer, their processes, their technical dependencies, and the next sensible steps?
This view is closer to a knowledge system than to a classic contact database.
What Can Be Transferred from Maintenance
At first glance, an industrial plant and a customer are fundamentally different. Beneath the professional surface, however, there are common patterns.
In maintenance, an asset is the focus. It is assigned master data, events, documents, sensor values, malfunctions, and measures.
In CRM, a customer or an opportunity is the focus. This includes contacts, conversations, requirements, documents, tasks, decisions, and a chronological history.
In both cases, information from various sources is brought together into a central object.
The knowledge process is also comparable:
- Capture information
- Establish context
- Make knowledge available
- Automate documentation
- Trigger next actions
- Feedback results
We want to practically verify this commonality.
Which ADAM Building Blocks We Reuse
Central Knowledge Objects
Instead of an asset, the customer becomes the central object. Conversations, documents, tasks, and decisions receive a shared context.
Natural Communication
Meeting notes can be captured by voice or free text. An assistant can ask follow-up questions and structure content.
Automated Documentation
From a conversation, a summary, next steps, and an internal handover can emerge.
Data Integration
Information from email, calendar, documents, and other sources should not be manually maintained multiple times.
Flow Studio
Data flows and automations can be modeled as reusable processes, for example, for follow-ups, internal tasks, or offer preparation.
Roles and Permissions
Not every piece of information is intended for every role. This applies in sales just as it does in maintenance.
What We Want to Learn About ADAM
The internal CRM is not purely an efficiency project. It is product development under real conditions.
We want to examine, among other things:
- How flexible are our data models really?
- How well do assistants work outside of an asset context?
- Where do new requirements for search and history arise?
- How understandable is the Flow Studio for internal professional users?
- Which integrations are missing?
- How well can knowledge be transferred between roles?
- Which functions are relevant platform-wide and which remain professionally specific?
These insights flow back into the further development of ADAM.
This does not create a random all-purpose product. On the contrary, the practical test helps us to understand the platform boundaries more clearly.
What We Explicitly Do Not Do
We are not building a complete replacement for every established CRM system.
We do not want to redevelop every marketing, sales, and service function. Standard functions remain sensible where they are well solved and economically available.
Our focus is on the areas where we ourselves have a special need:
- Knowledge-intensive technical conversations,
- Connection of sales, projects, and product knowledge,
- Traceable decision-making bases,
- Automatic documentation,
- and controlled transfer of experiential knowledge.
Where a standard solution is better, it should be integrated and not unnecessarily replaced.
Why Dogfooding Is Relevant for Customers
A platform provider can easily promise flexibility. Using it themselves shows how resilient this promise is.
When we use ADAM for our own processes, we experience the same questions as our customers:
- Are data models really adaptable?
- How complex is an integration?
- How do users react to new assistants?
- Where do media breaks occur?
- How much maintenance does the operation require?
- Which change is actually valuable in everyday life?
This makes us not only providers but also users.
This changes priorities. Functions must not only convince in a presentation. They must work in daily use.
Co-Creation Begins Internally
Co-creation means not fully defining software and then rolling it out. The professional solution emerges iteratively on an existing foundation.
Our internal CRM follows exactly this principle.
The platform provides reusable building blocks. Sales and marketing bring in real requirements. The application is gradually expanded, tested, and adjusted.
This way, we learn which forms of collaboration will also work in customer projects later:
- How small should an initial use case be?
- Which roles need to be involved?
- How are requirements prioritized?
- Which metrics show actual benefit?
- How is it prevented that flexibility leads to uncontrolled complexity?
Dogfooding is thus also a methodological preparation for better co-creation projects.
Which Limits We Must Make Transparent
An internal success does not automatically prove that the same solution works for every company.
Hahn PRO knows its own platform very well. We can make decisions faster and solve technical hurdles more directly than an external user.
Therefore, we must clearly distinguish in later statements:
- What is an internal prototype?
- What is proven in production?
- Which function is generally available?
- Which extension was created specifically for our process?
- What operational and security requirements apply to customers?
This transparency is part of digital sovereignty.
Our Goal
The internal CRM should achieve three things:
- Improve our own knowledge transfer,
- Practically test the platform capability of ADAM,
- Generate insights for future customer projects.
The starting point remains maintenance. There lie our experience, our product positioning, and the most important industrial use cases.
The CRM is not a change of direction.
It is a stress test for the core idea behind ADAM:
Knowledge-intensive processes require a common foundation of context, integration, assistance, and automation.
If this idea also works in our own company, our platform will not automatically become a universal product.
But it will become a better understood and more resilient foundation for co-creation.