A facilities director walked the counter area on a Wednesday morning in March and did the math out loud. Fourteen staffed handset transactions in the last hour. Three confused visitors. One broken device. One missed language request. One returned handset with someone else's earwax. She turned to me and said: "I want these gone by September."
Retiring a handset program is a decision most museum operators make privately for a year or two before they finally sign off on it. By the time the call happens, the case is already overwhelming — the rental fees have drifted up, the adoption numbers have drifted down, the repair invoices are creeping into territory nobody budgeted for, and a meaningful share of visitors are pulling out their own phones anyway. The question isn't whether. It's how to do it without the visitor experience falling through a crack between systems.
This is the playbook we walk museums through when they've made the decision and now have to execute.
Why "just switch it off" doesn't work
The most common failure mode at this transition is pure subtraction. Director decides the handsets are going. Operations gets told "by end of Q3." A communications plan never quite gets written. Front-of-house learns the news from a sticker on the rental counter saying the handsets are being retired. Visitors learn the same way, from the same sticker, often after they've queued for five minutes.
The first week after a cold cutover looks like this: ticket-desk staff improvising explanations they weren't given, visitors who came specifically for the handset-format guide walking out visibly annoyed, reviews on Google citing "removed the audio guide without telling anyone" as the reason for a three-star rating, and the director's inbox filling up with board members asking what happened.
None of this is necessary. The fix is that retiring a handset program is a communications job as much as a logistics one, and it needs a timeline that starts before the public notices anything has changed.
The four-stage playbook
The clean version of this project runs four stages, usually across 12 to 16 weeks.
Stage one: internal decision and hard dates. Before anything visitor-facing happens, three decisions need to land in writing. Last rental day — the specific calendar date after which no handset leaves the counter. App-exclusive day — the date after which the new system is the only official guide at the museum. Disposal deadline — the date by which the fleet is off the premises. These are not flexible. If they drift, every other stage of the project drifts with them.
This stage also produces the single-source FAQ and the front-of-house script. Operations, accessibility, and communications all sign off on them together. The script is the answer to "where's the audio guide" from week one onward, and it has to be good enough that a staff member on their second shift can deliver it without improvising.
Stage two: parallel run. Both the handsets and the new app are available. The app is the default — signage leads with it, reception mentions it first — but the handsets are still there for visitors who specifically ask, and for accessibility cases the app doesn't yet fully serve. This stage typically runs 4 to 8 weeks, and the goal is to move the adoption curve. If the app is good, handset rentals should drop by 60-80% during parallel run without any forcing.
Measure weekly. Handset rentals, app scans, questions at the desk, review sentiment. If app adoption is trending up and handset demand is trending toward zero, you're ready to cut. If handset demand is holding steady, something structural is wrong and you need to fix it before you cut — usually it's that signage hasn't done its job, or that front-of-house is still leading with the handset out of habit.
Stage three: firm cutover. The handsets come off the counter. Signage updates. Reception script updates. Any remaining hardware-specific accommodations (device loan for a disability-specific visitor) move to a named, behind-the-desk process rather than a staffed counter. This stage lasts about 2-3 weeks of settling in, during which you're watching for visitors who arrive expecting handsets and making sure the fallback experience — a brief, human, helpful redirect to the app — is consistently good.
Stage four: decommissioning. The physical fleet is staged for disposal, donation, or refurbishment. Charging infrastructure comes out. Counter space gets repurposed. IT systems tied to the old program (asset management, CRM integrations, data feeds) get decommissioned cleanly rather than left hanging. This stage often gets skipped because the operational fire is out — don't skip it. Old systems with credentials still active are a future security and compliance problem waiting to show up.
The visitor communication that actually matters
Most of the visitor-facing risk in this transition is concentrated in a small number of moments. Get those right and the rest is easy.
The ticket desk first-mention is the single most leveraged sentence in the whole project. Every visitor who buys a ticket gets one line from the staff member: "Our audio guide runs on your phone — you can scan the code at the entrance and it's included with your admission." That's it. Not a pitch. Not an apology for the handsets being gone. One line, delivered naturally, every time. Get this line right and 90% of the communication job is done.
The entry signage does the second-mention. A clear, well-placed sign at the point where visitors enter the first gallery, showing the QR code and one sentence of instruction. The visitors who tuned out the desk catch it here.
The website update is the pre-arrival work. The museum's website should say what the guide is now before visitors buy tickets, not after. Update the "plan your visit" page, the ticketing confirmation email, and the FAQ. Anyone who arrives expecting a handset because the website told them that's what the guide was will be annoyed, and they'll be right.
The review-response script handles the inevitable. A small number of visitors will leave reviews complaining about the change. The response template is short, friendly, and points at the new experience: "Thanks for visiting. We updated our audio guide to run on smartphones — this lets us offer it in 30+ languages and keep it up to date. Next time, look for the QR code at the entrance." That's the whole reply. Don't argue, don't explain, just surface the new option.
Where the accessibility question lives
The handset program at many museums was, quietly, the accessibility program. Visitors with certain disabilities used the handsets because they were a known, staffed, predictable format. When you retire the program, you inherit the obligation to replace what the handsets were doing for those visitors, not just the interpretive layer.
Two accessibility-specific considerations deserve explicit project time.
Visitors who can't use their own smartphone. Some visitors genuinely don't have a device with them, or can't operate one in the way the app requires. The answer isn't "too bad." The answer is a small, named, loanable-device pool — typically 5-15 unbranded devices kept behind the desk, issued to visitors who need one, with a streamlined loan process. This isn't a handset program; it's a loaner-device service, which is a different operational shape. We've covered the design pattern in audio guides for visitors who want accessibility.
Audio description for blind and low-vision visitors. Some handset programs included dedicated audio-described tracks. If yours did, the new system has to match or exceed that provision on day one, not "eventually." Audit what was available on the old system and confirm parity on the new one before the cutover, not after.
The quiet financial case that makes the rest possible
The reason this project is worth doing at all is almost never "we'll save money on rentals" alone. The real case is that the handset program was a cost center that grew with adoption, and the replacement is a system where the museum's cost is aligned to the engagement visitors actually want.
Legacy handset programs run on fixed annual rental fees plus variable costs (batteries, repairs, labor at the counter, content updates). The more successful the program, the more it costs to operate. A museum with 200k visitors a year and 20% adoption is running 40k handset transactions annually, and paying labor costs, device wear, and maintenance pro rata. Efficiency moves in the wrong direction.
Modern platforms like Musa price on per-interaction or revenue share. The museum pays for the engagement that actually happens, with no capex for fleet replacement and no labor bill for counter staffing. Higher adoption doesn't become a bigger operational burden — it becomes margin. That's the shift that makes retiring the handset program something other than a pure cost cut. It changes what the audio guide is on the balance sheet entirely. We laid out the full cost model in audio guide total cost of ownership, and the case for switching in audio guides worth replacing existing system.
A short word on what not to do
The single most common mistake in this project: keeping a small handset fleet "just in case" after the main program retires. Ten or twenty devices in a drawer, a staff member trained to hand them out, maintained indefinitely in parallel to the app. It sounds like a safe compromise. It is a quiet financial and operational cost that undercuts the efficiency case for the retirement in the first place.
If you have a specific, documented accessibility case that the app doesn't yet serve, solve that with a narrow loaner pool and a named owner for it, not with a persistent parallel handset program. If you don't, retire the fleet completely.
The second mistake: letting the disposal stage stretch indefinitely. "We'll figure out what to do with the handsets later" tends to mean they sit in a storeroom for three years while the warranty runs out and the batteries degrade into a fire risk. Plan the disposal in stage one, not stage four. We wrote about audio guide hardware end of life separately, which covers the WEEE and lithium-battery angle in detail.
The third mistake: running the cutover in July. Do not retire a handset program in the middle of peak summer season when front-of-house is already stretched and half the staff are on holiday. September, January, or February are the right months. Peak season is for settled systems, not transitions.
A closing position
Retiring a handset program is an institutional transition, not just a procurement change. The visitors who used the handsets still want interpretation. They still want language coverage. They still want help finding their way around. The job of the project isn't to take something away — it's to replace the delivery layer while the underlying service stays continuous or improves.
Museums that execute this well end up with higher adoption, better language coverage, lower operational burden, and a visitor experience that feels more modern without feeling abrupt. Museums that execute it poorly end up with a bad quarter of reviews and a staff team that learned the hard way what change management costs when it's skipped.
If you're at the point where the decision has been made and the execution is what's left, we're happy to walk through the timeline for your specific museum — including the accessibility and communications pieces, which are usually where the project quietly succeeds or fails.