Terminology mining, term extraction, term recognition, or glossary extraction, is a subtask of information extraction. The goal of terminology extraction is to automatically extract relevant terms from a given corpus.

In the semantic web era, a growing number of communities and networked enterprises started to access and interoperate through the internet. Modeling these communities and their information needs is important for several web applications, like topic-driven web crawlers, web services, recommender systems, etc. The development of terminology extraction is essential to the language industry.

From Wikipedia - Terminology extraction

In this log, I speak about Auto-tagging:

• Why we need it
• What is the challenge
• The different approaches: naive term frequency versus global semantic web-service
• The key role of compounds (i.e.: double-worded tags)

In this log, I speak about Search and Tag Clouds:

• Difference between Search and Tag Clouds
• Similarity between Search Clouds and Search Autocomplete Suggestions
• Potential to extend their usage for navigation
• Challenge to mix search and tags Clouds together (usage versus document frequency)

In this new domain where art can meet with technology, visualization with data mining and repetitive manual efforts with automation, I felt it was interesting to inspect the different components and their roles; and to figure out what is new and what is old, what is solved and what is not, what is possible and what is pure fantasy…

Let’s first visit the different aspects involved in the generation of a beautiful tag cloud like the one in the picture here-above:

The visual generator:

The visual generator traditionally receives a list of weighted terms and display them visually. While most tag clouds order the list from the top-left to the bottom right according to a specified order (the most common case being the alphabetical order), others take a more artistic approach like the one shown above.

The fundamental role of all visual generators is pretty much always the same. Therefore, I will focus more on the usefulness of the generated tag-cloud for the user as a tool to access information. I will analyze it in different contexts, and in relation with the way the terms and their weights are generated.

The content (i.e.: the weighted terms):

The traditional approach of a tag cloud consist in analyzing all the tags of all the content of a web site (or of a content database) and to generate all the weights with a scoring formula as this one (from Wikipedia):

for t_i > t_min; else s_i = 1

• s_i: display fontsize
• f_max: max. fontsize
• t_i: count
• t_min: min. count
• t_max: max. count

Then, all the tags are ordered according to their score and only the N top tags are considered to be displayed. Other variants are using a logarithm approach to calculate the score (instead of a linear approach like in this example). However, we can see that the term frequency (ti: count) is the key element of the scoring.

NB: In opposition, a Search-Cloud considers the frequency of the search to calculate the score, and not the number of results the search returns. Therefore, the visual generator of a Search-Cloud and of a Tag-Cloud is the same, but the content and its meaning is fundamentally different.

Why the tag-cloud?

Let’s analyze the  basic advantages of the tag-cloud as a visualization tool: while more structured ontology (e.g.: a tree of categories) have an inherent structure which is easy to apprehend for the end-user, a tag has a poor level of structure as it simply identifies a concept, but does not relate it with other concepts.

As a result, tags are a list of concepts, some of which are shared only by a very small number of elements, while other might cover the large majority of them. Therefore, the most frequent can be a quite good representation of the domain specific terminology of the web site. The goal of the tag-cloud is to show their relative importance as a new dimension in their visual presentation.

Such “horizontal view” gives a complete outlook of the most frequently referred concepts in a way which is easy to grasp visually. Where structured trees of category might fail to give an efficient access to many elements in the sub-nodes (either because the meaning of the first nodes is not intuitive, or because the user would not have thought the concept would be available at all), tag-clouds can succeed to give a solution, intuitive for anyone.

In what contexts?

While the traditional use of the tag-cloud is in a global context, it could also be used within a more specific context to further drill-down an initial category selection or a textual search (e.g.: after clicking on “student” in the tag cloud, a potentially very large list of result can be displayed, the tag cloud could then be refreshed with the tags and their score within this search context). This approach seems to make a lot of sense, but brings a certain amount of behavior which should be analyzed.

1. Synonyms: when two tags are synonyms, they are usually not likely to have the same association to the document (this is a general problem of tags, but it is emphasized by the usage of contextual tag clouds). If “automobile” and “car” are both tags in a web site, then even if they will have many documents in common, there will be a certain amount (maybe a minority) which will be exclusive for each. As a result, after selecting “automobile”, the most likely best scored tag will be “car”. This is a bad experience for two reasons: first it gives the impression to the user the coverage of the first tag is not complete (which is true, but not necessarily the feeling we should give to the user) and it pushes with the biggest score a repetition of the same concept which is likely to reduce only the list of result of a small fraction (if “automobile” provides 1000 results, then adding ”car” might only reduce the list of results to 950 results). The experience is therefore bad from all perspective and it is clearly a case which should be avoided (one solution can be to consider the absolute distance to the mean 50% of the remaining documents, this way even if the synonyms are not removed, they appear with a much smaller size than the concepts which are very discriminant).
2. Small list of results: while the list of results remains big enough, the statistical distribution of the tags is likely to stay meaningful, but when this number decreases (which is expected by the user to happen as quickly as possible), the fundamental advantages of the tag cloud is also reduced significantly. On the one hand, the results are likely to belong more an more to a very specific concept and the tags differentiating them are likely to become more and more unimportant or even irrelevant. If the user starts to feel the value of the tag-cloud decreases, it is likely that he will put the overall usefulness of the tag cloud in question. An easy solution is to remove the cloud when a minimum threshold is reached, but it might also disorient the user as he might not understand why it happens. The solution for this matter might be the subject for a future post in this blog as I didn’t find a valid solution for it so far.

NB: Another interesting idea could be to consider te popularity and the tag (the number of times it is clicked on or entered as a search query) and not only the number of documents linked to the tag to define the scoring.

The right terms are compounds:

While the tag cloud picture here-above is visually attractive, it is not containing what I would consider to be the “right terms”. Terms like “use”, “however”, “much” are clearly irrelevant and do not bring any navigation value to the user (on the contrary, they can be quite misleading).

It turns out that the right terms are compounds and their sub-parts:

The majority of domain specific terms are compound nouns, in other words, uninterrupted collocations. 85% of domain specific terms are said to be compound nouns. They include single-nouns of the remaining 15% very frequently as their components, where “single-noun” means a noun which could not be further divided into several shorter and more basic nouns. In other words, the majority of compound nouns consists of the much smaller number of the remaining 15% single-noun terms and other single-nouns. In this situation, it is natural to pay attention to the relation among single-nouns and compound nouns, especially how single-noun terms contributete to make up compound noun terms.

A simple but powerful automatic term extraction method - Hiroshi Nakagaway (University of Tokyo) and Tatsunori Mori (Yokohama National University)

