The Problem with PowerPoint and InDesign-based Content Automation (The “Save As” Phenomenon)
Recently, I wrote an article about why automating within desktop publishing environments can be a bad idea. When I talk about desktop publishing environments, I’m referring to programs like InDesign, PowerPoint, or Quark for content automation. If you’re looking for a way to effectively scale your literature production, you simply must say goodbye to your desktop defaults. And, I’ll tell you why.
This topic is front-of-mind for me today, following a meeting with a prospective client last week. This client described their frustration with their current automation solution. They told me a story about how their automation provider is currently supporting their suite of about 50 documents using about 50 InDesign templates. Even the client recognizes that this is a problem and knows that if the templates were being shared properly as shared entities then there should be, at most, eight of them for this catalog of documents. Fewer templates allow changes to be made centrally, without needing to apply a change 50 different times.
I smiled in sympathy as they told me about this problem. This is precisely the issue with automation solutions that are based on desktop publishing applications. This client articulated the issue even more simply and perfectly than I have in my past musings on the topic.
If a Microsoft or Adobe desktop publishing application is being used as the foundation of the automation solution, that system is then dependent on that desktop publishing tool, as well as the people who use the tool. It’s easy to overlook or dismiss this reality. People really love these programs, and understandably so. They are familiar, intuitive and your collateral is probably already designed in one of these formats. But, the hard truth is that almost always leads to bad long-term results in a commercial document production environment. This is due to what we call the “Save As Phenomenon”.
Here’s how the “Save As Phenomenon” occurs…
Here’s what happens: You have a nice template setup for automation and an integrated tool that pours content and data into that template, and it works great. Especially on day one. Everything will work nicely on day one. But on day two something happens. A new product is launched, a new variation on the template is needed, or a visual challenge crops up in a template based on new content being introduced. So, the person managing the template is very likely going to take the existing template and do a “Save As”, thus creating a new variation.
This process seems great at the time; “Hey look, I solved the problem quickly and didn’t have to call the automation vendor or IT group!” But without probably realizing it, you’ve made a big mistake.
The mistake is that you’ve put yourself on the road to non-automation
In a past life, I worked on a pair of Prospectus publishing systems that resulted in content being pushed into either MS Word or FrameMaker. And when I co-founded Synthesis, we originally used Quark eXpress and DL Formatter (a tool based on Adobe FrameMaker) to automate our final output. At the time, our clients’ design teams liked this because it left them with a file in a format they understood, and they could make changes manually if something came up. In both cases, the system and tool worked great and the client happily signed the system acceptance paperwork. From that day forward, steadily and incrementally, the “system” slowly devolved into something inefficient. And eventually, it became chaotic, requiring us to replace the tool at a significant expense. For desktop-based automation systems, there’s usually a 3-year lifespan before the replacement of the system starts to become a critical concern.
Here’s another story. Back in 2000, one of our clients had a group of desktop designers who worked with our Quark output model and did quite a good job of managing the automated templates. But about once a year, we had to come back in and help them consolidate all their manual tweaks and adjustments so that the system did its job well and the integrity of the system was maintained. We realized that this was a bad pattern and moved from publishing within desktop tools to our own proprietary automation system in 2002.
The downside of this move was that our clients felt, at least initially, that they would be too reliant on our client services team. The upside, however, is that with our automation experts involved on an ongoing basis, the templates and automation efficiency don’t decline over time. Our current average initial implementation lasts about 10-years before needing any real overhaul to get it refactored to a “best practice” operational model. And, it turns out that our clients really appreciate the hands-on support and expertise we provide in this extremely specialized field.
The other hidden benefit is that the real ROI of the system gets better with the use of outside professional services teams. With desktop publishing-based “do it yourself” (DIY) solutions, there are a lot of hassles, overhead, staff turnover, and other hidden costs that are magnified under this model. In addition, you’ll likely see diminishing returns from the technology. I recently wrote a guide on how to calculate ROI on your content automation solution that discusses this at length.
PowerPoint-based content automation solutions — Be leery of hidden costs
A big trend we’re seeing is the adoption of PowerPoint-based content automation solutions. This makes sense, as marketing and sales teams feel comfortable working within PowerPoint already. Marketers feel empowered to be the hero with the Powerpoint-based technology as their sword. The problem is that mastering the automation system takes time. Desktop-based DIY automation providers usually offer ample training and user conferences to help you become proficient with the system. But, do you really want to take on the responsibility to become master users of this technology? Is this in your core competency? And, do you and your team have the bandwidth to do so? If your team is already strapped for resources, the appeal doesn’t last long once you’ve evaluated what it’s going to take to roll it out and maintain it. The costs are often hidden or overlooked because they’re buried in staff salaries across multiple departments.
We’ve researched the results of the DIY model fairly extensively and have learned that asset managers who are invested in the DIY automation model are committed to a very long path to success. That’s because the implementation is taking two or three times longer than expected due to the learning curve and staff bandwidth issues. Implementation processes like integrating data are usually at the crux of these issues, and there are compliance concerns due to the lack of sophistication in data handling. The companies that provide this automation software are also not in the business of supporting the implementation to its conclusion; it’s not in their business model to provide this kind of personalized service and support. As a result, asset management firms are seeing their internal costs soar, and it’s especially disruptive when there is staff turnover.
In sum, desktop-based DIY automation models simply can’t be as efficient or cost-effective as a technology-enabled service. You can’t eliminate the “Save As” problem and the efficiency-drift it encourages if you’re using InDesign or PowerPoint. You’re also signing up for a long and internally-funded implementation process that could be quite frustrating.
If you’d like some help evaluating the full enterprise costs of the content automation solutions you’re considering, drop us a note or contact us through our website. We’re happy to discuss your situation and offer some insight based on our 20+ years of experience in this business.
Follow John Toepfer on LinkedInHere are some related resources that might interest you:
From the Blog:Why Salespeople Fight Presentation Automation
From the Blog:8 Pitchbook Pain Points for Marketers
From the Blog:Noel Rodolfo Will Leverage a 15-year Tenure with Synthesis to Support Clients in a New Role