Maintenance request management system on Tadabase for an energy company
A single internal platform for logging requests, tracking statuses, coordinating technical teams, and giving management operational dashboards — without building a heavy custom ERP.
About the Project
The service lets employees submit equipment or infrastructure repair requests through a web form by selecting the site, describing the issue, setting a priority, and attaching photos. From there, the request moves through a standard lifecycle: registration, assignment, execution, verification, closure. Dispatchers work in an internal interface where they see the queue, filter tasks by site and work type, and monitor technician workload. Management gets dashboards with request volume, average processing time, and the locations that keep showing up as problems.
About Customer
Tomasz is Managing Director at DeveEnergy and an engineer with 15+ years of experience in gas turbine services and power generation projects. He's a Chartered Engineer and a certified Project Manager who has worked with major OEM suppliers and independent service companies across four continents. His remit covers field operations, contracts, service processes, and quality standards — where the cost of a mistake is measured in equipment downtime and contractual penalties.
Scattered maintenance requests
Fault reports were coming in through different channels, weren't stored in one place, and carried no transparent execution status.
Unformalized request handling
Each department processed requests in its own way: different statuses, different prioritization rules, no agreed task lifecycle.
Roles and permissions
Access had to be separated between requesters, dispatchers, technicians, and managers — each role sees what it needs, while the data stays consistent across the system.
Low-code platform limitations
Tadabase ships with ready-made components, but more complex scenarios — approvals, notifications, extra checks — needed careful design.
Reporting and dashboards
Management needed aggregated indicators by site, by work type, by assignee.
Moving away from manual processes
The system had to go live without a long parallel period, which carried real risk of pushback if the interface felt complex or unclear.
Proposed Solution
We designed a full request-management system on Tadabase with four roles — requester, dispatcher, technician, manager. The data model, statuses, forms, and dashboards live as a low-code application; the more advanced notification and integration scenarios sit in a separate Node.js backend service.
Process definition
We started by fixing the core scenarios — how a request is created, who receives it and assigns it, how it closes. The special cases got their own treatment too: escalations, repeat requests, deferred tasks. From that, we settled on one shared set of statuses and transitions.
Data model in Tadabase
Inside the platform, we configured collections for requests, sites, work types, users, and teams. Every entity got required fields, relationships, and baseline validation, so half-empty records couldn't make it into the database. The structure was designed with the future reporting layer in mind.
Roles, permissions, and working interfaces
Each role has its own data view: simple submission forms for employees, queues and filters for dispatchers, lists of assigned tasks for technicians. Roles limit visibility and actions without duplicating data across separate versions of the system.
Automations and notifications
Part of the logic was implemented through Tadabase's built-in rules and triggers. The rest sits in a Node.js service handling email and SMS notifications on status changes, reminders for overdue requests, and dispatcher alerts.
Dashboards and reporting
For management we built several dashboards — the current request queue, distribution by site, average and median time to resolution, top issue categories by work type. The data aggregates from the operational tables and surfaces operational bottlenecks at a glance.
Integrations and extensibility
We left a REST API surface in place for connecting external systems later — email gateways, the company's internal portal, a future SAP/ERP touchpoint. The configuration is set up so new request types can be added without changing the working modules.
We interviewed dispatchers, technicians, and site managers. Each described what a typical day looks like in their role: where requests come from, how they currently get logged, what counts as completed work. From those conversations, we formalized the goals for the system — kill the duplicate channels, raise the transparency of statuses, and give managers an aggregated view without radically reshaping the current way of working.
+1 Resource
Results
The Tadabase platform replaced scattered calls and email chains with one repair-request system that gives the team a full operational picture by site, hands technicians clearly structured tasks, and gives management transparent numbers on load and response speed.
72% fewer
lost requests
−41% average time
to assign a technician
−28% average time
to close low- and medium-priority incidents
100% transparency
around SLA performance for management
35% fewer
manual clarifications in chats and calls
22% fewer
repeat requests for the same issues
Weekly reporting time cut
from 60 minutes to 10
Get in Touch
Or send us a message and we'll get back to you within 15 minutes during business hours