Multi-Channel Commerce & Retailing

It is with great relish that I join the list of talented bloggers who have preceded me and offer my humble contribution to the ongoing debate around multi-channel commerce (MCC). One of the first things which always strikes me when I am participating in debates around MCC or even customer discussions is while the focus is reassuringly on what MCC can accomplish and provide, inevitably the debate quickly becomes a one-sided focus on web capabilities. In a way this is understandable as the web has been the ‘ultimate solution’ to whatever problem or aspiration a company may have. Often times this is correct and the web truly does possess the power to revolutionize a business.

However, to put the focus solely on the web at the expense of all other channels – often the missing parts of MCC plans – is to run the risk of creating a new environment which suits the business but forgets one thing, who are the users and what is it they want to achieve? If the end customer normally transacts via telephone or is a user of SMS then important avenues are being dismissed which could in their own way offer a rounded and capable solution. So certainly focus on the attributes and capabilities of the web channel, the look and feel of the application you plan to launch but please, please, bear in mind the impacts on other established channels already in use by your customers, and consider carefully the implications of the new channel capabilities you are launching.

For example, often the very predictions of customers ‘switching’ channels without proper communication and incentives fall woefully short of their promise. If no equivalent planning has been made on how to align the two channels, then what inspired thinking will bridge the gap between expectation and reality? In such cases even the fundamentals can be ignored. How will a customer be handled if, in receiving a lack of sufficient clarity during a transaction, they revert back to the voice channel? How will their online history be presented to the agents in the call centre when they do call in? Will those same agents answering the call have any ability to impact on the process? And if not, could that status check be handled better by an automated announcement or better still a proactive contact via outbound dial or SMS? As a rule of thumb it is always better to provide the information a customer seeks proactively then to suffer the higher cost of an inbound voice contact and resulting customer frustration.

These are the issues which must be addressed to get the balance right, and prevent any new MCC initiative falling at the first hurdle. In this way new designs and applications can be more readily integrated into the existing channel hierarchy and prevent the feature rich deployment which, despite showing promise in its inception, proves a costly failure for an organisation who forgot it was the customer themselves they were building it for.

Over the coming months I hope to be able to offer some battle scars and insights and add to the fascinating content already on this blog.

Posted by Billy Byatt at 08:34 AM | Permalink | Comments (0) | TrackBacks (0)

A few weeks ago, I was talking to a friend of mine who is employed with one of the leading web portals in the world. Besides discussing other things, our chat ventured into the realm of customers, how to work with them better and what has changed in requirement extraction in the recent days, etc. One thing lead to another and not long into the conversation, my friend threw in an interesting statement – “Its relatively easier for us, we have got just one customer – our own company”. There was something odd about this statement that was making it hard to digest but I could not pin point it for a few minutes. When my thoughts caught up with me, I replied –“Hmmm, instead of just one customer, shouldn’t the whole world be the customer for you? After all, your apps are used by the whole world and I am sure a lot of people out there have ideas of about how to make them better. How can a bunch of business analyst think on behalf of the whole world and draw requirements for you?”

“Interesting, I didn’t look at it that way”, said my friend. “But let’s say for a second that I agree with you. How do you propose we go about collecting requirements from the whole wide world?” At this point, the consultant with in me rose to the occasion and said, “Blogs! You can collect your requirements from Blogs!” The conversation did not go much beyond “Yeah, right!” But later that week I gave it some more thought. Why can’t it be done, what could be the concerns, is it really that farfetched an idea? I am sure it has been done already by someone, somewhere.

In this post, I have tried to outline an approach on how to use discussion forums and blogs in a disciplined manner to extract user requirements. It will also throw some light on some projects that have already used this concept successfully. We will try to crystal gaze and see what common problems could surface when you try to knit blogging web into the Software Development Life Cycle (SDLC) cycle.

We will also extend the discussion to plant some thought about knowing our customer’s customers. We will look at how to help our customers reap the thoughts and ideas of their customers in order to build best of breed applications.

About Requirements

