In episode 116 of The Content Strategy Experts podcast, Sarah O’Keefe and Patrick Bosek of Heretto talk about Content as a Service.

“Do we still have places where building a static site or a static set of help materials makes a lot of sense? Totally. But there’s a natural aspect of dynamic changing content. If that content is going to be a little bit different based on who or where or when you access it, then you can’t build it statically. That’s one of the things you’ll never get from a PDF.”

– Patrick Bosek

Related links:

• Content as a Service
  
• Heretto webiste
  
• Content Components podcast
  
• Heretto blog
  
• WinWithContent
  
• Coffee and Content talk show
  
• CMSWire
  

Twitter handles:

• @sarahokeefe
  
• @PatrickBosek
  

Transcript:

Sarah O’Keefe:                   Welcome to The Content Strategy Experts podcast brought to you by Scriptorium. Since 1997, Scriptorium has helped companies manage, structure, organize, and distribute content in an efficient way. In this episode, we talk about Content as a Service with special guests, Patrick Bosek of Heretto. This is part one of a two-part podcast. Hi, I’m Sarah O’Keefe. Patrick, welcome. We’re happy to have you here.

Patrick Bosek:                   I am happy to be here. Thank you, Sarah. I’m excited to chat with you on this very special podcast about content strategy. I love content strategy, you know that, and I also love Content as a Service, which is our topic. So, excited.

SO:                   Excellent. So tell us a bit, for the people that don’t know, tell us a bit about yourself and about Heretto.

PB:                   Yeah, sure. So I’m Patrick Bosek, as you mentioned. I’m CEO and one of the founders of Heretto. And what that means is that I get to kind of run around the digital universe and talk about how cool content is if you do it right. And then talk a lot about how to do it right in a bunch of different places. I do that with Coffee and Content and Win with Content and the Content Components podcast, if you see a theme. I like to get out and talk about content. I also write for CMSWire from time to time. I like to blog on our blog and all this comes down to talking about, mostly the technology aspect of how to get content operations set up in place, make it run effectively, and just get more efficiency, scalability, lower cost, and joy out of your content systems.

PB:                   And then in my more … in what I’m actually paid to do, which is to run Heretto a little bit, Heretto is a component content management system that runs on DITA and it is a content operations platform that you can use to scale up your content, manage the localization, collaborate with people who are a range of levels of technical. So you can have people who are non-technical, people who are in legal, all those kinds of things, all the way through to developers and technical authors, creating structured content in an online Software as a Service, Wiziwig environment. And then we can put that into deployments, which can go out into the cloud and power content experiences across whatever you want to hook it up to the API. And we do that using an API, which is a Content as a Service, which leads very nicely into what we want to talk about today. Yeah.

SO:                   And there we go. So for first of all, we will get links to hopefully everything you just mentioned into the show notes so that people can go find all these other podcasts and resources and the Heretto site, and your CMSWire link while we’re at it and all the rest of it. But yeah, so not too long ago, I was on one of the podcasts that Patrick mentioned and we got into an active discussion about a number of things. So I thought it might only be fair to return the favor and let you give your perspective on some of these things after our little knock down drag out. So I wanted to start with the basics, which is how do you define Content as a Service or CaaS?

PB:                   Yeah, that’s actually not that hard. When it comes right down to it, if you can access your content over a web available API and you can do it in a production way, so if I can set up an application or a website or some other user interface or really anything that’s going to be able to select content using a web call, that’s a content as a service. I’m able to make a request and it will serve me that content on the request. So it’s provided to me as a service. It’s Content as a Service application. It’s not that complicated.

SO:                   Okay. So when we think about Software as a Service, it was generally this idea that you would buy software and put it on your laptop, I guess, or your computer on your local drive and run it there versus Software as a Service was kind of like, you go to a website and you get stuff. So you’re saying that content, not as a service, the old version is essentially packaged stuff, right? Like here’s a PDF or here’s a book, or even here’s a website that I have pre-built.

