Business Management System Development Example for a Plumbing and Water-Services Provider

This case began when a locally focused plumbing and water-services provider reviewed how information was shared from initial reception through on-site work. Office staff who also handled reception received repair requests by telephone and recorded the customer name, address, telephone number, preferred visit time, and fault description on paper dispatch slips. The owner or dispatcher wrote staff names and daily destinations on an office whiteboard, then notified available technicians by telephone or message. Customer information was retained in an Excel ledger, but it was not linked to daily schedules, work photos, or completion reports.

After on-site work was completed, field staff wrote the work performed, parts used, and estimated charges by hand on the dispatch slips. Before-and-after photos were stored on their individual smartphones. During busy periods, when seven to ten visits could overlap in a day, the office had to call staff to determine whether they had arrived, whether parts needed to be ordered, or whether the next visit could be rescheduled. When the same customer contacted the company again, the team had to search the Excel ledger, past slips, and individual photo folders separately, making it difficult to confirm the repair history while speaking with the customer.

Rather than replacing quotation creation, invoice issuance, and accounting integration all at once, the project was scoped around digitizing the flow from initial reception through site visits and completed-work reports. The system was designed for an operational volume that a small company could manage on a daily basis. For field staff, the core actions were limited to checking the destination, updating arrival or completion status, and registering photos. The initial release established a foundation for information sharing, while invoicing and a customer portal were reserved for a possible second phase based on actual usage.

At the office, staff registered a telephone request as a job, assigned a field technician, and set the planned visit time. Field staff used smartphones to check their jobs for the current and following day, then updated the job status to “En Route” and “In Progress.” Once work was complete, they entered before-and-after photos, the work performed, parts used, and any follow-up requirement, then reported the job as “Complete” to the office.

For the estimate, the functions required by customer-service and dispatch staff, field staff, and administrators were clearly defined as the initial scope. This made it possible to deliver the project for ¥1.58 million before tax over approximately eight weeks. Invoice issuance, inventory management, payment processing, accounting-software integration, and a customer portal were outside the initial scope and were positioned as possible second-phase functions after the initial operation became established.

To control costs, AI assistance was used for similar screens, standardized processing, and test preparation. However, the project team reviewed and adjusted the dispatch-slip field design, role definitions, handling of photos containing personal information, exception handling, code review, and user-acceptance testing to ensure that the system fit the actual business.

The initial release was limited to the functions required to take a repair request through to a completed-work report for the office. Finalizing service charges, issuing invoices, inventory management, and customer email distribution were outside the initial scope; the client continued to use its existing accounting software and business processes for those functions.

Workflow and Screen Overview

Main Data Managed by the System

Technical Architecture and Security Policy

The front end was built with TypeScript and a React-based framework as a responsive web application that works on both PCs and smartphones. Because field staff entered information while travelling or after completing work, the screens minimized text input and prioritized large status buttons and camera-launch buttons.

REST APIs were implemented for jobs, customers, staff, work reports, and attached photos. Input values were validated when jobs were created or updated, and field staff could update only the jobs assigned to them. Administrators could view and reassign all jobs, while authorization was enforced through the API as well as the interface.

During the first two weeks of the approximately eight-week project, the team reviewed the paper dispatch slips and the actual flow of telephone reception and dispatch. Defining input fields and operating rules early helped prevent rework caused by missing required fields or uncertainty about when a job should be marked complete.

Payment Terms

As a general rule, no up-front payment was requested. There was no payment at contract signing; the full amount was invoiced only after all development work was complete and the client had completed acceptance.

The following amount included implementation of the functions defined in the initial phase, testing, and production-release support. Invoice issuance, inventory management, payment processing, accounting-software integration, and a customer portal were not included in the initial scope.

Currency Options for Quotations and Invoicing

In addition to Japanese yen (JPY), quotations and invoices can be issued in U.S. dollars (USD) or other currencies upon request. The applicable exchange rate, conversion basis, and any bank or payment-provider fees will be confirmed in advance for each project.

Supplement: Estimated Third-Party Service and Maintenance Costs After Launch

The following figures assume an initial operation with approximately 12 employees, around a dozen regular users, several hundred jobs per month, and attached work photos. These expenses are separate from the initial development cost. Cloud services required to operate the web application in production, as well as any monitoring or notification services selected, incur third-party service charges paid directly to the respective providers.

The third-party cloud-service figures are a model estimate informed by published pricing structures for managed database, authentication and file-storage services, web hosting, and object storage.

For small businesses like this plumbing and water-services provider, where telephone reception, site visits, and photo-based completion reports occur daily, it is effective to begin by focusing on sharing each job’s status between the office and the field. Rather than abruptly replacing existing accounting software or invoicing procedures, the initial release moves only the dispatch-schedule and completion-report functions that had been distributed across paper dispatch slips, a whiteboard, and an Excel ledger into a web application. This approach helps the new workflow take hold without overburdening the field team.

Typical Scope for Common Add-Ons

After the initial release has become established, a customer portal may be added so customers can log in and view planned visit times, work history, photos, and quotations. Because the existing customer and job data can be reused, a typical estimate is an additional ¥600,000–¥900,000 before tax and approximately 4–6 weeks.

An online payment integration may also be added to issue a payment link after an on-site repair. This approach uses an external payment service and does not store credit-card information in the company’s own system. A typical estimate is ¥500,000–¥700,000 before tax and approximately 3–5 weeks.

Adding both the customer portal and online payment as a second phase is estimated at an additional ¥1.0 million–¥1.6 million before tax and approximately 7–9 weeks. Combined with the initial release, the total would be approximately ¥2.68 million–¥3.18 million before tax. Separate design and estimation would likely be required if the project also needed split billing, batch management of multiple properties, parts-inventory integration, manufacturer-warranty inquiries, or two-way integration with accounting or core business systems.

By first digitizing daily dispatch slips and completion reports reliably, then expanding in stages based on the functions actually needed in operation, the business can avoid unnecessary investment and grow the product into a better fit for its own workflow.