AI in CS Series, Interview #005. With Sarah O'Keefe, CEO and founder of Scriptorium. Founded the company in 1997. Author of Content Transformation and other books on enterprise content strategy. Speaker at ConVEx and DITA conferences worldwide. Host of the Scriptorium podcast. Bilingual EN and DE.
Sarah O'Keefe started Scriptorium in 1997, before "content strategy" was a job title. The 28-year arc of her career has been the arc of digital publishing itself: templates, then formatting automation, then structured authoring, then DITA, and now AI. She thinks about content at three intersections: content, publishing, and technology. Below, why structured authoring is terrible for authors and wonderful for everyone else, why the localization decision is not actually about documents, the real difference between back-end AI and front-end AI in the content workflow, and the reason chatbots are doing what publishers have chased for 30 years: infinite personalization.
Q1. The 28-Year Arc
Q: You founded Scriptorium in 1997. The arc of your company has also been the arc of digital publishing. Take us through it briefly.
A: Content strategy was not a thing in 1997. What I was interested in was how you do document production at scale with a reasonable amount of automation. At the time it was template-based at best. Create a template, follow the template. Most of our output was very long books. 300, 400, 500 pages, 800, 1200 pages. Monster tables of contents, monster indexes.
The arc of the company has been the arc of digital publishing. The World Wide Web came along in 1992 or 1993. Took off. Dot-com era, dot-com boom, dot-com bust. Financial crisis in 2008. Somewhere in there we have had structured content and we moved largely toward formatting automation. The logical evolution of templates.
The big problem with templates is that you have to convince people to follow them. There are forms of convincing up to and including "do this or else." But mostly it is soft power. You have to encourage people to follow the template, review their work, clean up the special exceptions they made. Along comes structured authoring. As an author I think structured authoring is terrible. You are told you will follow the template. If you do not follow, you get invalid content and it will not let you save or publish anything. Horrendous as an author. From the production side, fantastic. Because it lets us enforce the templates. Reduced variability, increased consistency. Both lead to better automation.
Now we fast forward to 2023, 2024, and we are asking: what does it look like to have AI, chatbots, and AI tools inside our content workflows? The thing I have always been interested in is the intersection of content, publishing, and technology. We sit inside those three and try to figure out how best to use them to deliver information.
Q2. Back-End AI vs Front-End AI
Q: You separate AI into back-end and front-end. Why does that distinction matter?
A: AI is a very broad category and you can do a lot of different things with it. So I separate roughly into back-end and front-end.
Back-end AI is the content producers, the author or the organization or both, using AI for productivity. Conceptually similar to building a template or using a spell checker. Just a back-end tool. You can do nifty things at a basic level. Grammar checker. Translation between languages. More interesting things: convert a podcast into a transcript, translate the transcript, make the podcast into a synthetic-voice version in French, German, Italian. You can do summarization and synthesis. A lot of that is incremental improvement over what we already know how to do. The interesting question is: when do I need AI and when do I need traditional deterministic scripting?
Front-end AI is you and me as a content consumer. I have a question, I need information, where do I go? It used to be search. Before that, you went to a printed book and used information access points: table of contents, index, bibliography. Now AI chatbots are basically information access points. The big difference: when you ask a chatbot a question, it assembles an answer. It builds it out of the database that has been assembled from the documents. You are not querying directly onto the documents. An intermediary has been injected into the process of asking for information.
Q3. The Localization Decision Is Not About Documents
Q: Many SaaS founders ask whether to localize their documentation. How do you think about it?
A: Machine translation generally does a really good job, right up until the point where it does not. Fantastic until it fails.
The first question is the risk. If I run across an article in Norwegian, which I do not speak, I machine-translate it and I read it. Fun story about the whale. Fine. But say a company in Estonia sends me a contract written in Estonian. I do not speak Estonian. Would you rely on the machine translation of that contract and sign it? No. The risk is the gate.
For a SaaS product, the calculation is the addressable market. How big is the market in this language? If you do not localize and you sell into a country, what percentage of potential customers are unwilling or unable to use your product with supporting content in the wrong language? Germany specifically: the percentage of people in Germany capable in English is quite high. The percentage who refuse to buy a product if it is not available with German support and content is also quite high. There is a culture of "you need to give this to us in our language or I will not buy it." That varies by country.
And localization is not document-centric. If I take a product built in the United States that has money in it, it has dollars. Canada has a different dollar. Germany has Euros. Even if you do not translate the interface, you have localization issues. Currency, dates, federal holidays, labor laws. All of those differ. The localization process goes far beyond "is this language A or B." It has to address cultural, legal, and regulatory issues across the markets you serve.
Q4. Why Machine Translation Has Better Pairs Than Others
Q: You said the workflow has translation memory for a reason. Walk through what that means in 2026.
A: Translation memory has been around since the 1990s. If you have a language pair, English-German for instance, the first time you translate, every sentence (every segment really) is stored as a language pair. The English original and the target German. Same sentence appears later, it auto-translates because it is a perfect match. Pre machine translation, just with translation memory, in technical documentation you can typically get up to 50 percent leverage on a new project. You are not translating everything again. Only the new stuff.
Then there has been statistical machine translation. Neural translation. Now AI. All on a continuum. Machine translation for technical documentation is actually pretty good, depending on the language pair. English-German has lots and lots of data. If you go Polish to Korean, not so many people have done that directly. Your dataset is much smaller. In a non-AI workflow you would pivot through English: Polish to English, English to Korean. Two language pairs, all the problems introduced there. When you look at AI and machine translation, it has the same problem under the covers. The quality you get depends on the language pair and how much training data exists for it.
Q5. Garbage In, Garbage Stays
Q: Companies are pouring content into chatbots and expecting good answers. What is going wrong?
A: The chatbot uses data sitting inside an LLM. The database is fed by the content ingested into it. AI thrives on patterns, consistency, conformity, and consistent terminology. When you do not have those, AI infers meaning from the lack of a pattern. Content goes into the AI database, and the AI database is basically mathematical relationships among things. When the pattern is consistent, the math works. When the pattern is not consistent, the math is different. So if your content goes in inconsistent, what comes out is inconsistent.
The implication: pay attention to what you are feeding into the database so the chatbot can deliver what the end user is asking for. You do not necessarily need structured content in the XML sense. Content in general, whether on a page or a napkin, has implicit structure. Headings, indents, cues that convey meaning. The question is: how do you ensure the chatbot translates your structure into the proper thing, into the math that delivers the correct answer?
The only way I have found to get authors to consistently follow the structure and rules is to put them in a structured content environment. If you do not, they do not follow. And I include myself in "they."
Q6. The Chatbot as Information Access Point
Q: Will chatbots become the dominant interface for documentation? Or do longform docs still matter?
A: Both and. If I want a quick question, I go to the chatbot. I read the answer. I say "okay great" or "I do not understand this, make it simpler" or "make it shorter, give me steps." Or I say "this is interesting, let me read the actual source." So I ask for a citation and read the source document because the answer was too superficial.
AI chatbots are clearly a delivery channel. Consumers will use them. The really interesting question for content creators is: how do we make sure the information that comes through the chatbot is accurate at the right level? That answer is different for public-facing chatbots than for private ones. If you are on my website and I have a chatbot built for my content, I have a lot more control. Over the public chatbots, less.
The most interesting thing about the chatbot channel, other than the accuracy concerns, is what it gives the consumer: infinite personalization of the requested content. We have been trying to solve personalization in publishing for 30 years and we never had the ability to personalize at scale. We came up with eight personas and personalized for eight categories. With a chatbot, the consumer says "I like poetry, give it to me in rhyme" and it will. That is very satisfying as a consumer. Powerful.
Q7. The Three Levels of Investment
Q: A SaaS company looking at where to invest first in AI for content. What is the order?
A: Start by understanding what you are doing today. Most companies skip that step. They want to bolt AI on top of an existing process that already has problems.
Step one: are your content production patterns consistent? If not, AI will amplify the inconsistency. Step two: is your structure explicit or implicit, and does that match what AI needs? Step three: what is the experience you want to give the consumer? Then choose AI tooling that supports that experience.
The companies getting this right understand that AI is a force multiplier on whatever you feed it. Quality in, quality out. Inconsistency in, inconsistency out, but at scale. The fundamentals of structured content production became more important the moment AI got real, not less.
Henrik's Outro
The line that stuck: AI is fantastic at translation, right up until the point where it is not. The risk gates the localization decision, not the language. The "three levels" framing on infinite personalization is the second piece I am taking. We have tried to do that with persona-based segmentation for 30 years. The chatbot solved it incidentally. The implication for support and documentation teams: the bar is no longer "is the content correct." The bar is "does the AI ingesting this content produce the right answer at the right level." That is a different design problem. If you lead content or support in 2026, our State of Self-Service in SaaS 2026 survey wants your view.
Connect with Sarah: scriptorium.com | LinkedIn | Content Transformation | the Scriptorium podcast
