Tag: recommendation engine

October 19, 2009   Posted by: John Maller

Four Times the Sales Transactions With the Same Head Count!

4x-sales

Products have so many choices. Customers hate the experience of having to answer 50 questions to get to selection. Asking them 50 questions translates to poor customer experience and it is actually bad for you too. Here is why. Every sale begins with a customer calling out the top 3 or 4 items they want in a product. I wish there were big blinking lights that could now say “Big Opportunity!” This moment is the biggest opportunity for you to recommend a product choice that meets his needs, while being good for you as well.

In ‘days of yore’, that is what a good salesman would do. He would look over his shoulder and see what he had in stock, and gently guide the customer to one of those products. But those were the days when products were fewer, choices were fewer, and sales guys could look over their shoulder and see what they had in stock. Gone are those days!  Today – sales is outsourced. It is one of the biggest and most critical functions’ that has been outsourced. Sales are done though dealerships, channels, etc. Even when a company has internal sales resources, the sales teams tend to be big or have heavy turn over. So – you have a newbie selling your product more often than not.

As product choices have continued to skyrocket, this poses a tremendous challenge on sales reps, sales channels and outside sales people. They lack the tools and automation to quickly hone in on customers’ needs and recommend product choices. The lack of these tools is causing tremendous challenges to sales people and customer. Here is a list of some of the outcomes:

  • Poor customer experience due to inability to recommend good product choices at point of sale .
  • Lost sale because customers do not like to answer endless questions to get to a product choice. More often than not – this is bad for the seller as well. Long list of questions result in random choice selections. This causes one-off products and poor product selection.
  • Longer sales cycle – Every sales rep will tell you that he wants to recommend a good product choice and close the sale. The faster you can recommend a product, the higher the conversion rate.

Today’s sales tools and CRM include contact management and pipeline management. We do not expect the sales reps to remember the names and contact information of their customers. But why do we expect them to memorize the product features and choices? Why do we take them through endless product training sessions, even as the products are changing?
CRM needs product selection information to enable a sales rep to close the deal. Jane Barrett, Research Director at AMR presented some of the benefits, in her presentation to an SAP user group in October 2009.

Here is a short list of the benefits of empowering sales reps with guided selling at point of sale –

  1. Sales cycle time drops dramatically, from days to instantaneous.
  2. Increase in profit (2% in one case) by continuous up selling and offering alternatives at point of sale
  3. Four times as many sales transactions can be handled with the same headcount. (400% sales productivity improvement!)

If you do not use product recommendation tools, your sales staff is working at 25% sales productivity. In affect, you have 4x the staff you need to do the same job

Call To Action – Please talk to your sales reps and channels on how they are currently selling your product and their current challenges. If they do not have automation and tools to recommend product selection, you have a significant opportunity for improvement. A potential opportunity to improve sales productivity by  400% !

Comments Off
September 24, 2009   Posted by: John Maller

Value of SKU Intelligence (What Are Customers Buying?)

One of the most frequent questions we are asked about Emcien’s methodology is “why hasn’t anyone done this before?” The answer seems obvious to us, but we should probably write it down once and for all so we can just point people to a definitive document.

Exploding SKU’s to attributes generates a LOT of data. It is only useful if this translates to actionable intelligence. As we all know, we don’t need more data. We need actionable items and recommendations to improve business. The simplest answer is that collecting all the attribute data for SKUs has not been done before, because the algorithms have not existed to farm intelligence from them. In this blog I am going to address –

  1. Why having the data with the SKU attributes is invaluable!
  2. What analytics capabilities are needed, if you have that data
  3. Value of having SKU Intelligence (To drive SKU velocity)

Consider a product that has attributes, and offers lots of variety, also called configurations. Almost all products come under that class today! Think car, computer, or cell phone. The product has features, and each feature has alternative options. For example, a car has an engine (V-6 or V-8), a body type (sedan or convertible), and a color (red, green, blue, black, or white). Any specific car has many choices for each of the features. Customers make choices on the features. Do you want the cloth seats or the leather seats? Do you want the DVD player? How about the iPod connector? Make a choice for about 30 features and you are done. This applies for shampoo, toothpaste, computers, light fixtures, consumer electronics, … all products that have attributes choices.