It is quite easy to understand why this makes sense. Let’s consider the following terms : “remote”, “power”, “control” and “off” and let’s imagine them distributed with many other terms in a tag cloud. Now let’s imagine compounds instead: “remote control” and “power off”. It is easy to see how much domain specific knowledge is contained in compounds, but are lost if they are split into single terms.

Auto-tagging versus manual tagging:

While I have tagged manually my blog to this day and do not complain about doing it, a significant increase in the amount of data might very well change my mind on the matter. Would many people write posts in my blog without being necessarily careful in tagging, I would then have an increasing feeling of uncontrollable chaos. An auto-tagging technique able to remove this trouble and avoid the synonym problems stated above, would then clearly be of great value.

I will not go into the details of Auto-tagging technologies in this post, as I believe it should be a debate on its own, but would simply like to state the key challenges at stake in Auto-tagging:

• The overall set of tags used should not be domain specific only, they should also differentiate contents between each other (e.g.: tags like “computer science”, “software” or “Internet” would have no value for my blog, even if they are domain specific, as they do not help identify a specific post (too general)). However, the statistical occurrences of “software” might be (by accident) misleading for a naive auto-tagging technology, to the point of making it look like a very good tag (maybe 50% of my posts use this word and 50% don’t)
• A content can be linked to a tag even if there is no no occurrences of it in its textual content (e.g.: very often, we use words which are very important in a summary, providing the key topics involved, while these words do not appear in the content at all)

Finding the right list of tags and connecting them to the right content should be considered as two separate processes. The first part of the problem should be to find the tags throughout all the content (possibly relying on external global semantic knowledge to do so) and the second to extend their mappings to the document (even if it is possible, in rare occasion, that a document, which has been the source of a selected tag, should not be connected to it).

When shopping for a product or searching for information on a website, it may take several attempts for consumers to find what they are looking for. It is suggested that these unsuccessful attempts to find a product or information, i.e., dead-ends, influence consumers’ perception and evaluation of the website usability. Results of this study, conducted with 204 consumers over two different sites, suggest that there is a negative relationship between the number of dead-ends experienced by consumers while shopping online and the perception of the website usability.  In addition, contrary to popular belief, a positive relationship was found between the number of pages visited by consumers and their evaluation of the website usability. [...]

The influence of Dead-Ends on perceived website usability

The approach described in the above reference relies on supervised test with over 200 users and is a statistical approach to identify and quantify the dead-ends in a collection of selected web-sites.

I will discuss here some simple methods which can be used to illustrate some Search & Navigation Dead-Ends without any guarantee that they correspond to frequent dead-ends, nor that they represent the majority of the cases, but which do not require any statistical data to identify. The points here-under should therefore be only considered as a checklist to exemplify typical search & navigation dead-ends to open the discussion with a new party on a concrete basis. Advanced statistical tests - like “Clickstream” described in the research above - are highly recommended to validate the significance of the cases of these methods.

Back to the frustration causes:

In my past post “Causes a frustration in the Search & Navigation Experience”, I indicated some of the key frustrating factors of the search experience: DOES NOT EXIST, TOO FAR, HIDDEN, UNDEFINABLE, UNDIFFERENTIATABLE, UNCOMPARABLE. These factors correspond to situations where the user feels in - or close to - a dead-end. I provide here-under 10 easy to identify cases where some these situation can happen.

Before starting, let’s define first the positive use cases with traditional search & navigation today:

1. The search keyword(s) used are represented in all of the desired results textual description exactly as is, and only in all of the desired results textual description exactly as is.
2. The categories provided bring me (after an intuitive and short sequence of steps) to the information I am interested in.
3. With some technology, a combination of both these cases (traditionally, the search step first and the category filtering step after).

NB: A last word foreword: the cases here-under have been made simple and therefore often do not consider combinations. Such combinations are easy to do (e.g.: adding a keyword to the search which doesn’t change the problem, but make it more complex). In concrete illustration cases, it might be necessary to show combination cases, as customers will tend to defend their current system by saying that it is possible to find a category by one or a few clicks and therefore that the user should not search in these cases. This is often not a valid argument as the fact that people “shouldn’t” search in some cases doesn’t change the fact that they do, nor that they do not want to read a manual telling them when they should or shouldn’t search. But in order to simplify the presentation process, a combination case can immediately solve this issue as it is then clear it is not possible to have the same situation simply by browsing in the tree of categories.

1. Long list of results

Pre-conditions: The user searches for something simple which generates a lot of results.
Symptoms: The user does not receive any relevant help to reduce this list by making a filtering selection.
Effects: The user will only look at the first page to see if there is (by chance) exactly what he is looking for and, if not, will either leave the web site or will try another search (refine his search by adding an additional keyword might bring him to the case 4).
Frustrations: TOO FAR, UNDEFINABLE
How to find the right use cases:
- Search for one word (or one search concept) only
- Search for the name of a category (or sub-category) you know contains a lot of products (tv, fridge, book, etc.)
- Search for a famous brand, a color, or a property common to many products in the database

2. Synonyms

Pre-conditions: The user searches for something which can be written in different ways.
Symptoms: The user receives one list of results if he types one word and another list if he types a synonym OR The user receives a list of results in one case and zero results in the other case.
Effects: The user will not necessarily understand what happens and can come to the conclusion that the product he is looking for is not offered in this web site. If the user does understand, he will be confused on what to do next to make sure he has seen all the possible results and will be frustrated to have to check all the different cases by himself. He will be less likely to make a purchase as he will never be sure to have seen all the possible options (maybe he forgot to try an important synonym). He might also not find the product he is looking for and leave the web site not knowing if the product is offered or not.
Frustrations: HIDDEN, TOO FAR (not necessarily too many pages, but too many trials to do), DOES NOT EXIST
How to find the right use cases:
- Close synonyms (e.g. “mobile phone” instead of “cell phone”)
- Distant synonyms (e.g. “optical media” instead of “CD-R”)
- Branded names (e.g. “Wi-Fi” instead of “802.11b”)
- Different spellings (e.g. “file cabinet” instead of “filing cabinet”)
- Simple plurals (e.g. “screwdrivers” instead of “screwdriver”)
- Complex plurals (e.g. “knives” instead of “knife”)
- Acronyms (e.g. “SLR” instead of “Single Lens Reflex”)

3. Misspelled words

