FXM
Introduction, New releases

Extending the Reach of your Sitecore Platform using the Federated Experience Manager.

The Customer Experience Management system landscape is incredible fragmented, covering amongst others content management, online customer service, e-commerce, campaign management, analytics and tracking, personalization, automation, social media, ad management, retargeting and many more, and most organisation have multiple systems in place – not only to handle different parts of the process, but often identical systems – like multiple CMS’s – to cover the same processes.

This scenario is not likely to change in the near future.

One of the newest features of the Sitecore Platform is the Federated Experience Manager, which can help connect a fragmented digital platform and make it possible to track and reach out to all visitors across all the owned channels in an organization.

Disconnected Platforms

Before joining Sitecore in 2014, I worked the last 14 years in a company called Pentia, based in Copenhagen, Denmark and since Pentia was the company from which Sitecore originally sprung in 2001, we were almost exclusively building Sitecore solutions for Danish and international customers.

Through the years, most of the clients I worked on aquired Sitecore as a major technological investment and as a new platform for driving their marketing efforts. So building or rebuilding their brand website, customer service website or e-commerce solution – and configuring the marketing tools – was almost always a major project for them.

When this is said, almost without exception, all would be stuck with one or more legacy websites or CMS systems following the migration or implementation project. This was not because the marketing division necessarily wanted it, but typically because the technical migration of their entire web platform would be too costly – or simply because Sitecore did not feel like the a good fit for a remaining systems.

So even though a lot of hours and smart people worked on implementing Sitecore and making the marketing platform better and giving the customers a better experience, it would often feel like we were working on a part that mattered very little.

Disconnected Experiences

We often saw that the legacy websites which were not converted to Sitecore was the e-commerce platforms, the direct customer service websites or the transaction websites. In other words, the websites actually giving the most value to the visitors – and often the organisation – and where the customer experience and visitor journey tracking was most vital to the success of the whole online platform, was being kept on legacy systems and technologies that were not allowing Sitecore to help marketing and customer service.

So the result was often a bad and very disconnected customer experience.

Seemingly simple things, like the visual design changing slightly from website to website, the overall flow or information architecture being bad or simply the content being wrong, not updated or just not assisting the customer towards the goal and the conversion. Furthermore the tracking and profiling capabilities of Sitecore was severely crippled, making the investment in personalization and optimization at best poor but often simply not worthwhile.

One platform, One Experience

Personally this was why I was rather excited when I first heard about the Federated Experience Manager a while ago.

By allowing Sitecore to reach out to non-Sitecore websites and applications and track visitor behaviour across these, we can start to see the entire visitor journey on the owned platforms and profile the users accordingly. But more importantly, we can start incorporating the legacy websites into the optimization effort, assisting the visitors on making those vital transactions, or start marketing our products or services on the websites where the visitor actually is, and not just where we would like them to be.

This will allow the marketing people to get even more control over all the digital channels – and ultimately make the investment in Sitecore and their new marketing platform much more valuable.

The Sitecore Federated Experience Manager

Sitecore Federated Experience Manager, FXM, will in short allow you to track the individual visitors across Sitecore and non-Sitecore websites using javascript tags – just like you know it from other analytics tools. This will allow you to use the standard Sitecore tools for goal tracking and visitor profiling. This mechanism is pretty much independent of technology, and FXM can even be used to track non-websites such as mobile apps.

But FXM will also allow you to push content from Sitecore to non-Sitecore websites and applications. This of course means that content can be maintained in one location within Sitecore and pushed across to other platforms. But potentially this can also be used to push theming and visual elements, to assure a unified user experience across all systems.

And since all content is managed and shared though the standard Sitecore mechanisms, we can leverage all Sitecores tools including personalization and A/B testing.

Finally FXM can be used to push data back to Sitecore too. This means that events and data from the external system can be sent across to Sitecore, and by leveraging Sitecores rules engine, we can trigger marketing events in Sitecore, for example engagement automation.

FXM is available for Sitecore 7.1 and forward on SDN.

Standard
Introduction, Sitecore

Getting your Sitecore project right