We consider a configurable product that has a large number of features, each of which many alternative choices/options. Notice that we have finessed the hierarchy problem by allowing only two levels: feature and option.  A customer will typically call out only a few attributes during a purchase. They expect you to know how you can complete that spec to fill the order. That is the single biggest opportunity at every point of sale!

If we have data with attributes for every SKU, we can begin to talk about buying patterns! A buying pattern is groups of options that are bought together, like the red color with the convertible body style. Or the DVD player with the leather seats. Or the pattern might involve 3 options, 4 options, 5 options…. many options.

cluster-screen

Auto detect most popular attributes in fastest sellers

This brings me to a very important point. If you have sales data with attributes, you need an analytics engine that will automatically detect and tell you what attributes are bought together and are highly popular. A reporting tool that makes you query every choice combination will NOT work! You will be very old by the time you get an answer to most popular choices, as there are millions of attribute combinations. Emcien offers an analytics engine with cluster analysis that will tell you what attribute groups are popular. This answers the questions – what are customers buying and what attributes are popular. This knowledge can also be used for planning the SKU definition and knowing what products need to be on the top landing pages of your web site/ store aisles. (SKU Definition is the list of attributes in the SKU.)

Once the SKU definition is in place, 75% of the cost structure and efficiency of your supply chain has been fixed ! Your supply chain operates under the assumption that the SKU definition is correct. What does this mean? This means that if you offer 2 SKUs with slightly different attributes, that could have been consolidated into one, the supply chain will suffer that cost and inefficiency. The SKU definition has to be optimized before you send it into the supply chain. This is a key driver to SKU inventory.

Customers buy products based on choices at the attribute level. If you cannot gather demand intelligence at the attribute level, you are out of touch with your customer. Customers DO NOT buy SKUs. They do not know the SKU numbers, and they do not care.

SKU Challenges Based on Supply Model

SKU Challenges Based on Supply Model

Your business falls into one of these categories based on your supply model (see table). Knowing what attributes customers are buying can dramatically improve your demand response. You will be able to improve -

  • SKU definition -This means knowing how many SKUs you need and what needs to be in the SKU
  • Demand Forecasting – You will be able to forecast demand at the attribute level, which is the level that customers are buying
  • SKU Inventory - plan what to stock to have highest turns.
  • Sales Productivity and Efficiency – If you know what attributes are selling together, you can implement an automated recommendation engine (EmcienMatch) and your sales rep can recommend a good choice to the customer during the ordering process. This is probably the single biggest value of knowing what attributes customers are buying. Your sales reps are a trusted advisor to your customers. If the sales person know that all customers of a certain type bough a particular configuration, he could recommend that choice to the customer. Win! Customer is happy because he done! Sales person is happy because he looks smart! You are happy because you increased your sales repeatability!

For our Nerdy Math readers, here is technical nugget that you will love:
SO – here is another reason why what Emcien does has not been done before. Statistics deals with numerically valued variables. A numerically valued random variable X has a domain that can be classified as a ratio scale, an interval scale, an ordinal scale, or a nominal scale. In a nominal scale, the numbers {0,1,2,3,…} are just labels and have no numerical significance. In an ordinal scale the numbers provide an ordering, so that 2>1 in some appropriate sense. An interval scale allows real numbers (like 3.27) and differences are significant, but ratios are not. The classic example is temperature. A difference of 10 degrees is bigger than a difference of 5 degrees, but 100 degrees is not twice as hot as 50 degrees. Finally, a ratio scale allows all of the usual numerical operations on real numbers. Most of statistics assumes a ratio scale, and almost all of it assumes at least an ordinal scale. This leads directly to the mean, variance, covariance, and correlation. It also leads to metric spaces with distance functions.

But we want to consider a random variable X that represents a choice between cloth seats and leather seats. You might argue that leather > cloth, because leather is more expensive. But what about color? Is there any sense in which green > red? We are really interested in nominal scales. We may assign 0, 1, and 2 to “none”, V-6, and V-8 respectively, but these are just labels. That has a profound effect on the statistics we can use. And beyond statistics, we will have to develop notions of proximity or closeness that do not depend on distance functions. So it hasn’t been done before because the mathematics you need is not the popular stuff that’s in the textbooks.

Comments Off
September 13, 2009   Posted by: John Maller

Part II: Analytics to Action….. The Holy Grail

