Part 5: See Your Messaging in Action

This blog is the fifth part of an ongoing series called “Introducing Customer Touchpoint Messaging 2.0” explaining how Touchpoint Messaging 2.0 simplifies the planning and execution of customer messaging programs.

We live in a world where instant gratification is the norm.  Especially when we create something, we want to constantly and instantly validate that we’re on the right track.  Strangely enough, in the print services world, which is all about creating and disseminating content to our consumers, this little pleasure is left to the end of the creation process (delayed gratification, anyone?). When so much is at stake, timelines are so tight, and making changes is not as easy as it could or should be, this strikes me as odd.

Historically, IT Operations has been in charge of controlling when and how messages and targeting are “coded” into the composition tool for any given touchpoint. To provide a bit more context: remember that old spreadsheet process of message management? Print “developers” are essentially taking what’s in that spreadsheet, and writing custom “coding” for it in composition. That’s just how messaging and targeting works in a lot of places today.

In that respect, messaging development looks eerily similar to software development, where detailed requirements are defined upfront by individuals like me, then passed on to developers to code and compile, then passed back to testers and yours truly for verification and “acceptance”.  It’s not surprising under this paradigm that reviewing and proofing touchpoint content happens at the end of the cycle. However, even in the software world, the clear trend is towards a more iterative, agile process, where validation and acceptance are done not at the end, but constantly, and instantly, throughout the process, which drives great predictability overall.

Where the similarity breaks down is that messaging development shouldn’t be a software development exercise to begin with.  For print, we’re talking about content development that involves well-known, structured entities (combinations of text, images, and rules); and in software, we’re talking about complex functions, algorithms, and innovations that have never seen the light of day before!   In other words, if it’s largely (not entirely!) about entering content and rules, users should be able to do that part themselves, electronically, and we should dis-intermediate the middleman (the developer) for a large part of the message management effort (again, not entirely!).

Touchpoint Messaging 2.0 changes the message management paradigm. Weaving our software story back into print composition for a moment: The beauty of software is that it can take repetitive or complex tasks and simplify them into packaged bite-sized chunks for end-users to consume. In our print example, this means that users can control messaging content from cradle to archive through software and a desktop, and reserve expensive print testing to when it is needed most. It also means that routines that allow end-users to request and receive validation (constant, instant gratification) through on-demand content previews and touchpoint proofs are also possible.

In a sea of customized communications chock-full of targeted messages and underlying rules, nothing beats a real-time view of what your touchpoints will look like come production time.  So your Touchpoint Messaging 2.0 platform should let business users easily request and run tests, simulations, and proofs themselves, without ever submitting a work order. This will ensure that your delivery deadlines can be met with confidence, and last-minute changes are kept to a minimum.