In other words, Sitecore has been steadily executing on the strategy they described in 2009. If there has been a change, it’s recognition that the company can’t build everything itself: hence the partnerships and app center, which use other developers’ products to extend Sitecore to other channels. Sitecore says this makes sense because giving customers a consistent experience across all channels requires only central data and central content management. Letting external systems deliver the actual interactions causes no particular harm.
This vision should sound familiar: it’s the idea behind the real time decision management systems I’ve been reviewing recently. The difference is architecture: the decision managers place decision logic at the center and see customer data and content as peripheral.
More specifically, the decision managers assemble a consolidated customer profile by pulling data on demand from external systems rather than storing it internally. This is actually a pretty minor difference, since in practice most companies will both maintain a central customer database with key profile information and make direct connections to other systems for details such as transactions. The Sitecore model is pretty much the same: it creates its own customer database and supports real time connections to other systems via Web services or database queries.
The approach to content is a more significant distinction. Most decision managers assume content is best stored with the touchpoint systems, while Sitecore wants to store most content itself. I chalk this up to their heritage as a content management vendor. Both approaches have their merits: central storage makes coordination easier but requires continued extension of system features to handle new formats; touchpoint storage makes it harder to know what content is actually available and appropriate. So far, Sitecore has been making the investments to manage new formats centrally, at least to the extent of making the contents visible to functions like message selection, access control, and approval workflows. It doesn’t necessarily extend to actually creating or modifying the contents themselves. Maybe that’s a good compromise.
The other important difference is decision rules. These are obviously the main focus of decision management products. Sitecore doesn’t talk about them much, although does deliver them in the form of campaigns flows and dynamic content rules. The campaigns can manage activities across multiple channels – such as sending an email response to a Web visit – although they are not as sophisticated as the multi-branch, looping logic, advanced decision arbitration, and integrated predictive modeling available in the best decision management systems.
On the other hand, Sitecore makes very powerful use of its close control over content. Each item can be assigned scores on several attributes, such as how much it relates to technology, product, or industry topics. The system then tracks the content consumed by each individual and compares their behavior to “profile cards” of personas such as frequent site visitors with high interest in business. Each person is assigned to the profile card they match most closely; people can be switched to a different card if their behaviors change. This nearest-fit approach is more flexible than the rigid inclusion criteria of traditional segments or lists. Cards are used in decision rules to select contents and treatments for each person.
One clear difference is that most marketing automation systems today are software-as-a-service products, while Sitecore is sold as licensed software, running either on-premise software or on the Microsoft Azure cloud. Pricing starts around $125,000 for an enterprise deployment. Smaller companies would pay less, but Sitecore will never be a system you can get for $1,000 per month.
0 comments:
Post a Comment