can-you-have-too-much-information? Can-you-have-too-much-information?

… in my last blog we talked about reporting, BI and data mining, and ? the information overload. So how can help business users with solutions for better decision making, as opposed to drowning them in more data and pretty charts? That is the Holy Grail and the purpose of all this data!

Lets start by defining analytics. So, what is analytics? Neil Raden of Hired Brains, a market research and management-consulting firm, has said that, “the proper term for interacting with information at the speed of business, analyzing and discovering and following through with the appropriate action, is ‘analytics’. I agree. In the information age, this must be done by specialized applications built on analytics based on the requirements of the actions/recommendations required by a business function. Dumping data on a users lap with the message – “Figure it out!” is NOT analytics, and it not very useful either. (I am reproducing a picture I really like as it conveys the message so very well! The Picture is from mathewingram.com/work)

So – how can we transform the user experience for analytics? As mentioned earlier, this can only be accomplished by focusing the analytics on a business problem with the mission to deliver actionable tasks. The challenge is selecting a business problem that the analytics truly delivers unique capabilities and intelligence that is relevant to that problem. This level of focus can be perceived as very limiting, and hence many choose not to go this route. Why limit the scope of the analytics to one specialization, when we can claim that we can do everything! To that I say – you are better off doing one thing very well, as opposed to many with mediocrity at best.

I am going to bring this back to Emcien, as this is a company that has focused analytics on a very specific business problem. The problem is one of product variety, product variants, and lots of attribution. In this age of product variety, that is a problem that is causing tremendous challenges to various business functions.

The analytics automatically detects what features customers are buying, where you are making money. This SKU or configuration intelligence is leveraged for:

SKU Intelligence Analytics Used to Drive Application Specific Recommendation

SKU Intelligence Analytics Used to Drive Application Specific Recommendation

  1. Better forecasting at the mix level -  The application uses the analytics intelligence to determine the exact product mix with very high accuracy based on true demand sensing.
  2. Improving the customer experience at the point of sale - The application uses the analytics intelligence and guides the buyer to a good configuration based on the few features they have called out. And by the way – customers love it when you can recommend a configuration based on the few features they ask for.  They want you to stop asking more questions and recommend a good choice.

While the analytics may throw out volumes of data, the user can relax, as he does not have to crawl through volumes of date wondering what it is telling him. Converting analytics to actions and recommendations minimizes human interpretation and error on a day-to-day basis. For analytics to be functional in business applications, this is a mandatory  requirement in today’s business environment.

So – when you are evaluating BI tools, Analytics, Data mining….. what ever they are calling it! Ask yourself, how am I adding value to the company? What am I giving my business users? Am I adding more work to their busy schedule by piling on data on their computers???? If the answer is YES, please don’t do it. They will thank you for it.

If the data has not been converted to recommendations the business can act on, you will not get value from your investment!

September 8, 2009   Posted by: Roy Marsten

Recommendation engine for configurable products

The Amazon recommendation engine has received a lot of attention and imitation. It has been successful at increasing sales by pointing out that people who bought book x also bought book y. This simulates a helpful book store employee who has an extensive mental map of how books relate to each other. Recommendations have been most successful for books, movies, and music. Companies that sell complex configurable products could also benefit from a system of automated recommendations. Products like trucks, tractors, computers, lighting fixtures, valves, and industrial fans. These are products that the buyer can customize to his own preferences or needs. The buying process is complex, and sales agents make recommendations, just like the book store expert. But many of these products are far more complex than books.

How is a book different from a truck? Could a recommendation engine for books be used to recommend trucks? The purpose of this note is to consider the ways in which the two cases are similar and different, and to explore what a recommendation engine for configurable products might look like.

Books and trucks can both be described in terms of attributes (also called features or characteristics). Books can be described by their genre, author, language, and publication date for instance. Trucks can be described by their engine, transmission, wheelbase, gross vehicle weight, and many other attributes. Books, movies, and music can be classified in sufficient detail with ten or fewer attributes, while configurable products usually have a lot more. Heavy-duty trucks can have anywhere from 30 to 300 attributes. For books, the attributes are used to classify existing books. For configurable products, each attribute represents a choice for a customer who is ordering the product. Each attribute has several alternative options, so an order is really a list of option choices.

