How long does it take to make an audio guide?

A realistic timeline for a first guide

For a small to mid-sized museum producing a first guide of ten to twenty stops, six to ten weeks is a realistic span from decision to launch. That assumes staff are doing this alongside their normal jobs, which is the usual situation.

The distribution is lopsided. Scripting and internal approval typically take more than half the total. Translation runs one to two weeks per round once a source script is locked. Voicing is days. Publishing and QR signage is days. The platform work is rarely the constraint.

Museums that move faster than this almost always do so by cutting the number of stops rather than by compressing any single stage.

• Scripting and approval: 3 to 5 weeks
• Translation, once the source script is locked: 1 to 2 weeks
• Voicing and audio review: 3 to 7 days
• Publishing, QR signage, and testing: 3 to 5 days

Approval is the stage that slips

The single most common cause of a delayed guide is an approval chain that was never mapped. A script goes to a curator, then a director, then a board, then a cultural advisory group, and each pass adds a week that nobody scheduled.

Map the chain before writing starts and agree who has to sign off, in what order, and by when. Where cultural material is involved, that review is not optional and it should be scheduled early rather than treated as a final check, because changes arriving after translation and voicing are the expensive kind.

It also helps to approve one representative stop before writing the rest. Getting agreement on tone and length on a single stop prevents a full rewrite after twenty stops are drafted.

Start smaller than you want to

The fastest route to a live guide is fewer stops. A guide covering the ten objects that matter most can launch in weeks and be extended continuously afterwards. A guide covering the entire collection tends to stall somewhere in the middle and launch months late, if at all.

A pilot also produces information that planning cannot. Once visitors are using a guide you learn which stops get finished, which get skipped, where people expect a stop and find none, and which languages are actually selected. Every one of those findings improves the next twenty stops.

This works because a browser-based guide is not a fixed print run. Adding stops later does not mean reprinting anything or asking visitors to update an app.

Where translation time actually goes

Translation itself is quick. The delay is the loop around it: sending the source text, waiting for a return, having someone who speaks the language review it against the collection, and applying corrections.

Two things shorten that loop more than anything else. Lock the source script before translation starts, because a source that keeps changing means retranslating and re-reviewing in every language. And line up your reviewers before the translations arrive, since a translated script sitting in an inbox waiting for a reviewer is the most common hidden delay in a multilingual project.

If a language has no available reviewer, that is worth knowing before you commit to it rather than after.

Signage is short but it is not zero

QR signage is a small task that is frequently left until the end and then discovered to have its own lead time. Designing, printing, and mounting signs in a gallery can involve an external printer, a facilities process, and in some buildings a heritage or planning constraint on what can be fixed to a wall.

Start signage in parallel with scripting rather than after voicing. The QR destinations can be created before the audio behind them is final, which means signs can be designed, printed, and even mounted while content is still being approved.

Test the signs in the actual lighting and at the actual height before printing the full run. A code that scans on a desk does not always scan in a dim gallery behind glass.