Some people hate them, some are obsessed by them and some abuse them, but none of us can ignore them. Requirements and scope are by far the most talked about subjects of the SDLC. Traditionally, requirements used to be extracted during the begining of the project, finalized and then brought to life through the remainder of the development cycle. A few decades ago, the realm of requirements changed first with the advent of iterative development and then with agile methodology. Iterative development gave the business a chance to build requirements in steps to have a better control on the end solution. With Agile methodology, the business analysts became part of the development team, validating and rehashing requirements for high risk project to keep bring some certainty into what they were going to get.

With Web 2.0’s advent, the stage is set to change yet again. Commercial portals these days are more aware of the need to meet the customer’s expectation and more importantly evolve with them. In this new world, it is quite hard to imagine having the same business analysts of 2003 era churning up requirements to stay competitive. Even with the best of the class business analysts, there are no guarantees that your number one portal will continue to remain number one. With traditional business analysts, the trend gradually leads to aping other portals rather than evolving with customers. The businesses can either start employing some psychics to read the customer’s mind and help them retain the number one slot or start asking the customers what they want. For my money, I will wager my bet on the latter.

Requirements & SDLC

Let’s us refresh our concept of SDLC as it applies to a dotcom, before we move further. Irrespective of what methodology is applied in a project, it will go through at least four main phases.

Figure 1 – SDLC Phases

This contextualized depiction of SDLC phases adds another phase – support for dotcom portals. The inception phase is primarily anchored by the business sponsors to make a case for what is needed and why. Traditionally, requirements are extracted in the elaboration phase, before the construction begins. The other phases are used for implementing the requirements as intended, validating it and then supporting your customers in using what you developed.

For a dotcom portal, the case is little different. Most of these portals are not built to solve a business problem. In this world, the more appropriate SDLC would be:

Figure 2 – New Generation Requirements Gathering

For this life cycle, I have separated the requirement gathering into three phases to communicate the idea. They could also be clubbed as three different activities in one phase. In addition, I have added another phase called “monitoring” which will run in parallel with the support phase to ensure that the delivered functionality is actually being used. The three new requirement activities are:

1. Float an Idea
2. Facilitate Discussion
3. Collect  & Rationalize Feedback

These phases are the ones where a collaboration utility like blogs or discussion forums could be employed really effectively. In the new world, when a dotcom portal is launched, it will also have a blogging facility for all its users. They can start a new thread here, post comments to existing posts, etc. And here is the twist, along with all your end users, these blogs will also be used by your business analysts. The new age business analysts will be responsible for floating new ideas, collecting user comments, rationalizing the collected data, take the most sought after features to the drawing board. These blogs will also act as the launching pad for releasing new features and soliciting feedback.

In the next few parts of this post, we will take a look at how blogs can be effectively employed to collect requirements.

Posted by Amit Jnagal at 01:08 PM | Permalink | Comments (2) | TrackBacks (0)

It is finished.  After months of working weekends, you are finally ready to go live.  The bug list is now short and manageable.  You have done your performance testing and you are good to go.  You go live with the redesigned site, breathe a sigh of relief and book tickets to the Caribbean.  Then something happens.  Support calls are spiking.  It seems that your customers are complaining about the speed of the new site.  The calls are coming mainly from customers in Ontario and in Florida.  Your boss has been called in to the CEO’s office and gotten chewed out.  He comes to see you with a stressed-out look on his face.  He isn’t yelling but …

