Everything a piano program has to keep track of.
Seven modules, one register underneath all of them. A technician can work the whole day in the platform without opening a spreadsheet, and a director can answer a budget question without calling the technician.
The register
The system of record. Everything else reads from it.
For technicians: The register becomes your daily reference — no hunting through spreadsheets for serial numbers or details. One scan or search gives you full history and current status.
For institutions: You know what you own, where it is, and what condition it's in. When a technician leaves, the data stays.
- Identity. Make, model, serial number, year built, size, type, and a stable instrument code that never changes even when the piano moves.
- Location. Building, room, and assignment, with room merges and building corrections handled as first-class operations rather than find-and-replace.
- CAUT factor codes. Condition, rebuild parameters, climate, age, usage, standards of maintenance, and class — the seven inputs the workload formula needs, stored per instrument.
- Photographs. Images attach to the instrument, the room, or the building. Serial-plate shots settle arguments about which piano is which.
- History. Every status change, comment, assignment, and completed service stays on the record permanently.
- Bulk work. Spreadsheet import, bulk field editing, duplicate merging, missing-value sweeps, and age auto-fill from serial data.
QR tags and public intake
The manual asks for a way anyone can report a deficiency. This is that, without accounts.
For technicians: Requests don't disappear into email. They're tracked, assigned, commented on, prioritized, and closed — all in one place. For contractors, each request is associated with a client institution for later service documentation.
For institutions: You can see what students and faculty are reporting, how fast problems are resolved, and whether certain instruments are trouble spots.
- A tag per instrument. Generate QR codes for the whole register at once and print them to Avery 5162 label sheets or a plain grid.
- A landing page per instrument. Scanning opens that piano's public page: specifications on one side, a service request form on the other.
- Requests that identify themselves. The form arrives already knowing which piano, in which room, in which building — so nobody files a ticket for "the one by the window".
- Structured complaints. Sticky keys, broken keys, buzzing, pitch, cleaning, plus free notes. Common faults become countable.
- Availability at a glance. The same page can show when the instrument's room is free, so a requester picks a time that is actually open.
Tickets and assignment
Daily routine and emergency repair, tracked as work rather than as email.
For technicians: You see exactly what's assigned to you and what's open, without digging through email threads or sticky notes.
For institutions: Cycle time becomes measurable — you can see how quickly reported problems actually get resolved.
- Claim or assign. A technician takes a ticket, or a lead assigns it. Both are recorded.
- Status you can report on. Open, claimed, in progress, complete — with timestamps that make cycle time measurable.
- Threaded comments. Notes stay attached to the instrument, not in someone's inbox.
- Checkups. Schedule a look-at without waiting for a complaint.
- Personal queues. Each technician sees their own assignments; the lead sees everyone's.
Scheduling against the building
The Guidelines note that scheduling access to faculty and performance spaces is crucial. That requires knowing what the room is already doing.
For technicians: You see room availability before you schedule. You don't waste a trip to find a room in use.
For institutions: Tuning happens strategically, not reactively. Performance instruments get the attention they need without interrupting rehearsals or classes.
- Institutional calendar import. Room and hall schedules pull in from the department's existing calendars, deduplicated on import, with a log of every run.
- Outlook sync. Tuning appointments can round-trip to a technician's own calendar.
- Feeds out. Availability publishes as ICS and RSS for anyone who needs to subscribe rather than log in.
- Holds and bookings. A requested slot can be held while details are confirmed, then booked — so two people cannot claim the same hour.
- Concert-day awareness. Performance instruments are tuned the day of the event; the schedule shows which days those are.
Reports
Built to be printed and handed to someone who does not work on pianos.
For technicians: Business tools, not just recordkeeping — the reports you generate can justify staffing requests or win contract renewals.
For institutions: Reports formatted for people who don't work on pianos — no technical jargon required to read them.
| Report | Answers | Typical reader |
|---|---|---|
| All Pianos with Workload | Per-factor averages across the inventory, recommended workload, and FTE technicians required, with the arithmetic shown. | Dean, business officer |
| Inventory Status | What is in the fleet, where, in what condition, and what is retired. | Lead technician |
| Current Status Overview | Open work right now, by instrument and by technician. | Lead technician |
| Unserviced Pianos | Instruments that have gone past their service interval, ranked by how far past. | Lead technician, dean |
| Recent Requests | Everything reported in the last fourteen days, and what happened to it. | Front office |
| Weekly Status by Tuner | Work completed per technician per week. | Supervisor |
| Humidifier Refills | Which climate systems are due for water, and which have been missed. | Technician, work-study staff |
Every report prints cleanly and exports for a committee packet.
Climate, deterioration, and money
“The importance of humidity control to the quality of piano service cannot be overemphasized.” The platform treats it as a financial variable, because it is one.
For technicians: You can quantify the impact of climate instability on workload. You have data to support requests for humidity control.
For institutions: You can model the ROI of climate improvements and budget for humidifier maintenance as recurring work instead of an afterthought.
- Climate code per instrument. Relative humidity variance banded to the CAUT scale, from 5-point variance down to uncontrolled.
- Deterioration curves. Condition modelled over time against the current climate code and against an improved one, side by side.
- Lifespan effect. Baseline service life adjusted by climate band, separately for grands and uprights.
- Cost projection. Annual maintenance cost as a function of climate quality, accumulated over the twenty-year planning horizon, with the net effect of an intervention shown as a figure.
- Refill tracking. Installed humidity systems need water weekly. That work appears on a list instead of in someone's memory.
Valuation and replacement
Pianos often outlast the buildings they sit in. The Guidelines argue for treating them as capital. That argument needs numbers.
For technicians: You have financial justification for recommendations — "this piano should be rebuilt" becomes a real cost comparison.
For institutions: You can plan capital investment on a schedule instead of waiting for a crisis, and show finance that maintenance tracks the CAUT-recommended percentage of fleet value.
- Replacement value per instrument, with defaults by type that you can override per piano.
- Fleet valuation as a single figure — the basis for the five-to-ten-percent maintenance budget the manual recommends.
- Replacement sequencing across a twenty-year horizon, so purchases are staggered rather than arriving as one unaffordable request.
- Rebuild versus replace comparison, using the rebuilding-parameters rating already on the record.
Access, tenancy, and care
Institutional software has institutional obligations.
For technicians: You see only what you need to do your job. Contractors can manage multiple clients separately, with clean data boundaries.
For institutions: Clear separation of concerns — service data is logged by technicians but interpreted by administrators, and requesters only see the instrument in front of them.
- One tenant per institution. Separate subdomain, separate database. Nothing is shared between schools.
- Roles. Lead technician, staff technician, contractor, administrator, and public requester each see what their job requires.
- Contractors included. Most college technicians are independent contractors; they get accounts and assignment queues like anyone else.
- Data health. Built-in checks for duplicate instruments, orphaned rooms, missing factor codes, and blank required fields.
- Backups and monitoring. Scheduled backups and automated checks on the search and request paths.
- Accessibility. Built to WCAG AA: keyboard navigation, visible focus, contrast, and layouts that work on a phone in a hallway.
Working alongside your existing tools
CAUTtools is designed to complement, not replace, your existing tools. If your technician uses Gazelle (or a similar business-management platform) for scheduling, estimates, invoices, and payments, CAUTtools can sync with it so service work enters the business system once, then flows into CAUTtools for institutional analysis. If you use institutional calendar systems, they import so tuning schedules avoid conflicts. Your existing tools stay in place. CAUTtools adds the institutional layer.
See it against your own inventory.
Send whatever list you have. We will load it and walk the platform with your instruments in it.