Amazon uses attributes to let customers search for a book, but the recommendation engine does not use them. The recommendation engine remembers each customer’s purchase history. For example, Joe has already bought “War and Peace” and “Crime and Punishment”. When he buys “The Sound and the Fury”, a connection is made between “The Sound and the Fury” and “War and Peace”, and another connection is made between “The Sound and the Fury” and “Crime and Punishment”. More accurately, the weights of these connections are increased. The connection between “The Sound and the Fury” and “War and Peace” depends on the number of customers that have bought both books. Commonality depends on common purchase by individual customers.

One big difference between books and trucks is that an individual will buy many books, but is unlikely to buy many trucks. So the basis for the connections between trucks can’t be the common purchases of individual buyers.

Another difference is that only books that have already been written are of interest. No customer is looking for a book that hasn’t been written yet, and you certainly can’t recommend one. But because of the very large number of choices, a buyer who is customizing a truck may arrive at a configuration that has never been built before. So our recommendation system must be able to accommodate trucks that don’t exist yet.

The helpful book store employee will jump from one book to another book that his customer might like. When we look at the helpful sales agent, he is doing something quite different. Based on the first, and usually most important, choices that the buyer makes, he will suggest ways of completing the order. The buyer may really only care about 10 of the 30 choices, and want guidance on what else to choose. The book store employee jumps from one complete item to another complete item. The sales agent is finding a path from a partial order to a complete order.

So we have an initial set of requirements for a recommendation engine for configurable products. It must help a buyer who has made some choices to make additional choices, so as to arrive at a complete order. From the seller’s point of view, we would want these recommendations to guide the buyer toward items that are advantageous. This might mean popular, in stock, and/or profitable. Its concept of the product (e.g. truck) must be broad enough to encompass configurations that have never been built before, and its concept of commonality must be based on something other than common purchases.

To show one way this might be done, consider a different way of making connections. When a customer buys a red truck with a V-8 engine, he is making a connection between red, a value of the Color attribute, and V-8, a value of the Engine attribute. So the customer’s vote is not recorded as a connection between two complete trucks, but as a connection between two attributes. More precisely, it is recorded as a connection between two values, or options, of the two attributes.

When a customer buys a truck with n attributes, we will record his “vote” n times, once for each of the options he has chosen. Then we will also record it nC2 more times for each pair of options. The symbol nC2 stands for the number of different pairs of attributes there are, and can be computed as n*(n-1)/2. For example 10C2=45. The relative popularity of the different pairs of options (like red and V-8) tells us something about how customers are buying the product, and gives us a different basis for making recommendations. (If you want pineapple on your pizza, you probably want Canadian bacon.)

If pairs of options are interesting, then so are triples of options. The same customer vote can be recorded for nC3 different sets of three options (10C3=120). Every option of every attribute has its own popularity (i.e. number of votes). Expressed as a fraction of total units sold it is known as a first-order take rate. Every pair of options also has a popularity, and as a fraction is defined as a second-order take rate. Similarly, each triple has a third-order take rate. Of course we can also define fourth, fifth, and higher-order take rates.

If customer purchases (votes) are recorded in this way, then we will have captured the buying patterns in the form of first, second, third, and higher-order take rates. A new customer who begins to select the options that are important to him will trigger these patterns, which will then serve as the basis for recommending a complete truck. So we see that two complete trucks may be related because they both contain instances of the same fifth-order take rate. This can be true even if neither truck has ever been built before.

We conclude that a recommendation engine for configurable products could be built by mapping customer purchases into a structure of take rates that record the relative popularity of options, pairs of options, triples of options, and so forth.

Comments Off
August 23, 2009   Posted by: John Maller

Recommendation Engine To Empower Sales Process

There exists a great opportunity for companies to streamline their front end and specifically the quote to cash processes which will deliver immediate relief from the current economic reality. Emcien provides a “Recommendation Engine” for configurable products, empowering the sales process.  In spite of tremendous technology advances, we see a selling process within companies that is very archaic, people intensive and time consuming. It involves sales people, sales engineers, quotes managers, configuration specialist, ……..

My favorite quote, also a dismal statistic, is from a Sales VP – “4 out of 5 quotes are lost because we cannot serve up the right stuff immediately at the point of sale“.

