Museum audio guide software

What to inspect in a real museum deployment

Compare how the guide is introduced as well as how it plays. The New Zealand Rugby Museum example shows paid guide access on a visitor’s phone; the Shantytown article describes free access and English-language listening. They illustrate different access models, not a forecast of sales or visitor uptake for another venue.

Kaikoura Museum’s directory entry includes photographs of the audio-guide display and a QR code beside an exhibit. Use those examples to plan where a visitor will discover your guide, then test the journey from that location on your own phone.

Journey Pal museum audio guide software at a glance

Journey Pal combines the visitor guide and the museum's content workflow in one browser-based platform. A museum can publish a focused highlights route or a larger collection, offer every prepared language from the same QR code, and update the guide without replacing that printed access point.

The software is already used by seven New Zealand museum and heritage venues, including the New Zealand Rugby Museum, Bill Richardson Transport World, Lakes District Museum, Kaikoura Museum and the Buried Village of Te Wairoa. These live installations give museum teams real examples to inspect rather than relying only on a supplier demonstration.

• QR access on visitors' own phones, with no app download or account required
• Written interpretation and audio together in up to 34 supported languages
• Content and language updates without reprinting an existing QR code
• Free or paid guide access, set by the venue
• Anonymous usage data for guide stops and visitor languages

What the software actually does

Stripped back, an audio guide system does four things: it holds your stops and their audio, it decides which version a given visitor gets, it delivers that to them somehow, and it lets you change all of the above without starting again.

Museums tend to evaluate the third of those, because delivery is the visible part. The fourth is what determines whether the guide is still accurate in three years. A guide that cannot be edited by the people who know the collection will drift out of date the first time an attribution changes or an exhibition moves.

The first two matter most once you go multilingual. Holding eight versions of forty stops, and reliably getting a Japanese visitor to the Japanese one, is a content management problem rather than an audio problem.

The capabilities that matter

Most feature lists are longer than they need to be. These are the ones that change how a guide performs in a real gallery:

• Content editable by your own staff, without going back to the supplier for a wording change
• Multiple languages per stop, with visitors routed to theirs automatically
• Delivery that works on a visitor's own phone, since that is the device everyone already has
• Stops that can be added or retired without reprinting or reissuing anything
• Usage data showing which stops and languages visitors actually choose
• A free or paid access decision that is yours to change later
• Transcripts alongside audio, for visitors who cannot use audio and for search engines

The delivery model drives almost all of the cost

Two systems with identical features can differ enormously in what they cost to run, and the difference is nearly always hardware.

A device-based system carries purchase cost, then charging, cleaning, repair, loss, and the staff time to hand devices out and take them back. That last one is a permanent daily tax on your front desk, and it also caps your busiest days at however many units you own.

A system delivered to the visitor's own phone removes that line entirely. What remains is content cost, which is mostly one-off, and signage, which is a few dollars a sign. This is why a small museum can now run a multilingual guide that would have been out of reach a decade ago.

The question worth asking a supplier is not what the platform costs per year, but what it costs to change something, and what it costs on your busiest day.

Questions worth asking any supplier

These separate systems that demo well from systems that work in year three:

• Who edits the content after launch, us or you, and what does a change cost?
• What happens when we add a ninth language: new contract, or new content?
• If a visitor's phone is set to a language we have not published, what do they get?
• What do we own if we leave, and can we export our audio and scripts?
• How does the guide behave on weak connectivity in a stone building?
• Can we see usage data at stop level, or only totals?

What suits a small museum

Small and mid-sized museums are badly served by systems designed for national institutions, which assume a dedicated digital team and a procurement cycle. The practical requirements at a smaller venue are different: no hardware to manage, no specialist to employ, content that a curator can edit between other duties, and the ability to start with ten stops rather than the whole collection.

It is also worth being honest about what a small venue does not need. Indoor positioning, augmented reality, and elaborate branching narratives are impressive in a demo and rarely survive contact with a two-person team. A guide that is accurate, multilingual, and easy to update will outperform a more capable one that nobody has time to maintain.

How to evaluate the software before committing

Test the same journey a visitor will take in the gallery. Open the guide on an ordinary phone, use mobile data, change language, play a stop, read its transcript and move to the next object. Then ask a staff member who was not involved in the setup to make a small content change. Those two tests reveal more than a dashboard presentation.

Supplier evidence matters as well. Look for named museum clients, public visitor-facing examples, installation photographs and a clear account of what the venue team controls after launch. Journey Pal publishes its venue directory and a live visitor demo so these checks can happen before a sales conversation.