Most museums don't have a content management problem with their audio guides. They have a content management absence. The guide was produced once, shipped, and nobody has a good way to touch it again without restarting the entire production cycle.
This works until it doesn't. An exhibit rotates. A gallery closes for renovation. New research changes the interpretation of a key piece. The audio guide keeps saying the old thing because updating it means hiring the same production team, re-recording, re-editing, and redistributing. So nobody updates it.
The question isn't whether museums need a way to manage audio guide content. It's what that system should actually look like, because it's nothing like managing a website.
Audio guide content is not web content
A website CMS manages pages, blog posts, media files. The mental model is documents. You write something, publish it, maybe update it later. The content lives on a URL.
Audio guide content is different in almost every dimension. It's spatial, tied to physical locations, floor plans, and walking routes. It's multilingual by default, not as an afterthought. It's layered: the same underlying knowledge might surface differently depending on the tour, the persona, or the visitor's question. And it has to work in real time for people standing in front of real objects.
A traditional CMS built for websites can't handle any of this well. You'd end up with a folder of audio files, a spreadsheet tracking which file maps to which stop, and a prayer that someone remembers to update both when something changes. We've seen exactly this setup at museums that tried to bolt audio guide management onto their existing web tools.
Who actually manages this stuff
There's no universal answer. That itself is the point.
At a large art museum, it might be the education department. At an archaeological site, it's often the lead archaeologist who also happens to know the most about each artifact. Small museums? The director does everything. Heritage houses sometimes hand it to their most enthusiastic tour guide.
The person managing audio guide content is rarely a "content manager" by title. They're a subject matter expert who also needs to publish things. The tools have to reflect that: a system a curator or archaeologist can operate without a training course, not one designed for professional content producers.
In practice, we've found the most common pattern is a single champion within the institution, someone who takes ownership of the audio guide and becomes the go-to person. It might be the museum director, a senior curator, or the head of visitor services. It depends entirely on the organization.
The real bottleneck isn't what you'd expect
You might assume content creation is the hard part. It isn't, at least not with modern tools. Museums already have the knowledge. They have catalog records, curatorial notes, research papers, existing label text, and usually at least one person who can talk about any object in the collection for twenty minutes without notes. The raw material exists. The challenge was always turning it into a polished audio product. AI removes that step.
The actual friction point is more mundane. When a museum first adopts a new content platform, there's often an onboarding period where the vendor does most of the heavy lifting. Data gets ingested, tours get configured, the first version goes live (sometimes in under a week). The museum sees the result, approves it, and moves on to other priorities. Then three or six months later, they want to add a temporary exhibition or update a gallery, and they've forgotten how the tools work. They need a refresher, not a reinvention.
That's a software familiarity problem, not a content problem. The solution is tools simple enough that someone can return to them after months away and immediately remember how things work. Not simpler tools that do less. Tools with clear mental models that stick. If your CMS requires a training session every time someone needs to make a change, the problem is the CMS.
From production to curation
The bigger shift in audio guide content management is about what "content" even means. With traditional guides, "managing content" meant managing a production pipeline: scripts, recordings, edits, translations, files. The content was the audio files. Managing it meant organizing, versioning, and distributing those files.
With AI-generated guides, the content is knowledge. Not scripts. Not recordings. The museum's collection data, curatorial notes, and interpretive guidance are the raw material. The AI generates the actual visitor experience from that material in real time.
That changes what "content management" means. You're not managing audio files. You're managing a knowledge base and the rules that govern how that knowledge gets delivered. Think of it as the difference between managing a music library and managing a band. The library is static files you organize. The band is living: you give them material and direction, and they perform differently each time.
So the CMS for an AI audio guide isn't really a content management system in the traditional sense. It's closer to a knowledge management and curation platform. You're loading data, shaping personas, setting instructions, and designing tours, not editing audio tracks.
What the tools actually need to do
Based on what we've built and what we've seen museums actually use, an audio guide CMS needs to handle a few things that website CMS platforms don't.
Draft and publish states. Museums need to work on content without it going live. A new temporary exhibition might require a week of setup: adding stops, tweaking personas, adjusting tour routes. During that week, the content should be private. When it's ready, you publish. Simple, but surprisingly absent from most audio guide tools.
Flexible access control. Different people need access to different things. The curator editing knowledge and tour design doesn't need the same interface as the front-desk staffer distributing QR codes. One person needs depth. The other needs simplicity.
Tour structure, not just content. Audio guide content doesn't exist in isolation. It's organized into tours with specific sequences, thematic arcs, and spatial logic. The CMS needs to understand tours as first-class objects, not just collections of individual stop pages.
Knowledge that's separate from presentation. The underlying data about an artifact (provenance, materials, history, artist) should be decoupled from how any specific tour presents it. One piece of knowledge might appear in a highlights tour, a kids' tour, and a deep-dive art history tour, each framed differently. If you update the base knowledge, all three tours should reflect it.
Real-time effect. When you change something, visitors should experience the change immediately, not after a rebuild, a redeployment, or a sync cycle.
Three layers of tooling
At Musa, we ended up building three distinct products because the people involved in audio guide content have very different needs.
Musa Studio is the CMS, what we sometimes call an AI Content Management System. This is where curators, directors, and content owners do the substantive work: managing collection data, designing tours, configuring personas, writing instructions, and reviewing how the guide behaves. It's the tool for people who care about what the guide says and how it says it.
Musa Tour is the visitor-facing product. It's what people actually experience on their phones in the museum. Everything configured in Studio produces this: the live tour, the AI guide, the interactive experience.
Musa Field is a simpler interface designed for reception and ticketing staff. These are the people handing out access codes, helping visitors get started, and managing day-to-day distribution. They don't need the full CMS. They need clear, fast tools focused on getting visitors connected to the guide.
We split it this way because a single interface that serves both a curator designing a detailed persona and a receptionist distributing access codes will serve neither well. The curator will drown in distribution settings. The receptionist will be confused by prompt orchestration options.
Versioning and iteration
Traditional audio guides don't really have versioning because there's nothing to version. You have the recording, and that's it. If you make a new one, you replace the old one. There's no concept of drafts, rollbacks, or simultaneous versions.
A proper audio guide CMS needs versioning at several levels. You should be able to draft a new version of a tour without touching the live one. You should be able to see what changed and when. And ideally you should be able to maintain multiple active versions (say, a standard tour and a holiday-themed variant) without duplicating all your underlying content.
That matters more than it sounds. A museum preparing for a major loan exhibition might spend weeks building a new tour alongside their permanent collection tours. If editing the new one risks breaking the existing ones, people won't touch it. The CMS needs to make simultaneous work feel safe.
The separation of knowledge from presentation is what makes this work. The base knowledge doesn't need versioning in most cases; it's factual data that gets updated in place. The tour configurations, personas, and instructions are where versioning matters, because those represent interpretive and editorial choices that you might want to revisit. The instructions you write for a stop are independent of the underlying data, so when you update a catalog record, the instructions you've already written still apply. No rework.
The expanding system
One thing Hendrik, my co-founder, keeps coming back to is that the system needs to expand in every direction without friction. New language? Available automatically. New exhibit? Add the data and it's part of the knowledge base. New tour theme? Configure it and the existing knowledge populates it. New staff member? Give them the right access level and they're productive immediately.
A good audio guide CMS differs from a good website CMS in this way. A website grows by adding pages. An audio guide system grows by adding dimensions: more languages, more tours, more stops, more personas, more staff, more visitor pathways. The architecture has to support that kind of multidimensional expansion without each new dimension requiring its own management overhead.
When the architecture is right, you stop thinking about content production entirely. You think about content curation: what should visitors know, how should they experience it, and who should they hear it from. The production happens automatically.
Getting this right
If you're evaluating audio guide platforms or thinking about how to manage your guide's content long-term, the questions worth asking aren't about features. They're about workflow.
Who at your institution will actually maintain this? What happens when that person is on leave? Can someone return to the tools after months away and immediately be productive? Does adding a temporary exhibition require the vendor's help, or can your team do it independently?
The answers tell you more than any feature comparison. An audio guide CMS that your team actually uses, one that fits how your institution works rather than demanding you work differently, is worth more than one with twice the features that sits untouched.
If you're thinking about this for your museum, we'd be glad to show you how it works in practice.