My second favorite quote is from a customer who was trying to buy a drive from a very well known company.  “I am still waiting for a quote, so they don’t have my cash”, he said.

Why? Because after he gave them his requirements, they left and caucused, came back and asked more questions, caucused more…. 2 weeks later, he still did not have a quote. “Why is so complex” he asked.  ”Because we have only one process”, he was told.

A Director at a lighting fixtures company told me that “EVERY customer request had to be touched by his staff” before they could issue a quote. 80% of the stuff ordered was repeat stuff, or close to repeat.  Wouldn’t it be a lot more efficient for him (and the customer) to treat it that way!   “We have only one process”, he said.

With Frank Hecker’s permission, I am republishing his article – “What Sales Engineers do”.  It explains roles in the quote-to-order process that date back to World War II.  In today’s economic environment, we cannot afford the luxury of so many roles and so much complexity for every unit we sell.  We need to manage the 80% repeat sales in an efficient way, and leave the complexity for one-offs and custom builds.   Companies that offer technical products have a quote-to-cash process that is completely outdated, very expensive and is a big opportunity for financial gain.   Here is Frank’s article -

What “Sales Engineers” Do

“Sales engineer” (sometimes known as “systems engineer”, or “SE” for short) is one of those unique professions made possible by specialization of labor in an advanced post-industrial economy. Simply put, SEs apply their technical expertise in support of the sale of complex technological products, typically computer hardware, software, and/or services.

Note that even though many companies use the term “systems engineer” to describe this function (and I myself used the term in earlier versions of this text), what I’m describing here has very little to do with the formal discipline of systems engineering that arose after World War II out of the Bell System and large Cold War military/industrial projects like SAGE and Atlas. (For more on this see the book Rescuing Prometheus by Thomas P. Hughes.)

I haven’t done any detailed research on this, but I suspect that the use of the term “systems engineer” to describe a sales support position originated with IBM, probably within the sales teams devoted to serving large military and aerospace customers. With the advent of computers to replace and supplement products like card sorters (the original “business machines” in IBM’s corporate name) the products being sold became so complex that the typical salesperson was unable to fully understand and explain them. (As the old joke goes, “What’s the difference between a computer salesman and a used-car salesman? Answer: The used-car salesman knows when he’s lying.”)

Hence the need arose for sales teams to include technically knowledgeable people who could assist the actual salespeople, particularly in complex tasks like creating proposed system configurations to meet particular customer requirements. I suspect that the term “systems engineer” was adopted for such individuals both because this work was done within the context of engineering the complete systems of which the computers formed a major part, and also because calling them “engineers” was seen as giving them greater prestige and credibility in the customers’ eyes.

If the use of “systems engineer” in a sales context did in fact originate at IBM, I’m guessing that it then spread from IBM to other computer hardware and software companies. (Many sales VPs at high-tech companies got their start as IBM sales reps.) At some companies the SE function was renamed to something else — “marketing support analyst”, “sales technical support consultant”, “sales support analyst”, “sales engineer”, and so on — but the nature of the position itself remained essentially the same.

SEs perform the following activities in support of the sales process:

  • soliciting technical requirements from customers
  • giving presentations on and demonstrations of products
  • providing informal advice on what products might fufill the customer’s needs
  • writing more formal documents such as proposals and targetted white papers
  • serving as a point of contact for non-routine technical issues at major accounts
  • assisting salespeople with the creation and execution of an overall sales strategy for an account

Some of the things that systems engineers do not typically do (except when there’s no one else to do them!) include

  • selling products
  • providing routine post-sales product support
  • developing products
  • providing consulting services for system design and integration

These functions are performed by other people and groups, namely sales representatives, technical support people, engineers/developers, and professional services consultants respectively.

The principal qualifications for being a systems engineer are technical knowledge in the appropriate domain(s), verbal and written communications skills, and the ability and desire to work closely with salespeople. Having these qualities combined in a balanced way in a single person is relatively rare; in particular, most people with technical knowledge prefer to be engineers and developers, and most people interested in sales prefer to be sales representatives. This leaves people like me to soldier on as best we can.

Frank Hecker

Frank Hecker

