Sitecore’s Customer Experience Maturity Model has been around for a while and it is still as relevant today as it was when it was first released. The model helps a team to understand where they are right now and where they could possibly be with customer engagement.
However, it isn’t easy to keep improving. I’ve written a lot in the past about using baby steps to continuously improve your software delivery. The same is true for marketing efforts. As teams we often focus on big-bang improvements: a new redesign, content re-work, big integrations to our back-end systems to better leverage our digital assets. All of this is awesome work to get us started.
Unfortunately, it often stops there. We lose the momentum to keep iterating and improving on how we engage with our customers. We need to have a plan that will allow for small incremental changes to our content and marketing automation. This ensures that we can give customers a better experience and ultimately help them with their problems.
How do we increment?
- Analytics. First off, we need to be tracking data. Whatever your analytics platform, make sure you know what’s happening on your site. Also, if you are using Sitecore xDB, make sure you have your xDB tracking enabled. You’ll need that data in the xDB for later steps.
- Content Tagging. Learning about visits is great, but we need to know more about what type of content engage people. Start by adding a few tags so you can get a baseline to learn about user behaviour.
- A/B and Multivariate testing. Once we have learned a little about the types of content our visitors view, we can start focusing on which variations of content are working for our visitors. This testing will greatly inform further improvements we make to the site. Keep it small, just a few tests so you can manage it.
- Personalization. Add a few rules-based personalizations into your website based on what you are seeing from analytics and results of testing. Again, focus on some big win personalizations: a hero banner, or a call-to-action button. Sitecore can even suggest personalizations based on analysis of your tests.
- Engagement Levels and Campaigns. At this point, we should be learning enough about our customers to start determining their engagement and moving them through a campaign. Our personalizations should start becoming less rules-based and more about where they are in our engagement level. Leverage your calls-to-action!
- Omni-channel. Start reaching out to your customers in different ways. Add a mobile app. Tap into your onsite kiosk. Develop email campaigns. Build a game app to complement your messaging. Keep making iterative improvements to add more sources to feed information back to your central xDB data. How can we reach the customer in a new way?
- Machine learning. At a certain point in the continuous improvement cycle, the data is just getting too big to handle by hand. Automation is required to process the information and look for trends. Microsoft Cognitive Services is one way to start adding some intelligence to the mix! You can read more on machine learning Sitecore’s “The Mind in the Machine” series.
- Learn. At this point, we probably need to take a moment to learn about what worked well and what didn’t. Time to improve our tests and personalization with the new information we have!
Want to see the original Customer Experience Maturity Model information? Check out the full PDF doc here:
I had the chance to work the Sitecore booth at MSBuild in Seattle last week and took the opportunity to walk around and meet some of the other partners in the Hub. A lot of folks are doing cool things, but one that caught my eye was the work being done by the LaunchDarkly team.
Feature toggling without deployment? Yes please!
Continue reading Managing feature flags with LaunchDarkly
This year, Sitecore will be exhibiting at the Microsoft Build conference in Seattle. This will be my first time attending the conference and I look forward to getting the chance to meet so many of the developers in our industry!
I have been working with the team to put together some cool stuff for visitors to the booth, so if you happen to be swinging by the conference this year, come say hello at Booth 118!
I promise, I will not sing any Taylor Swift at you. Much. 😉
Today I embark upon a brand new journey in my career. Excitement. Trepidation. Giddiness? Perhaps! Part of me is sad to leave my Nonlinear family behind, but I am so very excited about the opportunity to join Sitecore as a Technical Evangelist starting today.
That’s right, no more MVP for me! As a wise man once said: “I’ll lose my Sitecore MVP status in the best way possible”. I hope to see many of you again soon, and I will continue helping out in the community as I always have. If you’re at an upcoming Sitecore event, find me and let’s talk!
To sum up my current emotions:
You probably read the title and said to yourself: “Epic: you keep using that word, but I don’t think it means what you thinks it means”.
It is true. The fixed-price agile backlog exists.
Now, if you are lucky enough to have never faced such a beast, then I bow to you and wish upon you continued good fortune. However, many of us have lived Agile in the Iron Triangle. Many of us have walked away as shattered and broken shadows of our former selves. We have lived, lost, learned, and ranted to whomever would listen.
This post is brought to you by an experiment in requirements cross-checking.
Continue reading Using Epics to drive a fixed-price backlog
On Wednesday evening I’ll be visiting Toronto to speak about all the buzz about Sitecore and Azure. You should come on out and say hello!
To get a taste of some of the things you might hear about, here are a few lead-up blogs that went out on the Nonlinear site:
When you start using Sitecore as an intranet you inevitably must face the identity management scenario: where are the users who are visiting the intranet going to be stored?
In most established organizations, a centralized identity management system is already in place. For a recent project, I came across the need to get Sitecore to act as a Shibboleth Service Provider and perform Single Sign-on (SSO) with a Shibboleth Identity Provider.
Shibboleth itself handles most of the heavy lifting, but there are some steps to force Sitecore to get out of Shibboleth’s way. Also, once you actually authenticate to Shibboleth you still need to authenticate to Sitecore with the header details you receive.
Enter the Shibboleth Login module, now available for download on my GitHub repository: https://github.com/jst-cyr/SitecoreShibbolethLogin
The module will get inject a pipeline handler to read the headers from Shibboleth and log in a virtual user for you with the information from the identity provider.
This has been tested against Sitecore 8.2 update 2, but I’m fairly certain that the API calls I made should work across other 8.x versions. Let me know if you find a problem getting it set up!