Kriyantha Insights · Practical Operations
How a Simple Automation Portal Supports an Industrial Equipment Manufacturer
Why the client didn't need a complex system - just the right visibility into machines, maintenance, and orders in one place.
Not every manufacturing client needs a sprawling, feature-heavy system on day one. One of our clients, a medium-sized industrial equipment manufacturer, came to us assuming it needed something closer to a full ERP overhaul. What the business actually needed was much narrower: one place to view machine status, maintenance schedules, and open orders without replacing systems that were already working.
This case study looks at why a simple portal, built around a handful of real daily questions, ended up being the right fit instead of a larger, more ambitious system.
The Client: Scale and Complexity Without a System to Match
The manufacturer ran a medium-sized production floor with a mix of older and newer machinery, a small maintenance team, and a steady flow of custom orders from industrial clients. None of this was unusual for a business of its size - what stood out was how much of the operation depended on informal knowledge. Machine maintenance history lived in a supervisor’s notebook. Order status was tracked through phone calls between sales and the production floor. There was no single place to confirm whether equipment was running as expected or whether an order was at risk of delay.
What They Asked For-and What They Actually Needed
The initial request was ambitious: a full system covering production planning, inventory, maintenance, HR, and sales in one platform. After examining daily operations more closely, it became clear that most of these areas were functioning adequately. The real pain point was narrower: nobody could see machine health and order status at the same time, which occasionally led to accepting orders the production floor could not deliver on schedule. Narrowing the scope from replacing everything to connecting machine status with order visibility was the most important decision in the project.
Inside the Portal: What It Actually Tracks
The final portal was deliberately narrow in scope:
- Machine statusRunning, idle, or under maintenance, pulled from simple sensors on key equipment.
- Maintenance scheduleUpcoming and overdue maintenance tasks, replacing the supervisor’s personal notebook.
- Order statusWhich orders were in progress, and whether the machines needed to fulfill them were available and on schedule.
- Simple risk alertsAn alert when an order’s promised date was at risk based on current machine availability.
Getting Buy-In From a Team Used to Paper and Memory
The maintenance supervisor, in particular, had run his own system successfully for years and was understandably cautious about giving that up. Rather than asking him to trust a new system immediately, we ran the portal alongside his notebook for the first few weeks, so he could confirm it was actually catching the same information correctly. Once he saw the portal correctly flagging an overdue maintenance task before he had noted it himself, trust built quickly. This kind of parallel run, rather than an immediate full switch, made the adoption smoother than a hard cutover would have.
What Changed After Implementation
The most direct impact was fewer situations where sales accepted an order the floor later struggled to deliver on time, because order status and machine availability were now visible in the same place before a commitment was made. Maintenance scheduling became something the whole team could reference, not just one person’s private system. And when a machine went down, the impact on current orders was immediately visible, rather than being discovered later when a delivery deadline was missed.
Why “Simple” Was the Right Call, Not a Compromise
It would have been easy to build the bigger system they originally asked for. It also would have taken significantly longer, cost more, and touched far more of their existing operations than necessary. The narrower portal solved the actual problem faster, with less disruption, and left room to expand later if new needs come up. Simple was not a smaller version of what they needed - for this client, at this stage, it was what they needed.
Closing perspectiveThis client came to us expecting a large, complex project. What they got was a focused portal that solved a specific, costly problem: not knowing whether machine availability and order commitments lined up. It is a reminder that the right automation project is not always the biggest one - it is the one that actually matches what your team needs to know, day to day.
Key takeaways
The practical points worth carrying forward.
- Clients often ask for more than they actually need - a closer look at daily operations usually reveals a narrower core problem.
- Running a new system alongside an existing informal process, rather than a hard cutover, builds trust with skeptical team members.
- A portal does not need to cover every department to be valuable - it needs to answer the specific questions people are asking daily.
- Visibility between two connected areas, like machine status and order commitments, can prevent real business problems.
- Simple scope is often the more disciplined choice, not a lesser one.
Frequently asked questions
Questions to consider before the next step.
Conclusion