About the Author: Frank Hecker is Director of Grants and Programs with the Mozilla Foundation, a nonprofit organization promoting choice and innovation on the Internet through its support of the Mozilla project and related initiatives. Prior to joining the Mozilla Foundation full-time Frank was a sales engineer with Opsware Inc, supporting sales of Opsware IT automation software and services to the Federal government. He has also worked for CollabNet, supporting sales of CollabNet services relating to open-source and other collaborative software development, and for Netscape Communications Corporation and America Online, Inc., as Director of Systems Engineering for the Netscape government sales group in Bethesda, Maryland. At Netscape he was sales technical lead for the Netscape/DoD worldwide site license, the FORTEZZA, FIPS 140-1, and Netscape Security Services projects, and many other sales activities; he was also a key contributor to Netscape’s decision to release source code for the Netscape browser, and was appointed one of three Netscape Fellows. His professional interests include the technical, business, and public policy aspects of open-source software, information systems security, assistive technologies, and online education. He was the winner of the 2009 Catalyst Award for his work in promoting open source accessibility, and was named one of Washingtonian Magazine’s top 100 leaders of Washington’s tech world. He blogs at <http://blog.hecker.org/>

Comments Off
June 9, 2009   Posted by: Loraine Fick

Q&A with John Sloan, former director, Jeep Brand Global Product Marketing

carsindollarsignIn today’s post, John Sloan talks about challenges dealers face in ordering inventory that best matches customer demand.

Emcien: Describe the Chrysler-Emcien initiative that examined dealers’ struggles with complexity in the ordering process.

JS: In a soft “push” market where volume is driven by heavy incentives versus the merits of the brand / model, managing cost is paramount. A key piece to focus on is product inventory. Dealers get roughly 60 days of no-interest floor plan. In a soft market, vehicles can easily sit for longer than two months before being sold, so it’s critical that vehicles be easy to order, stock and sell. Simple is better.

Emcien worked on a model to simplify the Chrysler PT Cruiser product mix. There were thousands of possible build configurations for the PT Cruiser, creating significant complexity for engineering and the assembly plant, as well as the supplier extended enterprise. Emcien’s ability to accurately forecast demand is invaluable for a complicated product line because it can assist with reducing the build configurations to those that best match demand. The PT Cruiser initiative validated the power of the Emcien inventory model.

continue reading »

May 25, 2009   Posted by: Radhika Subramanian

Arm your salespeople to make the sale

key2successI was talking to an executive at Oracle, and he told me that CRM is entering a new phase. Salespeople are the revenue generators of a company. Current CRM tools have served the purpose of helping salespeople organize their customers’ contacts and manage the sales process and pipeline, but this isn’t enough.

Your salespeople are representing and selling your product. Customers who want to buy your product typically list a few things they want and look to the salesperson to guide them. The salesperson is their advisor on your product offering. The salesperson is expected to know the product and suggest good choices for the customer. Is your salesperson equipped to do that?

There was a time when life was simpler and products were simpler. The customer said, “I want a 17″ TV.” The salesperson could look at what he had stocked and reply, “I have a 19″ I can give you for the same price.” Wow! Done!

Today, even the best salespeople don’t stay at one job for long. They move, selling what sells. Training sales newbies on a product is a big challenge for companies, and the cost of the salesperson not knowing the product he’s selling is VERY HIGH. As many as four out of five quotes are lost because customers weren’t guided to a good product selection. You can fill this gap by arming your salespeople with tools and product knowledge that will help them advise customers effectively on your product. Your company needs salespeople to have that capability so you can make money on the stuff they sell!

Comments Off
April 29, 2009   Posted by: Russ Caldwell

Stop product complexity at the door

In any manufacturing company that builds configurable products, there is a lot of discussion around what product complexity is. What’s interesting is that when times are good and there are lots of sales, the discussion is usually around how to simplify or streamline with the goal to sell more product even faster, that complexity is keeping sales from going even higher. In bad times, the discussion typically moves to how complexity is causing undue stress on the supply chain, creating problems with parts forecasting, quality and finished goods inventory.

Rarely do these discussions end with participants really agreeing about exactly what complexity is or how to reduce it. Solutions are attempted with internal projects like SKU reduction and part number reduction initiatives driven by Six Sigma teams that mean well and do good work, but usually are chasing the tail of the complexity dog, rather than leashing it for good and guiding it to higher profits, lower forecasting errors, even shorter sales cycles.

continue reading »

Comments Off