Date: 16th April 2012
We’ve seen a steady stream of projects over the last six months, where eCommerce teams have moved sufficiently down the e-Commerce Maturity Curve and wanted to upgrade their current, rather static website monitoring tools. Very often this move has been made in order to both gain more realistic metrics of genuine user experience, and to provide greater reporting intelligence as to the root cause of each problem. Both of these are vital for organisations looking to reduce low level trouble-shooting and firefighting time for the Opps and Support teams, allowing them instead to focus on meaningful analysis of performance and development .
When teams have been used to the methodology, alert formats and reports of another website monitoring supplier it is important to help make the transition as simple as possible for the hands on Opps teams.
Of course it helps if you have the kind of focussed client liaison support all of our customers enjoy, but here are 4 top benefits gained from a managed transition collected from a number of clients that have moved to our platform quickly and easily.
Extra Realism opens the way to an easier dialogue between Opps and non-Opps teams
Dynamic journeys provide a measurement more realistic to different users choosing different routes and products – and that realism allows easier meetings between technical and business teams. With artificial or static monitoring, Operations teams are often not able to be certain of the extent to which customers were impact, and by what percent, by a specific technical issue.
With newer dynamic journeys, meetings can be more focused, Opps can be more confident that a green bar means that Journey really was working, even if the call centre had extra callers compared to normal.
Or conversely, if a problem affecting real users is picked up and confirmed by the monitoring more information can be provide to the customer facing or eCommerce teams more quickly and the fact that sampling speeds up to 30 seconds on an error gives better precision as to when the problem was resolved.
Less often will the support or operations team be asked in a meeting to go away and drill down to find more information -that’s a time saver.
Take the chance to rethink alerting, don’t just copy it.
There are a range of fine-grained alerting choices in the scivisum portal that allow the total number of alerts send out to be reduced per person to ensure everyone gets relevant communications. This can range from the simple end of sending alerts due to DNS problems only to the guys that can fix DNS through to the option of dialling in specific URL patterns that relate to specific known bugs you have and sending those to the one software developer who knows how to fix them there and then!
In addition, Alert emails themselves contain more intelligence, to save time trouble-shooting such as stating which product had the specific problem. With a click you are taken to the detail-rich Single Sample view for the error that saves trouble shooting time by calling necessary technical detail right into the page. This includes which server in your farm was involved (by serverID), average TTBF per host during the journey, specifics of the errors that occurred and one click to Reply to see the raw HTML, or the actual served page that the user saw.
Make the most of this right away and configure what you need, not just what you had. If you do that you will get the results you got before, and they must not have been what you needed or you wouldn’t have changed supplier!
Put your Wallboard view on a Plasma screen and immediately show when website problems are due to 3rd-parties
It’s worth getting a large screen on the wall to display the SciVisum wallboard. This will give visibility to the whole team as to which Journeys you are now monitoring and their status.
Added intelligence, such as visible flags that state when a problem root cause is not your own systems, nicely reduce the occassions when the technical team get blamed for things outside their control! If the root cause is actually down to a 3rd-party supplier, (such as an Image Content 3rd-party or search supplier) the ‘3’ icon shows it, with no live intervention needed from the Opps team.
Don’t be scared to re-spec your Journeys
A common theme from those who moved to us in the last 6 months, is the speed in which we make Journey changes as requested.
Firstly, our own team are watching your journeys anyway, and if you change your site so much that a journey rewrite is needed, will do that proactively and let you know, typically 2 working hours later.
Of course the dynamic Journey approach, means that our Journeys don’t need updating as often as static ones. If the monitor is statically hard-coded to hit an exact URL for an exact configuration of the same specific product, then it will of course fail when that product drops out of stock, or when your site changes slightly and that old URL is no longer valid. The dynamic approach looks into the live site, to find the list of products offered, and chooses from those actually available so never tries to buy a product that is no longer even visible on your site!
But feel free to go beyond that and experiment. If say a particular problem is being addressed by your development team, then change your journey spec to ensure that feature is included and we’ll be able to pick up the errors that it produces, and give you proof, when no more errors like that occur, that the software fix has been a complete success.
So a change in website monitoring suppliers, with a new, better common language of user experience can be a key component in helping an organisation move together higher up the eCommerce maturity curve.
Get in touch if you’d like to discuss how we can help manage change, provide support and training and provide trials of our product to run concurrently with those from your current supplier.