Pre-conditions: The user searches for something but fails to type it correctly.
Symptoms: The user receives either no results or the wrong ones and is not properly helped to correct his spelling mistake.
Effects: The user might try a few other variants (in the case he does understand that his problem was the spelling); he might try to find the products another way (other search and/or category browsing); but he is very likely to leave the web site without even knowing if the product is offered or not.
Frustrations: HIDDEN, TOO FAR, DOES NOT EXIST
How to find the right use cases:
- Brand names (e.g. “Motorolla” instead of “Motorola”)
- Category names (e.g. “Pilateese” instead of “Pilates”)
- Product names (e.g. “Airon” instead of “Aeron”)
- Product details (e.g. “Mahagony” instead of “mohagany”)
- Author or artist names (e.g. “Bill Mar” instead of “Bill Maher”)

4. Mixed specifications

Pre-conditions: The user searches for more than one criterion.
Symptoms: The user receives either no results or too many (some web site use an OR filter in such case).
Effects: The user will need to do another search with only one element, which might be a problem as the reason he is using mixed specifications might be because a search with one element generated two many results (loop between point 1 and point 4).
Frustrations: HIDDEN, TOO FAR
How to find the right use cases:
- Mixing gender and products (e.g. “Women’s sweaters)
- Mixing details and products (e.g. “Red jacket”)
- Mixing specials and products (e.g. “Skirts on sale”)

5. Too general

Pre-conditions: The user searches for something with keywords that are present in many more results than the ones he is interested into.
Symptoms: The user receives a very long list of products probably including what he is looking for, but potentially hidden within many irrelevant results. He has no appropriate filtering criteria suggested to him to remove the results he doesn’t want.
Effects: The user will need to do another search with one more search keywords (potential loop between point 1 and point 4).
Frustrations: UNDEFINEABLE
How to find the right use cases:
- Search for a category name which is present in many contexts (”accessories”, “sony computer” (might show also all the other computers having a “sony” memory card), “usb” (will show not only the keys, but also all the computer who have usb), etc.)

6. Incomplete coverage

Pre-conditions: The user searches for something with a specific keyword which is only present in the textual description of a small percentage of the desired results, even if a lot of the other products have it (by default, or written differently).
Symptoms: The user receives a list of results witch only contains some of the results he is looking for. He might come to the conclusion the products doesn’t exist or will realize he needs to make a more general search and analyse many more pages of results to be sure he has seen all the relevant products.
Effects: The user will need to do another search with less or other search terms.
Frustrations: HIDDEN, DOES NOT EXIST
How to find the right use cases:
- Search for specific feature that you have identified is not always properly listed (e.g.: “HD-READY”, “6 channels”, “HDMI”, etc.)
- Search for a specific binary feature (e.g.: if the description of the features contains “MULTI-LINGUAL : yes” will not provide the right search behavior unless specific manual configuration has been done)

7. Too complex guidance

Pre-conditions: The user searches for products having hard-to-understand features.
Symptoms: The user receives search guidance criteria which are not easy for him to understand as he is not a specialist (e.g.: “How many Gos do you want for your MP3 player?”). He has no idea of the meaning of the filtering options he has and chooses one more or less randomly. Unless he is very lucky, he will need to come back.
Effects:The user will need to make some guesses (does not make him confident that he is choosing the right product) or will ask for help.
Frustrations: UNDEFINEABLE, UNDIFFERENTIATABLE
How to find the right use cases:
- Navigate in every category and look at what questions are asked in different context (typically focusing on the domains where some technical knowledge might be useful; e.g.: computers, digital camera, etc.)

8. Parallel searches

Pre-conditions: The user searches through several parallel searches (potentially due to any of the cases above).
Symptoms: The user will either use extensively the back&forward buttons and will often have to redo the same searches (i.e.: the less-technical person) or will open many tabs with all the products he has selected in any of these lists (i.e.: the more technical person). The user will then not be able to use the product comparison feature and will need to do it by switching visually from one case to the other to look at what is different. If more than 2 products are selected, this process is very painful.
Effects: Unless the user comes to a purchase decision directly, he will not be tempted to come back to the web site for this purchase, as he will remember all the efforts he had to do to have the selected products compared  (and know he will need to do it all again).
Frustrations: UNCOMPARABLE
How to find the right use cases:
- If the web site doesn’t support multiple selection on the filter choices (results in different searches)
- If the web site doesn’t propose enough filtering criteria (results in different pages)
- If the web site doesn’t provide re-definable search criteria (after selecting a few criteria, the user might want to reconsider one to see what are the alternative, if he needs to start a new search, he will need to keep things in parallel)

9. Partially satisfied searches

