Designing a unified ERP architecture

Work began by designing the overall logic for the future system. The client needed more than just a car wash booking form; they required a full-scale information system that integrates several distinct business processes.

A unified data model became the key architectural decision. Clients, vehicles, orders, services, discounts, employees, crews, branches, and contracts were no longer to exist in isolation. For example, when creating a new order, the system automatically finds the client by phone number and pulls up their vehicles, visit history, discount card, vehicle category, and previously provided services. This eliminates redundant data entry and reduces the likelihood of errors at the service point.

The system was designed as a web-based platform with PWA support. This format was chosen in collaboration with the client so that users could work through a browser while also having the option to use the interface as an app on their workstation. For a multi-branch chain, this is more convenient than traditional local software: updates can be rolled out centrally on the server, and employee access can be controlled through authentication and roles.

From a software architecture perspective, the solution was divided into three major subsystems: car wash management, tire service management, and a management dashboard. At the same time, the logic for orders, clients, employees, and discounts remained shared to ensure the system avoids data duplication and can scale to new service locations.

Web + PWA as the employee workflow format

Special attention was paid to how the system is used at the service points. Administrators and cashiers work in a high-traffic environment: they need to quickly find a client, create an order, select services, apply discounts, send the order to the floor, process payments, and close out shift totals. Therefore, the interface had to be simple, fast, and adaptive to daily operational demands.

This format allowed for the development of a web application that is not tied to a specific workstation. Users access the system via authentication, select their available location, and work within the required subsystem. For management, this reduces dependence on local computers at each branch, and for the business, it simplifies system maintenance.

PWA is also well-suited for these service scenarios: the interface can be opened on a tablet, a point-of-sale computer, or a laptop without installing a separate desktop application. As a result, the client received more than just an internal website; they gained a functional and adaptive corporate service for daily management of the chain's operations.

Order and queue management

One of the central modules is the order management system. In car wash and tire service operations, an order goes through several stages: appointment, queue, service, completion, payment, and archival. It is essential for the administrator to see at any moment how many vehicles are in the queue, how many are currently being serviced, which orders are finished, and which require further processing.

The system features an order card with an automatic number, client details, phone number, vehicle make, model, license plate, vehicle category, service list, price, discount, unique code, comments, and assigned crew. If the client is already in the database, their information is pulled automatically. If the client or vehicle is new, the system allows them to be created directly during the order entry process.

A specific challenge was that service pricing depends not only on the service itself but also on the vehicle category. The system supports five categories, each with its own potential pricing. Therefore, when the vehicle make and model are selected, the category is automatically applied, and the final cost is calculated based on the selected services and client conditions.

To speed up the administrator's workflow, digital service prompts were implemented. Frequently used services can be quickly selected in the interface without navigating through long directories. This is a crucial part of application interface design: in the service industry, even a few extra clicks per order can lead to queues and errors during peak hours.

We also implemented a separate logic for special orders. These orders are visible to the administrator while they are in progress or in the queue, and completing them requires a specific action involving payment and a comment. This allows for separating the standard service flow from situations that require additional oversight.

Customer CRM and vehicle service history

As part of the project, we developed a CRM system from scratch, integrated directly into the operational workflow of the car wash and tire service. This is a key point: the CRM here is not a separate directory where someone manually enters customer data after service. It operates in real-time as the order is being created.

The system stores the customer's full name, phone number, vehicles, license plates, makes, models, discount cards, order history, and tire storage data. When a customer returns, the administrator can quickly find them by phone number or license plate. The system then displays the service history, recent orders, and current discount terms.

For the business, this reduces errors when working with repeat customers. For example, there is no need to ask for the vehicle model again, recall the category, look up a discount, or check past services. The system automatically retrieves the necessary data, helping the administrator process the order faster.

Unified logic for car wash and tire service

Although car washing and tire services are different service areas, their operational logic is largely the same. Therefore, the system was designed not to create two completely independent programs, but to use shared entities and reuse business logic.

The tire service subsystem inherited the same basic sections as the car wash: orders, billing, order history, discount cards, employees, and appointment scheduling. This maintained a consistent user experience for staff while allowing for the addition of specific tire service functionality, such as storing sets of tires and wheels.

This approach is crucial for business software development: if multiple departments within a company operate under similar rules, it is better to unify them under a single architecture rather than creating separate solutions with different interfaces and databases.

Tire storage subsystem and document generation

One of the most specialized modules is the tire storage subsystem. This is a distinct business process that requires not only tracking the customer and vehicle but also preparing documents, recording set specifications, managing storage periods, and handling the subsequent return.

The system supports the creation and editing of storage agreements. The agreement records the vehicle make and model, customer's full name, phone number, agreement number, customer address, ID details, and storage duration. Once the data is entered, the system generates the agreement in PDF format and redirects it to the print page.