This post is for you clients who have already selected Sitecore as your new website platform and is starting up a new Sitecore project.
Here are a couple of my thoughts on how you can get your Sitecore project on the right track from the beginning, by setting the stage for a good collaboration with your implementation partner.

The website you a building today should also be the website for tomorrow and hence the website you are building should be extendable, flexible and scalable. It is absolutely possible to build a Sitecore web platform which will last many iterations – considering that you take this into account early in the process.

Select your implementation partner carefully

Your implementation partner is the single most important collaboration partner in your project. They bind everything together; requirement specifications, user experience design, hardware, software, domain knowledge and more, and is therefore crucial for the project’s success. Therefore your primary focus initially in your project should without doubt be to find the right implementation partner.

In my opinion, what you should focus on is:

Human chemistry: A website is not primarily a technological project, but a communication project. Therefore select a partner with whom you can communicate openly and freely. If you sense that they are listening, factors as for example domain knowledge is less important.

Experience: Sitecore is not a difficult tool to learn – but is takes time to master. Therefore, try to find a partner which has multiple large scale projects under its belt, and preferably with projects which has undergone a number of iterations.

Technology based: In my experience, companies which are technology based, i.e. which focuses primarily on the integration and platform parts of the solutions compared to the user experience driven companies, e.g. design agencies, makes more future proof Sitecore solutions. Therefore if you are looking for someone to build your future webplatform as opposed to just your next website, opt for a company with vast knowledge of Microsoft .NET and surrounding technologies.

References: Most implementation partners can most likely show an impressing list of references – but please do not stop there. Call their references and enquire about support, quality etc. Hearing whether their existing customers have gotten value for money is very useful.

Don’t be too specific in your requirement specifications

My suggestion is that you use your implementation partner as a sparring partner on requirements. Remember that these guys have built other solutions before yours and might bring experience, skills and functionality which will benefit you. Also, allowing multiple implementation partners to suggest different solutions to your website’s objective – as opposed to a RFP checklist – will allow you to better evaluate their creativity.

Therefore, in the specifications, try to explain the objectives you have for your company, users or editors, instead of the precise functionality. In Pentia we have had multiple requests for debate forum functionality in solutions – which in our experience is a prime example of a specific functionality which is often never used by users. By explaining which objective the clients wanted to achieve on the website, instead of the specific functionality, we could have advised better, earlier in the process and given more value to the client. By the way; in most cases we managed to dissuade the clients to actually implement the debate forum, and used the precious development time for something much more valuable.

In short: Requirements change. Therefore, being too specific and detailed about functionality already in the RFP process will most likely get you a whole lot of expensive, unused functionality.

Be open about your development budget

This is in my book a no-brainer. The only reasons for not being open about the budget are if you adopt the “they-are-all-thieves-and-robbers” attitude or if you hope to haggle your way to a cheaper website. In both cases, you are doing yourself and your website a whole lot of damage.

First of all, you have to trust your implementation partner, as they hold an immense power to make your project a success or failure. If you don’t, find another partner. Secondly, this is not a standard product you are buying. If you push your implementation partner on time or money, they have but one place to push back: quality. This basically means that your solution will be in a worse state, bringing lower reliability or higher support cost.

Therefore, a selection process is not about getting the lowest price or best solution description. It’s all about finding the implementation partner which you trust the most. And if you found that implementation partner, why not be open about mostly everything, including budget?

Bring your partners on board early

There is a lot of benefit in bringing in all your partners as early in the process as possible – this means both strategy and design partners and well as implementation and hosting partners. Each domain has something to bring to the process and can potentially save you a lot of money and hassle. Getting the implementation partner and hosting partner to talk together as early as possible can save a lot of time in the deployment process, and in my experience, by getting the implementation partner involved in the strategy and graphical design process a lot of hours can be saved in communication afterwards. Furthermore implementation partners often have prebuilt functionality which – if it fits the project – can save you a lot of time and money. The earlier this is brought forward, the easier it is to fit into any graphical design or information architecture.

 

Standard
Introduction, Sitecore

Welcome to Molten Core!

Writers on this blog are Thomas Eldblom and Jens Mikkelsen. We are both part of Pentias new department/team called the Core team.

To share our knowledge and biased opinions on Sitecore, we have created this blog. Hope you enjoy!

Standard