Pre-conditions: The user searches for several criteria which work individually, but not together as no product matches all of them.
Symptoms: The user will need to make many trials to understand which variations are supplied and which ones are not.
Effects: Unless the user is both patient and technically advanced, he will give up. If he doesn’t, he will still have the parallel search issue at the end as several variants probably exist.
Frustrations: UNDEFINEABLE, DOES NOT EXIST
How to find the right use cases:
- Find a case of at least 3 criteria providing solutions 2 by 2 (at least for two cases), but not all together
- Try to use global attributes (not specific to a category) (e.g.: COLOR (global) + BRAND (global) + CATEGORY (global)  - versus - CATEGORY (global) - SUB-CATEGORY #A (local) - COMPONENT ONLY AVAILABLE IN SUB-CATEGORY #A (even more local))

10. Consequence of setting filters

Pre-conditions: The user selects some criteria without realizing that their selections filters out others which are necessary for him.
Symptoms: The system will remove the criteria which are no more valid and the user will realize that an important option is not offered anymore. The user does not necessarily remember (or simply understands) what action made these choices disappear and might come to the conclusion he selected “something wrong”.
Effects: The user will need to go back and identify when he defined the search criteria which filtered out the products he really needs and chance his selection at this stage (that is, if he is able to).
Frustrations: UNDEFINEABLE
How to find the right use cases:
- Usually, brands have a hidden connection with prices. Selecting some brand often removes some price ranges
- Unusual color or features often make some sub-category, heights, price or weights unavailable

NB: Several examples here-above are coming from this quite old, but quite useful and still quite relevant study.

The main goal of this speech was to present a case study explaining how Corbeil Electroménagers has implemented a new CEM approach and technology on their E-Commerce web site (here are the slides I presented).

Keynote introduction:

We will present how Corbeil Electroménagers launched a new innovative technology to improve the customer experience on their E-Commerce web site.

We will demonstrate how we achieved to bring a more human-like online experience, by replacing the traditional trial & errors into an empowering step-by-step guidance.

We will show how we solved the key search and navigation experience challenges at their roots: from suggesting guidance already in the search auto-completion, to helping refining and redefining the search context; from comparing similar products between manufacturers, to transferring qualified requests to the right human expert.

With this new environment, Corbeil has successfully transformed all the experience dead-ends into a continuous sequence of human-like navigation steps, each of which is only one step away from a purchase or contact action.

Finally, the continuous monitoring of the search behaviors and of the satisfaction of the customer intents enable Corbeil to continuously monitor the adaptation of their product offers and stocks status to the dynamic reality of customer demand.

- -

Here is an online press article written about my presentation.

I have also done a presentation about doing business in China:

Distributing your software in China: the real opportunities, the real challenges

China’s market size and growth have everything to blow the most conservative minds, but why so many international firms invest while so few succeeds?

Sylvain Paillard started Guidyu’s operations in China in 2006 and has been based in Beijing for the last 2 years as General Manager for Greater China. Mr. Paillard manages the local R&D, Sales and Administration teams and successfully secured the investment of Chinese risk capital in the company at the beginning of 2009. Guidyu has established partnerships with the biggest software companies in China and has been able to penetrate various verticals of the domestic industries: from brick and mortar industries like Banks and Telcos to innovative young Internet companies.

Mr. Paillard will visit some of the key aspects enabling a successful distribution of foreign software to and through local Chinese companies and will share some of the main challenges his company faced and how they have been overcome. He will also try to demystify some of the most bias ideas westerners frequently have about what it is to do business in mainland China.

While the fundamental goal of most web analytics systems is to reports the KPIs (Key Performance Indicator) having the most effect on sales, these KPIs all tend to be usage driven instead of satisfaction driven.

The CEM (Customer Experience Management) consulting companies tends to supplement this problem by polluting the life of the customers by asking them to answer countless surveys, but fail to deliver precise and actionable conclusions, especially on the per case basis.

How can you capture your customer intents in order to see how well your product offering is adapted to it and presented properly?

Understanding the key parameters of customer intents for products which are not easy to find or not in the database is the key to ensure the satisfaction of all the significant purchase intents.

Statistical information like product page views and purchase counts give valuable information about the products matching the most common customers’ intents of purchase, but they do not provide any information about why the purchase happened, or help identifying missing product lines or products which are hard to find.

As the entire structure of e-commerce web sites is build around its existing content, the only real source of information of unsatisfied intents are the search logs, but it would be a mistake to consider them as a perfect representation, notably for the following reasons:

1. Intents are flexible; search queries are not:

Customers traditionally have a certain flexibility in the definition of their intents, which is not well adapted to the rigidity of the search query. As a result, the search queries tend to be either to general or too specific compared to the real intent.

For example, a customer searches first for “shampoo”, while he is looking for a shampoo of a high class brand, and will then do a new search with “shampoo l’oréal” due to too big amount of results provided by the first trial.

2. Intents are subjective; search queries are not:

Only the most objective parts of the customer intent are usually expressed, the customer will then evaluate if products matching his intent are in the list or not, but will never inform the system of what the intent really was (whether it is matched or not).

For example, a customer searches for “shampoo”, while he actually intent in buying an expensive shampoo for his wife. Only the objective part remains.

3. Intents are personal; search queries are not:

An intent is very comparable to a motivation: there are many different intents bringing to the same product, but for different reasons. Due to the impossibility to express an intent freely as a search query, only the people able to formalize objective and impersonal search queries will use the search tools enough to provide statistically relevant information.

For example, a customer who is looking for a shampoo to protect his sensitive hair and likes ones with tropical fruit smell will probably not know how to formalize his search query, but if he saw a commercial of it and remember the product name, he will simply type it.

Another critical problem of analysing and understanding the customer intent only with search logs and category access statistics is to identify the unsatisfied intent. First, many intent will not be expressed (as discussed above), and the only simple case which can be managed easily is the identification of the search queries providing no results, however, this approach has a very limited potential, partially for the following reasons:

Many searches provide results, but many do not include any relevant result

As the amount of textual information about products (description, features, reviews, comments, etc.) tends to become more and more important, it starts to be increasingly uncommon to face the zero results page. To some degree, one could argue that it is better, as showing a list of items which are at least partially relevant is better than no list at all. However, it is not the same from the side of the web analytics where we would like to differentiate the cases of success and failures.

For example, a customer searches for “l’oréal conditioner for sensitive hair”, but none of the products of the database matches this intent. The search will stil provide results with L’oréal conditioners as the others words can be found from the textual descriptions and the customer reviews (even if in a negative sense, e.g.: “not for sensitive hair”). It is then almost impossible for the company to identify that this request was not properly answered, even if it provided results.

Unfortunately, differentiating the searches bringing sales from the others cannot help either, as the one bringing sales are very clean, but not helpful, and the others tends to be extremely noisy and most of the time unusable (as many search queries providing valuable results will be there as well).

In this post, I try to demonstrate that the need of a new understanding level of the search queries is not only beneficial for the end-customer (as discussed in prior and probably future posts), but is absolutely necessary to report and analyse customer intents properly.

In this process, two components are critical for the success:

1.    Have a technology which is able to capture the customer intent in a structured way
2.    Educate the customers so they know they can express their intent freely and should expect the web site to answer them better over time due to the intent analysis and optimization outcomes

PS: All the examples are coming from a current case I am working on (www.perfecthair.ch), so don’t worry, it’s not that I am trying to sell shampoo, it’s just my current work which is a good source of examples and a motivation for this post

As a result, two potential reaction are usually adopted:

• I prefer not receiving these services anymore until there is something better out there
• I will use it for now, but I will definitely quit as soon as there is something better out there

The type of reaction is usually more linked to the need we have for the service than our level of frustration (i.e.: we can be extremely frustrated, but continue to force ourselves to continue if we really need to find the information, while a slightly disengaging experience turns us off quickly if the service is not critical for us).

In this post, I try to identify the sources of these frustrating experiences when related to search & navigation and discuss the ways they can be solved.

As we can see in this diagram, a negative experience can be worse than no experience at all!

Defining properly the real cases of frustration of the online experiences is a much more complex task than it seems. Indeed, a definition like “I can’t find what I am looking for” is not quite precise enough to come up with appropriate solutions.

Here are the most common cases as I see them, which I divided in two groups:

A: I know what I want:

• DOES NOT EXIST: The information I am looking does not exist on the web site.
• TOO FAR: The information I am looking for is in a list of many results, but I don’t know where
• HIDDEN: The information I am looking for exists but is not included in the result lists of my searches/navigation

B: I don’t know what I want (at least not exactly):

• All the points of A
• UNDEFINABLE: I don’t know how to define what I am looking for (maybe it is there, maybe not)
• UNDIFFERENTIATABLE: I don’t know how to identify the information which I want out of others which seem fully similar
• UNCOMPARABLE: I found something, but it is impossible (too hard/long) to make sure it is the most adapted option for me

Many other points could be added in consideration of the reasons people decide not to buy on e-commerce portals, but I will only focus here on the frustration of the user, not of the seller

Also, other points could be related to the frustration of exploring the content of the information (not sufficient, too complex, too long, etc.), but I will only focus here on the information access problematic.

We can see that the experience of someone who does not know what he is looking for exactly is much more likely to be frustrating than the one of someone who does (which is quite intuitive). This explains to some degree why it is harder to deliver a good online customer experience in a Gift Shop than in a Office Supply Store.

DOES NOT EXIST:

This is probably one of today’s biggest differences between the online and the offline world. When you go to an electronics store and ask for a well known product like the IPhone, they will immediately let you know if they don’t sell it (which is often the case, as the distributor are mainly the telco operators).

Strangely, when you go on stores like Amazon, you have no indications that the products does not exist after searching for it and you might spend (like me) up to 30 minutes until realizing that they actually don’t sell it. You will even find yourself encouraged to do so by the auto-completion search suggestions which invites you to type: “Iphone”, “Iphone 3G”, “IPhone 3G unlocked”, …; clearly misleading as it strongly imply that the Iphone is a well-known product in their offer.

Identifying that the customer is looking for something which you don’t have (or simply that you have, but not as part of your online collection) is a crucial part of providing a positive customer experience. Inviting the customer to be contacted when the situation changes is also a good idea (by e-mail, or by calling him).

TOO FAR - HIDDEN: The great pleasures of trial & errors:

Another way to explain this issue is UNDERDEFINED - OVERDEFINED:

PC under 500$ : 3′000.- results

with bluray burner : 0 results

with a hard drive bigger than 50 Go : 2′950 results

with > 19” screen : 2 results I don’t like

with CPU > 2Ghz : 2′850 results

This is a pretty understandable problem, as most manufacturers focus on the biggest demand and therefore the most needed features are present in almost every models. Many other aspects differentiate them, but most of them are not part of the important need of the customer (for the exact same reason). Therefore, the TOO FAR - HIDDEN scenario can last for a long time, and the user will need to open many tabs on his browser not to loose the products he wants to consider. He will need to switch from one to the other to have a way to compare (not exactly what was intended by the “compare” features) and will lose everything when he exits his browser.

Making sure the user can have an efficient view on the set of parameters which matters for him is key to avoid this vicious frustration cycle.

Depending on the case, this selection can be done explicitly by the user (which brings a certain amount of complexity in the user interface) or induced more intelligently in the back (reducing the freedom of change of the user). There is no magic formula, but there is definitely a need.

UNDEFINABLE:

Try to imagine your mother buying a computer online and you will have a good picture of what undefinable means: while certain people will be able to know what to ask for in terms of CPU, Memory, or Hard drive, defining these parameters can be mission impossibles for others. Their requests are much more subjective and define the usage they want to have with the device, instead of the required properties it must have.

The typical approach nowadays to solve this challenge is to force customers through a predefined path providing simple to understand explanation (e.g.: “What hard drive do you want? A hard drive is where you can store all your data (pictures, documents, etc.)“,[ "100 Go (up to 30'000 songs or 100 movies)", "250 Go (up to 75'000 songs or 300 movies)", "500 Go (up to 150'000 songs or 500 movies)"]).

However, a better way would be to provide a completely different type of search criteria to the users who need them, with parameters like the desired usage: office work, image editing, video montage, 3D gaming, etc.

Adding subjective confirmation on the product can confirm the impression of having found the right ones (e.g.: “This model is perfectly suited if you look for a entry price desktop computer to do office work”, “This model is powerful enough to edit all your family videos with great visual effects like in the movies!”, …)

UNDIFFERENTIATABLE:

There is nothing more frustrating than to have the feeling that 3 products are just exactly the same. In some cases, increasing the size of the database in order to offer a bigger product line can backfire for the customer experience. Customers had no problems to find the right products in the past and are now confronted with big lists of products which all look similar.

This problem can also give the customer the impression that the provider is not able to select the good product offering for him and just pushes everything to make more money. In such case, the price tends to be perceived as the only competitive value (versus the expertise of choosing the right products for the customer target segment).

The best way to solve this problem is to complete the product properties to provide the final differences (and possibly to invite the customer to narrow down his selection with these new criteria).

Another common approach is to provide CGC (Customer Generated Content), not requiring any manual effort on the side of the company and showing an “objective” evaluation of the product to let the customer increase its confidence to identify the right product out of a small selection.

On the other hand, it has the limitation to be very general (if 50% of the people like the products and 50% don’t like it, the ranking will not give anything relevant), and to push a potentially heavy analysis work on the side of the customer (having to read hundreds of reviews, most of them providing no interesting content). On top of this, reviews can contain information implying a bad after sales experience with the provider, which might be difficult to find and moderate.

The most sophisticated approach I have seen so far is CGC over CGC (or like I like to call it: CGC²): let the customers vote for the most useful customer reviews (the one saying the product is good and the other one that it is not). It is then likely that customers will limit their reading to these and it enable companies to only moderate a small percentage of the total amount of reviews.

UNCOMPARABLE:

The problems related to comparing products are quite similar to the one of differentiating a small selection of them. However, the experience (and frustrations) can be quite different. In that way, the comparability is more tricky in terms of customer experience than the problem of differentiation.

• If the customer finds 3 products and needs to differentiate them to identify the best one, the coverage is extremely simple: it’s these 3 products.

• If the customer finds one product he likes, but want to see if there is anything else he should consider, this coverage is fully open-ended.

Unlike what some providers might think, this problem is not solved by pushing more compelling marketing message on the product detail page, as the challenge is not to be convince of the product value, but to remove the fear that there might be something better which the customer didn’t find so far.

The reason why this aspect is extremely important in E-Commerce is that if the customer is not sure that the site has showed him all the products he should consider, he will be likely to look for other possibilites on other web sites. In that logic, ensuring a good comparison experience between the different products can lower the need to compare with other providers.

There are several approaches to help the customer find other products for comparison purposes:

• Prepare a list of similar products for each product
  • advantage: no action required from the user
  • disadvantage: customer has no idea how this list was computed and might not feel it is complete nor adequate for him
• Provide dynamic search filters (with counters)
  • advantage: customer can easily decide which parameters are important to keep and which ones are not (as he can decide which filter he wishes to modify). Counters are important as many combination can lead to zero results and should not have to be tried.
  • disadvantage: none really, except it requires purchasing advanced technologies
• Escalate to the contact center
  • advantage: the customer might just need to hear from a real person that he is making a good choice
  • disadvantage: none really, except the cost of the calls and that not everyone will want to chose this option

Comparison is one of the most important issues in the e-commerce world today. The focus of the industry has been put on the meta-portal showing the difference of price between providers for the same product, but not in finding the adequate products to compare to within the product offering of one provider. This is another example of how the Internet world has accomplished things that were not possible in the brick & mortar world, but totally left aside other aspects which have been  proven extremely important in the real world, for the reason that nobody really knows how to handle it properly.

Conclusion:

This post is not the final conclusion on this topic (far from it) and, if anything, it is more intended to show where the issues are coming from and to group them into a short 6 points list. I will elaborate more on the possible solution CEM (Customer Experience Management) can provide in terms of Information Access for each one of them more in depth in the future, but I hope you can already find the above useful and understand a little better what is at stake when someone tells you that you have customer experience issues with your web site.

The idea of a Dialog System is probably as old as the field of computer science itself.  It is hard to know if Charles Babbage already thought about it in the 1830s when he created his  Analytical Engine and then his Difference Engine; but it is clear that Alan Turing set the definition of the ultimate Dialog System when he described the Turing Test in his paper Computing Machinery and Intelligence in 1950.

From Wikipedia -   The “standard interpretation” of the Turing Test, in which player C, the interrogator, is tasked with trying to determine which player - A or B - is a computer and which is a human. The interrogator is limited to only using the responses to written questions in order to make the determination.

Turing predicted that machines would eventually be able to pass the test and that 30% of human judges would be fooled in a five-minute test by the year 2000.  Futurist Raymond Kurzweil updated it to 2020 in 1990 and revised it to 2029 in 2005.

This last prediction appears to me as uncertain as any of the prior ones, but many interesting Dialog Systems have been developed already and, thankfully, the market does not need the Turing Test to be passed to start adopting them.

Turing Test version 3.png

The fundamental difference between Chatterbots and Dialog Management:

Before providing some elements about the history of Dialog Systems since 1950, it is important to consider that two different trends have been pursued throughout the past decades: the one of simulating a dialog in appearance (which I will call the Chatterbot approach) and the one of modelling a real understanding of the dialog and generating the appropriate answers dynamically (which I will call the Dialog Management approach). We can find the reason for this co-existence directly in the definition of the Turing Test which considers only the impression of validity of the answers provided and not any other sort of proof  of understanding.

In the reality, the developed system sometimes mix both approaches, but one almost always has a clear predominance on the other (and to some degree, one can claim that a Chatterbot has a Dialog Manager inside, even if it usually based on simple pattern matching rules). Let me give an simple example to compare what I mean:

The user asks: “Can you buy me a bottle of milk?”

In a Dialog Management approach, the computer could (but this is just an example), build an model of this kind: [type:Question; action:buy;interrogation:ability to perform action;object:bottle of milk] on which it would query what would have to be a fairly complex knowledge reference-base to answer, for instance, “no, because I have no money”, or possibly to ask a question: “It depends, can you give me some money?”.

In a Chatterbot approach, this internal processing doesn’t exist and a predefined answer is selected through quite simple rules (”Can you*?” => list ["yes, of course", "no, i can't", "no, I don't want to"]). The answer is often randomly selected in the list. The answer can appear to make sense, however, the system has no real understanding of the question, he just fakes to be able to perform a dialog.

It is easy to understand that the Chatterbot approach simply doesn’t make any sense if the goal is to perform a real action and not just to provide an answer (how could a system perform any meaningful action by faking the understanding of the requests of the users?). In my view, it doesn’t make sense when it comes to textual conversation either, because the fundamental limitations of Chatterbots are too great to provide any sustainable value, even when only answering questions.

However, the “wow” affect of good demo cases is so great that, repetitively during the last 50 years, many people have been duped  by the false impression that a free dialog system could work efficiently with a Chatterbot approach. Billions of dollars have been spent in pure vain and, to my great desperation, I predict more will be spent in the future, until the Dialog Management provides sufficient results to simply eradicate this this shameful error in the evolution of computer science.

The history of Chatterbots:

Everything really started in the 60s, when Joseph Weizenbaum developed Eliza in the MIT, which is commonly referred to as the first Chatterbot. The most famous program of Eliza was the DOCTOR script, which provided a “parody” of the responses of a non-directional psychotherapist in an initial psychiatric interview. The irony was that, even if Weizenbaum believed the system had a great interest due to the emotional reaction it created on people, he never really considered it as a solid base for more intelligent systems.  Even more so, the multitude of meaningless discussions and wrong conclusions Eliza created in the society pushed him to write the book Computer Power and Human Reason: From Judgment to Calculation, which argued that the misuse of artificial intelligence has the potential to devalue human life. But people preferred to play with Eliza rather than to read his book and, as in Pygmalion (from which, due to another irony, he chose the name Eliza), he had no control on his creation. If people wanted to believe in the potential of a Chatterbot, even without any scientific justification, it couldn’t be stopped. 50 years later, as I write this post, many companies tried to convince people to buy pattern matching-based systems, even if many historical cases should remind us they are doomed to fail miserably.

6 years later, in 1972, psychiatrist Kenneth Colby created PARRY at Stanford University. The basis were the same as for Eliza, but Parry tended to simulate a paranoid schizophrenic, instead of a psychotherapist. Even if Colby made a much more serious effort, the result was fully similar. As you can imagine, the connection between Eliza (the psychotherapist) and Parry (the schizophrenic) was inevitable, here is the result of their meeting at the ICCC in 1972. As it could have been guessed, connecting two stupid Chatterbots together didn’t result in anything great…

The field didn’t get more serious with Racter, and The Policeman’s Beard Is Half Constructed, a book the creators, William Chamberlain and Thomas Etter, pretended had been fully written by Racter. The result was impressive, but the program was never released to the general public. One year later, when Mindscape released a Chatterbot version of Ractor, it became clear for everyone that Ractor was far less sophisticated than anything that could have written the fairly prose of The Policeman’s Beard. The story is still not very clear today, but it seems obvious Chamberlain and Etter created huge data files containing most of the text of the book, which Ractor just “joint” together.

As early as 1978, Michael Mauldin was one of the first person who tried to bring some reasoning into a Chatterbot, when he created PET, a Chatterbot able to posit new information and became famous for the following Dialog:

Subject:                I like my friend
(later)
Subject:                I like food.
PET:                       I have heard that food is your friend.

Then, Mauldin created Virtual Personalities (now Conversive) and two famous Chatterbots: Sylvie (1994) and Julia (1997).  The key aspects provided by Maulding and Peter Plantec (the other founder) was, in addition to provide incorporated animation and synthetic voice, the ability to explore a virtual world (e.g.: a web site) and use the gathered information in a dialog. In this sense, Mauldin try to open a way out of the pattern matching approach, realizing the knowledge had to come from outside and couldn’t be a pre-formatted data file as for ELIZA. Another interesting aspect is that Mauldin is also the founder of Lycos, a search engine which was initially an extrapolation of Julia. Mauldin is also the inventor of the term ChatterBot in 1994 (as a synonym for Artificial Conversational Entity (ACE))

In 1990, the Loebner Prize contest was created as an annual competition in artificial intelligence that awards prizes to the Chatterbot considered by the judges to be the most human-like, following the same format as the Turing test. The Loebner Prize does not require the Dialog Systems to be based on a pattern matching approach, and therefore, the day reasoning based system will work, they will be able to prove their ability. However, this contest do not reward the sophistication of the approach, but only the result, by following casual chatting scripts and evaluating the relevance of the result. As an effect, systems providing quick results are destined to be rewarded, rather than more serious efforts which would try to solve one small aspect at a time.

Another significant player in the Chatterbot history is Richard Wallace, the founder of  A.L.I.C.E. (Artificial Linguistic Internet Computer Entity). Wallace took a different approach which was quite rewarded as Alice won the Loebner Prize 3 times (2000, 2001 and 2004). His approach went back to a purely pattern matching one, but he created an XML Schema called AIML (Artificial Intelligence Markup Language) for specifying the heuristic conversation rules. The advantage of this approach was that it was easy to create and share knowledge in an AIML file, as well as to load many AIML files together to have a “smarter” bot.

My opinion is that all these efforts on Chatterbots based on pattern matching are a monumental waste of time and money (as we will see here-after, to the level of billions of dollars). You don’t believe me? try Eliza and compare it with 2008 Loebner Prize winner Elbot. Tell me how you really believe that these 50 years of efforts were worth it. Were we really digging at the right place?

Chatterbots in the business world:

The average lifetime of commercially employed chatterbots is restricted to only 6 month.
Forrester Research

One of the most fascinating story related to how large companies believed in the potential of Chatterbots is the case of Artificial Life, a company founded in 1994 which was able to sell custom-made Chatterbots applications to companies like Credit Suisse First Boston, Price Waterhouse Coopers and UBS. The company still exists, and is actually doing quite well, but now in a totally different field (mobile gaming), as, after the Internet bubble burst, they lost more or less all their market.

What is interesting is that the company was able to become public on the NASDAQ (ALIF)  in 1998 and the market capitalization of this company reached a stock value of over $38 in February 2000. In June 2003, the stock was only worth $0.05, or 760 times less 3 years before. What is interesting is that the market capitalization when the stock had a value of $38 was over 1.8 billion USD. This value was less than 2.5 million USD 3 years later.

Artificial life is not the only case, but it is, to my knowledge, the biggest one ever. All this being said, I have to express my highest admiration to their executive team, and more particularly to their founder, Eberhard Schoneburg, who is still their current CEO, not only for having created such an amazing value in the domain of Chatterbot (even if for a short time), but more especially for succeeding in turning the company around, moving it to Hong Kong and having the second highest mobile penetration rate in the world.

Another famous example is the company Ask Jeeves (now Ask.com), who was able to convince Dell to adopt “Ask Dudley” for the online technical support in 1998. Ask Jeeves capitalized quite strongly on its natural language capacities with this Chatterbot-based technology and was able to grow quite well until 2000, reaching $58 million in sales. From a high of $190 per share in 1999, the company’s stock began spiraling downward, falling to just $.86 per share by 2002. Stuck with a technology that simply didn’t have what was necessary to perform properly, Ask Jeeves found a way out by purchasing a search engine company called Teoma Technologies. In 2005, the company announced plans to phase out Jeeves. On February 27, 2006 the character disappeared from Ask.com.

However, both these cases did show pretty strong sales successes compared to the average case in the world of Chatterbot as, in many cases, only grants funding are able to justify the costs of their implementation:

“Most of the German bots were build with funds from grants.”
A Trend from Germany: Library Chatbots in Digital Reference

The Chatterbot technology is inherently stunted in it’s evolution and it’s effectiveness due to the approach and fundamental basis of Chatterbot technologies idea of pattern matching… The fact that there is a completely faked but nevertheless appearance of some form of Artificial Intelligence to the user may make for a sexy sale… but the smoke and mirrors approach in offering customers a new ‘feature’ with very limited value, if any at all, has been historically proven that the road to failure is a short one…

The history of Dialog Management:

Dialog Systems based on Reasoning, in opposision to Chatterbots, try to do much less, but with much more control. As a result, their implementations are usually quite focused to a specific domain requiring specific actions. Even if the history of Dialog Management has not been exposed to the market as widely as Chatterbots, they also have an interesting history.

The first reference I found of Dialog Management being really used is in 1986, in the article “Dialog management for gestural interfaces” of IBM. Of course, many efforts have been done before, but not really on a separated module defined as a Dialog Manager (or at least, not to my knowledge).

Carnegie Mellon University (CMU) is probably one of the research center which has been the most active in Dialog Management during the last 20 years, especially since the AGENDA dialog manager of Wu & Rudnicky in 1999. In 2003, Bohus & Rudnicky created the RavenClaw, which is now the standard Dialog Manager of the Olympus Dialog System Framework, the CMU architecture for spoken dialog system.

Such architecture already show very impressive results, not only limited to the scope of the Dialog Manager, but throughout the entire flow of the Dialog System (speech recognition, natural language processing, dialog management, output generation and text to speech). I am personally particularly impressed by the RoomLine application which show, in my opinion, already a great business potential yet not exploited at all by the market.

Dialog Management in the Business world:

While Chatterbots found their place in casual textual chatting, Dialog Managers tended to penetrate the vocal environment, but first, we needed a standard: AT&T, IBM, Lucent, and Motorola formed the VoiceXML Forum in March 1999, in order to develop a standard markup language for specifying voice dialogs. They published the VocieXML 0.9 standard the same year and the version 1.0 in 2000, followed by the version 2.0 in 2003.

In that light, the field has been heavily pushed in the direction of speech recognition and some very large company were created, like Nuance, the worldwide leader. The company was founded in 1992 and has now a market capitalization of 3.5 billion USD. Even if most of their products are related to speech recognition and document management, their products line based on dialog management is a valuable and growing part of their revenue.

The future:

Nobody knows how long Chatterbots based on pattern matching will find their place in ther market world and how many cases will be necessary for the market to finally understand the limitation of this approach.

On the other side, the hype of Dialog Management is still to come and it is to hope that they will go to the same heights than Chatterbots. We can already see the accomplishment of their early potential in the impressive works done at CMU and it is, in my opinion, just a matter of time until these technologies hit the market properly.

The interesting thing with the hype driven by Chatterbots, is that there is a clear desire especially in our current market context in having machines understand us.  The key lies not just in spewing out a response but rather in having computers ‘understand’ customers and interpret the understanding based on learned ‘experience’.  This in my view is where Dialog Management is taking us, with this approach we can see the basis for evolution, even organically, learning and adapting to ‘experience’ … while enabling technology to deliver the ‘understanding’, guidance and result we are all looking for.

The main goal of this speech was to explain why technologies driven by Artificial Intelligence are going to be the key success factor to provide a positive customer experience online. The main reason I advanced is that the complexity of the task of satisfying all the different of the customer requests properly is way too high to be managed with any traditional approach.

You can find here the main content of this speech: the Presentation slides and the video of the keynote as well as an short interview I gave the same day (unfortunately, the videos are in French).

Keynote introduction:

The most significant customer experience issues take place during a customer’s interactions with your company’s web site and contact center.  Negative experiences generate frustration and result in higher costs of support, while discouraging customers to adopt your company’s products/services, sometimes definitely.
We will exemplify how most of these issues are connected with maladapted access to the most critical information of your company and the lack of unification between the different communication channels and data sources.
We will present what are the critical aspects of these issues and how they can be solved by implementing an adapted Customer Experience Strategy.

We will explore how:

• Contextual Guidance solves the most critical search experience challenges
• Social Profiling and Personalization shorten and enrich the exploration experience
• Seamless intelligent escalations from the web to your contact center -  lower your costs of support and leverage the way customers interact with your company
• 1:1 Marketing Automation increase your sales and changes the way customers perceive your brand(s) and increase conversion rates significantly.

Video of the Keynote speech:

[Not yet released, will add it as soon as it is done]

Video of the Interview I did after:

Web site suppliers understood this problematic quite well, but didn’t find the solution. Instead, they use it to their benefits, leveraging it on one side to sell a new expensive version and requesting on the other side the necessary validations from the customer before the creation process is over (when there is still some euphoria of what they believe it will do for them), to make sure there are concrete proofs that the customer satisfaction was reached (as waiting until after the launch would be suicide).

In this post, I make the assumption that the problematic relies at the technology level as customers want their web site to be an attractive and efficient online engagement platform, while web site technology can only deliver an access to a set of fixed information segmented into information pages. As a result, the engagement would have to emerge magically out of the intelligence of the content of the pages, which, except in a few very specific situations, will never happen.

What if we could put in place a better technology which would make web sites more dynamic, not in their content, but in their structure?

What if the resulting flow of interaction was adapting automatically and if the content of the web site was the documentation along this flow?

Before explaining this approach, I would like to address a few key concepts:

Online Engagement

We define the process of online engagement as transforming visitors of the web site into customer prospects, meaning that they terminate their online interactions by manifesting their intent of becoming a customer. This intent can be converted immediately online, in the case of e-commerce, or through the contact with a sales agent. We call the transfer of the request from the online world to the offline world an “Escalation”.

Information Access

Accessing the information is a key aspect of engagement, as no visitors want to become a customer if they didn’t find anything interesting for them. The success of this critical phase of online engagement depends both on the content and on the technology used to provide the access to this content.

Online Qualification

We define the process of online qualification as the collection of customer data which are required to finalize the engagement process. There is no limit on to what type of information the qualification can be (e.g.: socio-demographic information, products of interests, etc.). Their gathering represents a key aspect of Online Engagement, as requesting too many data from customers can lower their interest to the point they are not willing to complete it anymore.

Interaction Flow

We define the Interaction Flow as the chain of interactions between the user and the web site. The interaction flow can be pictured as a succession of states the user has visited (traditionally HTML pages) connected by the selected transitions (traditionally URL links).

Contextualization

When considering the Context throughout the Interaction Flow of an Information Access process, the context is initially very large (the whole web site) and becomes very small along the way (to a very specific piece of information). We call the process of passing from a very large context to a very small one the Contextualization.

The concept of my new approach to online engagement relies on making all the ending points of the Contextualization process to become the points of Escalation (requiring no more, or very limited additional qualification). From this basis, monitoring the success of the web site as an online engagement platform can be simplified to the analysis the conversion rate of each point of escalation, as well as all the ending states of each unfinished Contextualization.

To make this concept possible in the reality, we need a technology which could generate the Contextualization automatically (e.g.: from both the company’s products meta-data and customer qualification requirements). As the only goal of the web site would become the Contextualization (bringing the user to the most relevant information, while gathering the required information about him), the structure would have to provide the supporting information for all the possible interaction states.

The required information would then be provided not as information pages as it is the case today, but as explanation around the different Contextualization steps.

Let me give an example to illustrate this approach:

Company A provides 9 products, which can be categorized in 3 domains sales,support,supply; and in 3 functions optimize,manage,analyse (i.e.: one product for each combination).

Let’s consider that the price (and difference of features) of the products depends on 2 factors: the customer size: big,medium,small; and the customer industry: bank,telco,IT.

Let’s consider that there is 5 information required to qualify a customer: name, position (CEO, CTO, others), industry, domain of interest (sales, support, supply) and e-mail

If we consider that the name and e-mail are the 2 only elements which should not be considered during the Contextualization, we can see we have 5 possible states for the interaction flow (domain, function, size, industry, position).

The approach would imply to create the required information to support all the possible Contextualization process cases.

As, in our example there is 3 possible values per attribute, we can see that the number of possible ending points of the Contextualization are 3^5 = 243 and the number of possible Contextualization processes (considering the first step dynamically selected as well as all the others) 5*3*4*3*3*3*2*3*1*3, or 5!*3^5 = 120*243 = 29′160.

We can immediately see that the possible dimensions of both of them are too big to prepare a specific textual information to support each. This challenge can be addressed if the information provided is either not static (e.g.: pricing information and ROI calculation depending of dynamic parameter), or the same in many cases (e.g.: the message to explain the pricing can be the same for a CEO looking to optimize support or the a CTO looking to manage supply, as, in the case explained above, the differentiating price factors are only the customer size and the industry).

However, when looking at the most popular Contextualization cases, the customer might be willing to differentiate the message at every state for his most important cases to receive the most personalized information possible.

In addition to provide a direct connection between the Information Access and the Escalation, this approach has the big advantage to provide a possible context for each piece of information a company wants to put on his web site: a context connected to the intent and the profile of the customer.

It is therefore more likely that the company will naturally provide engaging information which makes sense for the customer and his current context of mind and therefore will result in more engaging information in addition to a more engaging process.