You tell your spouse to cancel the vacation.  You rollback to the old site and you tell the staff that you guys are working the weekend again.  You put your head in your hands and ask yourself, “What could I do more than I have already done? I spent four weeks on the performance tuning.  Every one of our load tests showed that 99% of the simulated customers had sub-three-second response time.  And now I look like a moron.”
Our development manager friend has made a classic error:  he was not sufficiently paranoid. He trusted a simulation that was not worthy of his trust.  Every simulation deviates from reality some.  If that deviation is small, then the simulated result will be a good predictor.  If that deviation is too great, then the result is garbage.  Our manager should have asked himself a set of questions before declaring that the new version of the software was good to go live:
·         How many simultaneous customers are we simulating?  Is this number correct?
·         What hardware are we testing on?  Is it representative of the live site?
·         What other processes take place on the live site that aren’t present on the test platform?
·         What are we testing? Is the ratio of tests that we are running a true indication of what we will see when we go live?
·         Where are we testing from?  If our test is within our own firewall, then we will not be simulating what the end users will see.
·         Are our tests from a single geography?  Every region has its own network characteristics and its own set of ISPs. 
A good performance test must be accurate enough to cover the risk to your revenue stream and your brand.  An experimental eCommerce site that sells no-name closeouts can temporarily afford to give the user a shaky experience.  An upscale brand that sells $1B US/ year cannot.  In the second case, great performance testing rigor must be instituted.  This rigor involves doing the following:
·       Create a set of test cases that accurately reflect the mix of activities that the site will experience on a daily basis, especially during peaks.  This requires a careful analysis of the web analytics data and the creation of a transactional load profile. This load profile can then be used to add additional test cases and to set the frequency at which they are run.
·       Move the test outside the firewall.  Ideally, move the performance test close to where your users are.  If you test in Atlanta, how will you know if you are getting good response time in Canada? Do you sell in Europe? California? This higher the risks the more elaborate the testing has to be.
·       Test on multiple browsers.  Which browsers are most of your customers running on?  How does that affect your response times?  A whole new set of browsers from Microsoft, Google, and others has just been released.  They have a new set of performance characteristics that differ from the old browsers.  You must test on every browser that can impact your performance.
·      Test on multiple connection types.  What types of connections do you customers use?  If 50% of your revenue comes from dial-up in the Northeast, then you need to know what they will experience before rolling it out to them.
Andrew Grove chose “Only the Paranoid Survive” as the title of his famous book on business advice.  We, as software development professionals, would do well to remember that.

 

 

Posted by Stephen Alan Potts at 06:42 PM | Permalink | Comments (2) | TrackBacks (0)

Before I write anything about Next Generation SEO trends, let me explain what I mean by next generation SEO. My idea of next generation SEO is something similar to a car in cruise mode or a plane in auto pilot mode where minimum intervention from driver or pilot is needed. Next Generation SEO is a self healing system which is enriched by numerous data sources and intelligence using which it will keep improving itself. Currently there are lot of analysis tasks which are required on continous basis to keep improving ranking of your web pages. Analysis tasks generally includes Seasonal keyword trends, Keyword research etc. for SEO optimization. Next geneartion SEO systems will be able to automate much of this and build a self improving SEO datamart.

I am a big bollywood fan so first example is from Bollywood. And before I proceed, let me disclose that I am big fan of Shahrukh khan (He is a bollywood actor). Those who don't know Shahrukh Khan, I strongly recommend reading about Shahukh on Wikipedia and watch few bolloywood movies :-)

Recently I was looking to buy a book which was written on Shahrukh Khan but I couldn't recall the name so I decided to search for the book on Google and searched for "book on shahrukh khan". (http://www.google.co.uk/search?hl=en&q=book+on+shahrukh+khan&meta=)

Though I got book results from Amazon but that made me think that what other Shahrukh fan might search if they are in similar situation as me. For those who don't know Shahrukh is also known  as SRK (Stands for Shah Rukh Khan) and King Khan. I decided to look at the customer behavior and see there are any trends which exists here. Another google tool to my rescue this time and I looked for trends for terms SRK, Shahrukh Khan and King Khan on google trends. (http://www.google.com/trends?q=SRK%2C+Shahrukh+Khan%2C+King+Khan)

This is very evident from this graph that in recent years term "SRK" is gaining momentum as a search keyword on search engines whereas queries for term "King Khan" are still very limited. This brings a important point if somehow there is a intelligent way to co-relate SRK with Shahrukh Khan or King Khan, you can optimize your web pages for term "SRK". More importantly, you can atleast include these related terms in descriptive URLs for the product detail page.