After the agreement is created, an intake report is generated. It records the set's parameters: tires with or without rims, new or used, steel or alloy wheels, presence of hubcaps or center caps, quantity, size, radius, brand, model name, load index, comments, and photo documentation. Some data is automatically pulled from the agreement so the employee does not have to re-enter it manually.

For an active agreement, there is an option to generate a return report. Thus, the subsystem covers the entire storage lifecycle: agreement, intake, inventory, printed documents, and return to the customer. This is an example of custom software development where standard CRM or POS software does not cover real-world business processes, requiring precise configuration to match the client's operational model.

Discount system and loyalty program

A separate module was implemented for the discount system. For car washes and tire centers, a loyalty program is especially important: customers often return with the same vehicle, service multiple cars in a family, or use services seasonally.

The system stores the discount card number, owner, phone number, linked vehicles, discount percentage, card status, comments, and information on who assigned the discount. A basic card is issued with a specific discount, which can then increase based on a cumulative formula. Additionally, there is a provision for manually adjusting benefits for individual customers.

This logic requires careful implementation: the discount must be correctly applied to the order, displayed to the administrator, factored into the discounted price, and remain manageable by the manager. At the same time, the manager must be able to see who changed the terms, why the discount was applied, and whether the card is currently active.

The discount module became part of the overall CRM development logic because the discount is tied to the customer, their vehicles, order history, and employee actions.

Corporate agreements and fleet maintenance

The manager's dashboard includes a contracts section for companies that have signed agreements to service their vehicle fleets. The contract records the number, name, expiration date, discount rate, list of vehicles, comments, and individual terms.

When vehicles are added to a contract, they are saved in the database with a corresponding note. When processing an order, staff can see that the vehicle is serviced under a corporate contract, and payment can be handled via the contract rather than by cash or card.

This is a vital part of the system for B2B scenarios. Car washes and tire shops work not only with private clients but also with companies that have their own fleets. Therefore, the ERP had to support not just one-off orders, but long-term contractual relationships as well.

Managing Personnel, Roles, and Branches

The system features employee profiles containing names, phone numbers, roles, earnings, penalties, and login passwords. Employees can be grouped into teams, and a team can be assigned to an order. This allows the work performed to be linked to specific staff members and ensures accurate calculation of earnings.

Special attention was paid to access control. Authorization is performed via phone number and password, and upon logging in, the user selects a service location. An employee at one location should not have access to data from another. If an employee temporarily works at a different branch, a separate account is created specifically for that location.

This access model is necessary not only for security but also for clean reporting. A cashier should see data for their specific location, an administrator should manage their own flow of orders, and a manager should oversee the entire network. This is an enterprise-level system where it is essential to account for roles, branches, permissions, financial transactions, and management oversight.

A manager's dashboard was developed for executives—essentially an internal corporate portal for managing the network. It provides full analytics on clients, employees, discount cards, location performance statistics, service lists, orders, and corporate contracts.

Managing Services and Pricing by Branch

The service directory was designed as a manageable module rather than a hard-coded list. In the manager's dashboard, you can create and edit services, set prices, add quantitative parameters, and apply pricing to individual locations.

This is important for a network: different branches may operate in different shopping centers, have varying foot traffic, different lease terms, distinct pricing policies, and different service offerings. Therefore, the system had to allow for setting uniform prices across multiple locations or configuring specific prices for a particular branch.

This approach makes the ERP flexible: the business can change prices without having to contact a developer every time. This is one of the key goals of business software development—moving operational settings from the code into the management interface.

Financial Analytics and Daily Reporting

The system includes an analytics block for managers and cashiers. Statistics are generated separately for car wash and tire shop services, as well as by service location. Reports account for cash revenue, non-cash revenue, total number of vehicles, revenue from special orders, revenue from contracts, and average ticket size.

For the cashier, this data is needed for daily reports on washing, tire services, and storage. For the manager, it is used to monitor branch efficiency, assess workload, analyze revenue, and verify financial discipline.

This block can be viewed as an internal business intelligence system: it does not replace a full-fledged BI platform, but it provides the manager with actionable metrics directly within the ERP. The system generates interactive reports linked to real orders, payments, services, employees, and branches.

Automated reporting is particularly significant. While cashiers and managers previously had to collect data manually, key metrics are now generated based on operations within the ERP. This reduces the risk of discrepancies and speeds up the preparation of the daily management summary.

Operation Auditing and Change Control

The manager's dashboard includes order monitoring, where you can view canceled transactions, price changes, and deleted orders. Such actions are highlighted separately so that a manager can quickly spot unusual situations.

This is an important technical and management layer. In the service business, financial discrepancies often arise not from major errors, but from small manual changes: an order was deleted, a price was changed, a discount was applied irregularly, or payment was processed using the wrong method. Therefore, the system must not only allow operations to be performed but also maintain transparency regarding what took place.

For the client, this means better control over cash discipline and fewer disputes between administrators, cashiers, and managers.

‍