The problem
A maintenance log often starts as one shared workbook because that is the fastest place to put a row. Then someone adds a tab for each month. Columns grow: date, asset, problem, who fixed it, parts, notes. Two technicians edit the same row and one change disappears. After a few months the file records edits, not maintenance.
The daily failures are concrete. Asset names are free text, so Pump 3, pump-03 and P3 become three assets. Status hides in a note. Closed dates stay blank. Parts are words in a cell, so you cannot see what a repair consumed. Preventive tasks sit on another tab and never become work orders. A technician at the machine cannot open the file on a phone, so the repair detail arrives by text later. Finance asks for maintenance spend by asset and gets a manual sort.
Permissions are the quiet problem. A shared link usually gives edit access to the whole team. There is no reliable record of who changed a due date or deleted a row. A former contractor may keep access until someone audits the folder. When a warranty claim or safety review needs one asset's repair history, you rebuild it by hand. The spreadsheet lacks required fields, roles and an audit trail.
What a good solution looks like
A good maintenance app is small. It has linked records for assets, requests, work orders, work log entries and parts. An asset record carries a unique ID, location, make, model, serial number, criticality and status. A request is short: who reported it, which asset, what is wrong, a photo, and priority. A work order adds the assigned technician, due date, status and vendor. Work log entries hold labor, parts, downtime, notes and attachments.
Use a fixed set of statuses and enforce the moves. New, Triaged, Scheduled, In Progress, Blocked, Done, Canceled works for most maintenance teams. A work order cannot move to Done without an asset ID, a resolution note and a closed timestamp. The app sets the timestamp. Every edit writes an audit row: actor, time, record, field, old value, new value. Requesters see their requests. Technicians see the queue and asset history. Supervisors see blocked and overdue work. Finance gets a read-only export.
The screen has to work at the machine. Use a responsive layout, large tap targets, and a search box that accepts asset ID, serial number, location or text. The asset page shows every work order, part and attachment in one list. A dashboard answers what is open, what is late, and what keeps breaking. Notifications go to email or chat when a job is assigned, blocked or due. Do not copy every spreadsheet column. Keep the fields that change a decision.
How to build it
Start with one workflow: a request becomes a work order and ends with a close out. Write a one-page spec. Name the statuses. List required fields. Choose an asset ID format, such as site code plus number, and stick to it. Decide who can create, assign, close and reopen. Set response targets for each priority. Timebox the first release. A small maintenance app can go live in weeks if you keep scope tight.
Clean the data before you write screens. Export the workbook to CSV. List every tab and column. Build the asset list first, then map old asset names to new IDs. Split free text parts into a parts table where you can. Import requests and work orders into a staging database. Reconcile row counts and check a sample side by side with the old file. Keep the original workbook as a read-only archive. Mark imported history as legacy.
The data model can be simple. Tables for users, assets, requests, work orders, work log entries, parts, parts used, attachments and audit log cover most maintenance logs. Use foreign keys so a work order cannot point to a missing asset. Put status changes behind a server-side function, not a free edit form. Write the audit row in the same transaction. Use your identity provider for sign-in and map groups to roles. Test a backup restore before launch.
Build the request form, queue, work order page and asset history first. Add exports next. Test with two technicians, one requester and one supervisor. Run real scenarios: a new leak, a blocked part, a vendor repair, a repeated failure, a job closed with a photo. Watch where they hesitate. Fix labels before adding features. Roll out with short training at the machine and a written runbook. For the first week, keep the old file read-only and have one person watch the queue.
Risks and how to manage them
The main risk is that technicians keep using text messages. A form with twenty fields will lose to chat. Keep the request form to five fields and let a dispatcher fill the rest. Make the asset picker searchable and allow a new asset from the request screen. Put a queue view on a shop floor monitor. Have supervisors assign work in the app, not in chat.
Data quality will drift. Asset lists grow, equipment gets replaced and duplicate records appear. Name one data owner. Review new assets and duplicates on a monthly walkthrough. Require a serial number or nameplate photo for every new asset. Do not allow a free text asset field on work orders. For imported history, accept that some notes are messy. Label them legacy and move on. A clean asset list beats a perfect copy of old notes.
Scope creep is the second risk. Maintenance sits next to inventory, purchasing and HR. Each request to add a field, approval step or report needs an owner and a decision. Keep roles narrow: requester, technician, supervisor, administrator and finance read-only. Use single sign-on and group sync so leavers lose access. Make the audit log append-only. Encrypt backups and test that you can export every record. Plan for downtime and staff changes. Keep a paper form and a named person who enters it if the app is unavailable. Write a runbook for common fixes and train two administrators.
How to measure success
Measure the work, not the app. Before you freeze the spreadsheet, record a baseline: count of open work orders, count of overdue preventive tasks, number of assets with no ID, and time it takes a technician to log a request at the machine. After launch, track the same counts. Also track work orders closed without a part record, duplicate assets, and edits to the old file. Those numbers show whether the app replaces the spreadsheet or sits beside it.
Run a weekly maintenance review. The supervisor clears blocked and unassigned work. The data owner checks new assets and duplicates. Finance checks the CSV export against its own records. Ask technicians two questions: which field wastes your time, and what do you still look up in the old file. Fix the first and import or link the second. Retire the spreadsheet when the queue is current and nobody opens the archive for daily work.
If you want outside help, Cloudverg's Internal tool sprint at $16,500 fixed price builds one workflow in four weeks, with sign-in, roles, audit trail, data import, CSV exports, training and a runbook. It is one option among others. A custom build, a low-code tool or a focused CMMS can all work. Pick based on the maintenance workflow you need this quarter and the team that will own it after launch.
Frequently asked questions
What should a maintenance log app track?
It should track assets, requests, work orders, labor, parts, downtime and attachments. Every work order needs an asset ID, a status and a close out note. Keep the request form short and put the detail in the work order.
Should we build a small app or buy a CMMS?
If your maintenance process is one workflow and your team lives in a shared spreadsheet, a small app is often enough. Buy a CMMS when you need deep asset hierarchies, inventory, scheduling and vendor contracts out of the box. Try a narrow build first if the spreadsheet is the real problem.
How do we migrate an old maintenance spreadsheet?
Export each tab to CSV and build a clean asset list first. Map old asset names to new IDs, then import open work orders and only the history you need. Keep the original file as a read-only archive and label imported records as legacy.