PB:                   Totally. That is exactly the difference. Now there’s a bunch of, I mean, I don’t know how nerdy we want to get on this podcast. I mean, this isn’t Components after all, but there are places and there’s a time and place for both of these things. Content as a Service isn’t meant to be, even though it’s the next thing, it’s the new thing. It doesn’t remove the need for some of the packaged content, just like we have apps on our phone today. That’s the old model of software. You download them and you install them just like we used to do before. They’re not software as a service, the apps that are on our phone. So that model hasn’t gone away. Software as a Service has just become a really effective model for certain types of applications. The ones that spring to mind are obviously, social media is an application that tends to be really strong through Software as a Service when you’re on a web browser. And a lot of business applications.

PB:                   Salesforce famously is the first one to really embrace it in business applications. And Content as a Service is very much kind of the same thing but for content. So do we still need PDFs that we can download and print and take with us? Yeah, sure. I use PDFs every day. Do we still have places where building a static site or a static set of help materials makes a lot of sense? Totally. But there’s a natural aspect of dynamic changing content. If that content is going to be a little bit different based on who or where or when you access it, then you can’t build it statically. That’s one of the things you’ll never get up from a PDF. If you and I, based on who we are or where we are need to have a different piece of content in a paragraph, you can’t do that with a PDF efficiently or at scale. And that’s when you need Content as a Service. And that’s kind of the same thing with software or anything else that comes as a service in that way.

SO:                   So what do you see? I mean, you’re mentioning contextually aware or personalized kind of content. Where does this matter the most? What are the kinds of use cases that you’re seeing for Content as a Service where people need it and are using it appropriately?

PB:                   Yeah. So that question is so much fun because everybody wants to call it personalization and it is personalization. The problem is that when everyone thinks of personalization, they kind of go right to really dynamic stuff, which is Facebook or Amazon or stuff like that. Those types of experiences, which are really very individualized, personalized. When you’re thinking about Content as a Service, personalization, the purpose of it is to get us the things that we need, which is to say the information we want more quickly without having to wade through a bunch of other things. And those other things are going to be navigation or they’re going to be not having to read things. So when we think about where Content as a Service makes the most sense and where it’s having the biggest impact, it’s typically in business functions, where there is a necessity to either deliver less content to make it more easily digestible, more quickly digestible, get people to an answer or to a resolution faster, or content specifically that has an aspect of confidentiality or security or privilege.

PB:                   So if I have 10 different groups of people and what they can see changes. So the classic example is support distributor customer. Let’s say you sell tractors, I don’t know, and your distributors get certain version of the manual. You want them to be able to work on everything. Support gets a different version of the manual. You want them to be able to support people really effectively, but maybe they don’t need to know how to re-time the motor or engine. And then the end customer gets another version of the manual which is some Venn diagram of those three things. That’s a really classic example. Each of those personas, based on who they are and what their function of the product is, need to have secured effectively different access to a shared pool of content.

SO:                   Yeah. And I remember, I mean, a long time ago we had a … it wasn’t the most challenging thing, but we had a situation where a customer had support content where essentially the external facing support said, “Oh, the thing is broken, try this, this and this.” And then the last line in the knowledge-based article was more or less, if that doesn’t work, call corporate support. But the corporate support version of that same page said try the first three things that was identical. But then instead of saying call us, it said, “Okay, if a customer calls you with this problem, here are the weirdo things that you can do.” For which you need higher levels of access than the customer has or that we’re willing to give the customer. And I mean, that was doable with just a pretty simple switch, but you extend that as you said to more versions and more people and more variants, and all of a sudden it gets complicated.

SO:                   I also feel like there’s an element in here of security in the sense of if you get it right from an API point of view, there’s less likelihood that the content will leak out inadvertently.

PB:                   I think there’s an aspect of that, but I would warn people against thinking that they’re going to be able to prevent somebody from removing that content and creating a copy. I wouldn’t endorse that concept, but you can certainly make it more challenging and you can make it a thing that someone has to maybe have active male intentions or whatever you want to say. Something where they’re doing something that they know they shouldn’t and that is probably a really strong deterrent. But yeah, if it goes through the internet, people can hang onto it, for sure.

SO:                   If it’s digital, it’s … yeah.

SO:                   I think that’s a good stopping point, but we will continue this discussion in the next podcast episode. Patrick, thank you.

SO:                   And thank you for listening to the Content Strategy Experts podcast brought to you by Scriptorium. For more information, visit scriptorium.com or check the show notes for relevant links.

The post Content as a Service (podcast, part 1) appeared first on Scriptorium.