Part 6: Embrace Change

If you’ve ever been involved in the creation of any customer communication touchpoints, you know that the only constant is change, and that’s usually right until the touchpoint gets sent out!  It makes sense too, considering it’s critical to get the messaging right when communicating with customers. Miscommunication and confusion cost, frustrate, and alienate, and no one wants that.  The other aspect is that to stay customer-centric and compliant, the messaging we use in touchpoint communications needs to change constantly to adapt to market conditions, regulatory requirements, and customer needs. So, when I heard today about a large customer who needed 3 to 4 months to push through changes to a single letter touchpoint, I thought: Houston, we have a problem.

So, why is that? Recalling from the last installment: in the 1.0 world of touchpoint communications, content and rules are essentially wrapped up in code.  Meaning that a composition engineer needs to take even the simplest of typo corrections, enter them into their build environment, and “recompile” or re-bundle to make the changes.  And since the entire bundle has changed, everything needs to be re-tested, not just the corrected typo.  All of this takes time, scheduling and resources – most of which are not available on-demand, all-the-time, and can translate into long delays (a la 3-4 months!).

Being a software guy,  it reminds me of the days when hard-coded strings were de rigor in software development.  This is where the text found in the user interface (text strings), like help text,  labels, or descriptions,  were stored directly or hard-coded into the software itself.   Which in turn meant that those annoying typos or meaningless geeky descriptions were written by developers to confuse mortal users could only be changed as part of a development cycle. And because any change to code could introduce instability or risk, making simple changes to improve the user experience, especially in the final throes of delivery, became a difficult task that typically got deferred to the future.  The solution, of course, was to abstract content from code and make it more accessible to more folks who could change it, without requiring an engineering degree or a recompilation of the software.  Incidentally, this also made translating the user interface to appeal to broader markets possible (more on managing touchpoint translations in a future post).  The content of the user interface was now referenced, and the references were verified and certified, not the text and language itself.

Which brings us to Touchpoint Messaging 2.0, a world where content and rules are now managed and controlled by the content creator through the messaging lifecycle, separately from IT and the composition platform – outside of code, but safely referenced by the code. This also means that any required changes can be implemented, verified, and approved by user stakeholders, without ever tying up valuable IT development resources.  So, how long does it take to change content now in a Touchpoint Messaging 2.0 world? Maybe 3-4 minutes, along with an on-demand proof?  Of course, with change-friendliness comes the need to ensure that approved production content cannot be changed by any individual at any time.  So a 2.0 touchpoint messaging platform also needs to provide controls that let users continue to make changes for future delivery that doesn’t impact todays.

It’s worth adding that it’s not just content authors and stakeholders who will benefit from Touchpoint Messaging 2.0.   IT will also no longer be viewed as a bottleneck or a scapegoat for a lack of agility and flexibility in responding to rapid, last-minute changes brought on by agile marketing folks or fickle regulators.

This blog is the sixth 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.