Anybody who has observed SEO efforts of big e-retailers in recent years can easily figure out that  descriptive URLs for product detail pages are constructed using a algorithm which takes product title as input (Check URLs for Amazon results in google in first screen shot in this post) and if this co-relation can be built into the algorithm, output will definitely will be more fruitful for SEO efforts.

But millon dollar question here is that how IT systems can figure out this co-relation between various terms. Remember the data soruces which I mentioned while defining Next Generation SEO systems? Those numerous data sources will be the key to build system intelligence. Next question is that what those data sources might be...we still need to figure out. I attempted to look for the data source which we can use for building SEO intelligence. Here are some of those data soruces:-

1) Wikipedia can serve as a valuable data source here. Wikipedia entry for Shahrukh Khan (http://en.wikipedia.org/wiki/Shahrukh_Khan) can definitely help in this particular case and to my surprise wikipedia knew that these three terms are co-related (Check Other Names section).

2) In my search for additional data sources, I landed on Amazon.com. It's a hidden treaure for customer insights in my opinion, hence I tried to give it a shot for this research. Amazon "related searches" feature can provide valuable insight here. Though, in case of "Shahrukh Khan" amazon didn't suggest SRK or King Khan to me but I am sure some day Amazon's system will learn this and will be able to provide this insight as well. Or Otherwise, by community  contributions like "Amazon tag for Search" (https://www.amazon.com/gp/associations/wizard.html?ie=UTF8&ref%5F=s9%5Frk%5Fdpcs%5Fwiz&asin=0446578584), I expect Amazon systems to build that intelligence some day...and here you go...we got another data source to feed into our SEO data mart.  

3) Another data source may be insight which you get from your Web Analytics tools like Omniture, Web Trends etc. You can always feed Search term report from analytics tools to SEO data sources and that might result in some useful trends. (You probably want to get a customize search term report like "Common search terms used by various customers who ended up buying same product"). With this additional data point, next generation SEO Data Mart can gain some further insights on consumer behavior when it comes to searching.

4) Further search for data sources takes me back to another google product. This time it was recently launched "Google Insights for Search". Google insights showed me a clear pattern for regional interest in these terms. (http://www.google.com/insights/search/#cat=&q=SRK%2C%20Shahrukh%20Khan%2C%20King%20Khan&geo=&date=&clp=&cmpt=q)

With this it's clear that in Finland and Switzerland, people search for Shahrukh with term "SRK" rather than searching for "Shahrukh". With this comes the concept of GeoMarketing SEO URLs. Now it makes sense to focus your efforts for optimize your pages for term "SRK" in Finland and Switzerland and for "Shahrukh Khan" in rest of the world.

Now to digress from Bollywood here, if you take the example of newly launched Canon 1000D Camera (http://en.wikipedia.org/wiki/Canon_EOS_1000D). This particular model is known as EOS Kiss in Japan and EOS Rebel in United States. If you compare the search traffic for these two terms (EOS Kiss Vs EOS Rebel) in google trends (http://www.google.com/trends?q=EOS+Kiss%2C+EOS+Rebel&ctab=0&geo=all&date=2008&sort=0), it clearly shows that traffic for EOS Rebel is significantly higher compare to EOS Kiss. 

  

But regional data reveals some interesting facts here again.... Search pattern for these two terms is exactly opposite in Asian countries compared to Europe and United States. This data can serve as a very useful insight in coming up with Geo-Optimized SEO URLs.

We will see more and more data sources or services which will provide ecosystem for Next Generation SEO and obviously building a system like this will have it's own challenges. Lot of research is still required in order to come up with a robust system which can consume all these data and provide insights using this data. This may require a significant investment in technology which probably only big players will be able to afford. Small players will have to wait and watch if this works or not.

I will be looking for more and more data sources in future to support this theory. Meanwhile feel free to comment on this post if you have interesting thoughts or ideas..... 

Thanks for reading. 

 

Posted by Rockey Nebhwani at 03:44 PM | Permalink | Comments (11) | TrackBacks (0)