Support Experience Management

For the past couple of weeks, we’ve been having an issue with our home wifi router crashing every few days. It wasn’t annoying enough to deal with because a quick reboot cleared things up and everything went back to normal for a while. Last night things came to a head when the kid’s 100th streaming of The Lego Movie repeatedly *gasp* dropped out.

I set off to fix this issue “once and for all” and immediately spent about an hour searching the internet for a solution. Quickly I made my way through a handful of banal and generic FAQs, all of the stale support site content I could digest and ultimately found myself elbow deep in the morass of dense community forums. After spending too much time paging through all of the “me too” responses and “close but no cigar” solutions, I finally gave in and called tech support to resolve my issues.

The call was a fairly typical one and as an experienced support adventurer, I deftly made my way through the 9 levels of IVR hell. Avoiding the dead ends, infinite loops and pitfalls designed to trip me up and send me back to the web at every turn. As a reward for my bravery and agility, I was granted a 15 minute wait on hold with some killer 80s synth pop which is clearly intended to melt my brain and make me forget why I was calling in the first place.

Once I finally reached an agent, I was exhausted, only to find that I needed to retrace ALL OF THE STEPS I went through online for the agent. My support journey, to this point, was completely stateless and the agent had to repeat many of the same steps to try and resolve my issue. At about 90 minutes into our journey, I say our journey because we’re both in it to win it at this point, we finally had a breakthrough and roughly 15 minutes later we had rolled back the firmware that had caused my problem. Bam! Problem solved.

Improving The Support Journey

My recent experience is emblematic of problems that exist across the support ecosystem and affect companies of all sizes. Don’t get me wrong, at ANSWR, we love tech support agents but also realize that the entire support journey can be a broken and fractured experience for both the consumer and the agent. This void, at the intersection of support and customer experience, is what drove us to create ANSWR.

By empowering consumers to help themselves and enabling better agent support through data, we can bridge the gaps in the support journey together. By making the support journey stateful and automating improvements to the process, we break down the barriers that create a stressful experience. By focusing on reducing customer support effort we increase customer and agent success.

These are the things that we are passionate about and drive us to improve the support journey everyday. Not just for the consumers but for the agents as well.




Learn more about how ANSWR or keep up with us on Twitter and LinkedIn.

Support Experience Management

The End of Average


“In all affairs it’s a healthy thing now and then to hang a question mark on the things you have long taken for granted. “ -Bertrand Russell

We are living in an “Age of Average” when it comes to Knowledge

Watching a Ted Talk by Harvard Professor Todd Rose on the “Myth of Average” got me thinking about knowledge in the support industry and how historically content and information sharing have taken a “just good enough” posture. It seems backwards to spend hundreds of hours on creating, differentiating, and advancing our technology platforms that then get supported with one-size-fits-all knowledge processes and solutions. Does designing knowledge for the masses end up helping no one?

Professor Rose discusses how in designing for average we end up creating solutions that no one can use, because frankly, none of us are average. Individuals use and comprehend technology in a myriad of ways and at ANSWR we believe that our technology support teams need unique solutions that help them find, share, and create knowledge that embraces the individual.

At ANSWR we say – Ban the Average!

Seriously, no one likes to be called average…or, frankly, get average service. Yet, for some reason we seem to be okay living in the “Age of Average” when it comes to finding and sharing knowledge. So if today’s knowledgebases are average, i.e., doing just enough, just the basics, we are missing an opportunity to, (as Todd Rose points out) innovate for the edges, or embrace the individual and make their support experience exceptional, not average.

Join the Knowledge Revolution! Bespoke Knowledge?

At ANSWR we think that average knowledge is well…to put it bluntly, blah. In today’s world we look to individualize everything – “bespoke our lives” as it were. From how we dress, to how we travel, even the tools, or vacations we take. We demand individualization and personalization when it comes to all aspects of our lives; so why do we accept different standards when it comes to how we search, share and create knowledge? The ANSWR platform was specifically designed to allow teams to create individual collections of knowledge that make sense to them and how they best support their customers. ANSWR lets you treat your customers as individuals, retrieving content that makes sense for their technology challenges in real time with solution sharing between support teams. You can personalize the content you use, the searches you execute, and the steps you take so they make sense for the issue you are solving. If we can bespoke our suits, our bikes, or even our investment portfolios, why can’t we bespoke our knowledge base?


Learn more about how ANSWR can help you curate smarter and share better with your team.

Keep up with us on Twitter and LinkedIn.


The End of Average

Python Pipelines for Sentiment Analysis

How many times have you written boilerplate code that transforms your data for input into an algorithm? Or maybe you are doing preliminary testing on multiple types of models to test their performance. Python’s scikit-learn offers an easy way to set up work-flows through their Pipeline interface, which can greatly simplify data transformation and model set up. Let’s take a look at some data and see how this can be implemented in practice.

Sentiment Data


In there era of social media and brand reputation management, knowing the sentiment of your user base relative to your product is vitally important. Do you have insight into how much people approve of your product? Kaggle hosts data science competitions and is a great place to pick up new data for all sorts of problem domains and today we will take at the Rotten Tomatoes dataset which we will use to create some models to predict user sentiment. This data is comprised of phrases from movie reviews that are labeled on a scale ranging from zero to four where zero indicates a negative review and four indicates a positive review. For your own projects you can either get publicly available data like this to train on or you can use manually labeled data, like Tweets, specific to your particular product. The benefit of using your own data is that the vocabulary will be more specific to your problem domain. On the other hand, you will need to invest time manually labeling the sentiment your data.

We first need to load our data, so here is a helper function so that we can start training.

import numpy as np

from sklearn import cross_validation
from sklearn import random_projection
from sklearn.decomposition import TruncatedSVD
from sklearn.ensemble import VotingClassifier
from sklearn.feature_extraction.text import CountVectorizer, TfidfTransformer
from sklearn.linear_model import LogisticRegression
from sklearn.pipeline import Pipeline

def load_data(coarse=True, shuffle=True):
    x = []
    y = []
    for record in open('./data/train.tsv'):
        atoms = record.split('\t')
        sentiment = atoms[3][:-1]
        # skip header
        if sentiment == 'Sentiment': continue
        sentiment = int(sentiment)
        pos = sentiment
        if coarse:
            if sentiment == 2: continue
            pos = int(sentiment > 2)
        if shuffle:
            perm = np.random.permutation(range(len(y)))
            x, y = ((np.array(x)[perm]).tolist(), (np.array(y)[perm]).tolist())
    return x, y

This simply returns a tuple of training data and its associated class label, i.e. it’s sentiment. The coarse parameter will be explained later.


The input into our model is raw text. We will be using a logistic regression to classify each phrase, but logistic regression requires that inputs be numeric and not text. We run the data through two transformations, CountVectorizer and TfidfTransformer in order to accommodate for this. The former provides word counts for each phrase and the latter is a transformation of the word counts to penalize very common words, giving more priority to “content” words.

x, y = load_data(coarse=False)

count_vectorizer = CountVectorizer()
tfidf = TfidfTransformer()
logistic_regression = LogisticRegression()

model = Pipeline([('counts', count_vectorizer),
                  ('tfidf', tfidf),
                  ('regression', logistic_regression), ])

scores = cross_validation.cross_val_score(model, x, y, cv=5, scoring='accuracy')
print('Accuracy: %0.2f' % (scores.mean()))

# Accuracy: 0.63

Accuracy is 63%. On the surface of it, that does not sound that good. Looking into the Kaggle forums for this competition it looks like a reasonable baseline is around 61% and many people initially get around 56%. Given that we used all of the default settings for the models and the only preprocessing was to lowercase the data, 63% is not that bad. Random guessing would give an accuracy of 20%. This is granular scale, however. We may have classified the review as a 4 instead of a 3. Both are on the positive side of the scale so the accuracy may look a little worse than it is. A common thing to do is to remove the neutral reviews and categorize the remaining either as positive or negative sentiment. This is what the coarse parameter does on the data load. Let’s see what that looks like.

x, y = load_data(coarse=True)

count_vectorizer = CountVectorizer(lowercase=True)
rp = random_projection.SparseRandomProjection(random_state=11)
svd = TruncatedSVD(n_components=2500)
tfidf = TfidfTransformer()
logistic_regression = LogisticRegression()

model1 = Pipeline([('counts', count_vectorizer),
                   ('rand_proj', rp),
                   ('logistic', logistic_regression), ])
model2 = Pipeline([('counts', count_vectorizer),
                   ('svd', svd),
                   ('regression', logistic_regression), ])
model3 = Pipeline([('counts', count_vectorizer),
                   ('tfidf', tfidf),
                   ('regression', logistic_regression), ])

vc = VotingClassifier(estimators=[('model1', model1), ('model2', model2), ('model3', model3)], 

for clf, label in zip([model1, model2, model3, vc], 
                      ['model1_random_projections', 'model2_svd', 'model3_tfidf', 'ensemble']):
    scores = cross_validation.cross_val_score(clf, x, y, cv=2, scoring='accuracy')
    print("Accuracy %s: %0.2f" % (label, scores.mean()))

# Accuracy model1_random_projections: 0.85
# Accuracy model2_svd: 0.81
# Accuracy model3_tfidf: 0.86
# Accuracy ensemble: 0.85

What is going on here? We loaded the data and trained on binary positive/negative output classes. We then set up a series of models utilizing different data transformations: random projections, singular value decomposition (SVD), and term frequency-inverse document frequency (TF-IDF). The first two models utilize dimensionality reduction techniques. The third uses TF-IDF, which was used in first, granular model. The last output here is an ensemble (mixture) of all three models where we use a max vote for the classification. Ensembles are typically used for averaging different types of models. For this ensemble we used the same model but leveraged different data transformations. It is more common that ensembles used a mixture of different types of models (see possible alternatives in the next section), but both paths are worth exploring. It is interesting to note that the model with the highest accuracy is the TF-IDF model. Many times it is well worth doing simple things first and than trying more complex transformations. The accuracy of the model is around 85%, given further tweaking of the model parameters and data preprocessing we could probably get another 5% increase.


As stated, we used many of the default parameters of the models. Here are a few things you could try on your own to further increase the accuracy.

  • document preprocessing
    • bi-grams
    • tokenizing
    • stop word removal
    • stemming
  • try different dimensionality reductions for SVD and random projections, i.e. reduce to a k-dimensional dataset
  • optimizing the parameters of the logistic regression, e.g. regularization and solvers
  • try different ensemble methods provided by scikit-learn
  • try other models other than logistic regression, e.g. Naive Bayes or Support Vector Machines


We took a look at Pipelines in scikit-learn and how these can be used to assemble models. We took two views in the data classification, granular and coarse, and fit a few different models. The motivation was to simplify boilerplate code and to afford the opportunity to easily swap out different models. We also took a look at simple ensembles and how these could be used in your work.


Python Pipelines for Sentiment Analysis

The ANSWR for technical debt


It’s officially safe to say, we live in a Post-Agile World. Though we fully realize that software developers will likely read that with a shrug because (a) most of us have been shipping software in real-time for years and (b) we really don’t have time to argue because there’s another release coming up.

Continuous development gives companies the option to release code every week, or even every day. And while this capability has given rise to some amazing technology advances, it also has some unintended consequences. The concept of the Minimum Viable Product has led to build-as-you-go-development, where we work to make solutions that are just (and only just) as thorough as possible.

In fact, today, MVP should probably stand for Most Viable Product. We run fast and push functionality first, spec’ing and planning on the fly, cutting corners where we can and architecting as we go. We’re all building planes as we land them.

But, in fact, what we’re flying is often just a pile of technical debt.

Look, we’re not judging. We’re right there with you. When it comes down to building it well or building it fast, fast will pretty much always win. Great programmers know when to cut corners—clicking over to GitHub or Stack Overflow to hunt for best practices that we can build upon to keep things moving. Or Googling code snippets that worked well in the past and can be easily modified for your current project.Hunting through chat streams and email to find solutions to problems that have already been solved.

And, along the way, the technical debt mounts. Code suddenly isn’t so elegant anymore. It works…but will it scale? The plane landed…but how many more flights can we make?

Now ask yourself a different question: what if you could buy some time to go back once in a while and fix your technical debt? Or be able to fully understand the code you’re using in order to make the next release work that much better?

That’s where we think ANSWR can help. ANSWR is an instant short cut for search. It’s an elegant way to tag, catalog and annotate your searches on the fly. So let’s say you’re searching Stack Overflow and you find the answer you’re looking for. With ANSWR, you can tag it in your parlance, comment on how you used it—and let others know how you modified it to make it work for you.

Best of all, ANSWR is a simple Chrome extension, so it becomes native to your Google search. (We even have an ANSWR Bot in beta for HipChat, and more on the way.)

It saves you time. It saves your teammates time. And the more time you save, the more you can focus on making your code great. Or…okay, who are we kidding…the more time you can spend releasing even more than before. <sigh>

So give ANSWR a try. Because, chances are, your next plane has been cleared to land and you’ve probably got a lot of building left to do.



Learn more about how ANSWR can help you curate smarter and share better with your team.

Keep up with us on Twitter and LinkedIn.

The ANSWR for technical debt

Eating Our Own Dog Food


The development team at ANSWR is a small group still – we all sit in one room at our offices in downtown Boston. On any given day we can be overheard working through requirements, debating the value of new features, helping each other solve problems and answering each other’s questions about why certain code works the way it does during code reviews. Of course, that’s when we’re not arguing over where to find the best burritos (Villa Mexico) or coffee (Gracenote) near South Station.

A few months ago, throughout all of those conversations and the many hours of collaboration – whether in person or over HipChat – we started to see a pattern of the same or similar questions reappearing multiple times. Problems that one developer had solved weren’t getting filtered efficiently to other developers, questions were just getting asked to and answered by the same person who had figured it out the first time, over and over again. It was becoming an anchor on the productivity of the whole team and wasting hours per week that as small group, we didn’t have the luxury of.

The thing was that each of us had all spent a shitload of time using our own software – we installed it, uninstalled it, ran searches, tagged and annotated thousands of pieces of content during development but we never, as a team, USED our software as we expected other teams to. We were so focused on building the best product possible for our customers that we lost sight of why we started ANSWR in the first place: to make knowledge creation, sharing and recall easier for all types of teams.

That’s when we decided to eat our own dog food, for real – and it really worked.

We cleared out the old test data, set up a fresh new team, added all of the developers to it and started using our Chrome extension to tag “real” content that the team was finding helpful, wanted to share with others or just remember for themselves. Over the past few months, we’ve curated hundreds of pieces of useful content found during Google search sessions and teased out of Confluence on wide ranging topics as diverse as debugging memory leaks in Ruby applications to writing obscure SQL aggregations for Redshift to cleaning the dust of out our laptops.

All of this newly curated content is being shared by the team every day though our HipChat Bot and at the top of our Google searches and we’re now seeing real benefits.

We’ve seen a remarkable uptick to the teams productivity by shaving off those repetitive search hours we were previously wasting – freeing us up to push through our debt and feature backlogs more efficiently.

We’re also collaborating better and more transparently because we are sharing more and more frequently about what everyone is working on and searching for.

And the best result of eating our own dog food (and why you should too) has been discovering new features that, as users, we want to see on the platform that we may not have thought about or prioritized as highly before. Hashtag searches from the Chrome omnibox anyone?

Screen Shot 2016-06-29 at 10.59.07 AM



Learn more about how ANSWR can help you curate smarter and share better with your team.

Keep up with us on Twitter and LinkedIn.


Eating Our Own Dog Food

If you’re searching, you’re probably shaving the yak.


The more you code, the more you search. It’s just a fact of life. There’s no way any programmer has time to write every line of code herself, so all we hit the Google bar and begin hunting for the code we need to get the job done a bit quicker.

But quicker isn’t always…well, quicker. One search often leads to another which leads to a chat board that leads to a threaded discussion and so forth and so on and pretty soon you’re shaving a yak trying to figure out where the last 60 minutes of your life went.

Hold on…doing what? Yak shaving is one of those terms that, on the surface, makes no sense whatsoever. But it conjures such a bizarre image that, once you understand its meaning, you’ll recognize it just about everywhere you go.

How does one shave a yak?

One of the most cited definitions comes from The Jargon File, courtesy of Eric S. Raymond:

Yak shaving is…any seemingly pointless activity which is actually necessary to solve a problem which solves a problem which, several levels of recursion later, solves the real problem you’re working on.

The entry refers to what may be the seminal definition by Carlin J. Vieri, Ph.D., described in an email from Jeremy H. Brown to his colleagues in the MIT Artificial Intelligence Lab back in 2000.

Yak shaving is what you are doing when you’re doing some stupid, fiddly little task that bears no obvious relationship to what you’re supposed to be working on, but yet a chain of twelve causal relations links what you’re doing to the original meta-task.

The term has been propagated by two blogs, one by Seth Godin and one by Joi Ito, who notes that yak shaving can have some positive effects. But the definition seems to ultimately go back to an episode of Ren & Stimpy. Adam Katz, another alumnus of the MIT AI Lab, wrote:

Though not a regular viewer of Ren and Stimpy, I did see the ‘Yak Shaving Day’ episode and thought it bizarre enough to be the end of a long chain of tasks.”

And then writer Alexandra Samuel offered another bit of etymology on her blog, which effectively boils down to that time of year, every year, when Tibetan villagers realize that their rice harvest could have been be made easier if they shaved their yaks to facilitate rice-paddy bridge crossings.

But if you really want to see what yak shaving is, check out this perfect illustration from an episode of Malcolm in the Middle.

And…there you go. I’m officially shaving the yak about shaving the yak. For programmers, the idea of getting caught up in meta-tasks is all too common. But the very act of realizing you’re doing something just may be the key to salvation.

Finding another ways – or maybe a better razor

In his blog, “Don’t shave that yak – God loves lazy programmers,” Pete Warden noted,

“I swear that the biggest reason I’m a more effective programmer now than when I was 20 is that I’m better at spotting when I’m shaving a yak, and finding another way.”

Like Pete, we found a better way and it became the basis of ANSWR, an elegant Google plug-in that helps you tag, annotate and instantly share your searches. Look, here’s our ANSWR results for yak shaving stories.

Screen Shot 2016-06-16 at 10.54.22 AM

Best of all, friends don’t let friends shave the yak either. Because when your team uses ANSWR, it becomes a instant collaboration platform. One tagged search means others can see what you found useful, comment on it, improve it, or add to it…which helps everyone work more efficiently. And ultimately, that’s what coding should be all about.



Learn more about how ANSWR can help you curate smarter and share better with your team.

Keep up with us on Twitter and LinkedIn.


If you’re searching, you’re probably shaving the yak.

Support Superheroes Work Better Together


I started my career in call centers in the early 90’s and have seen and heard it all… the manual processes, the revolving door, the irate customers and the team members who just can’t bear one more screaming customer. This is one of the toughest jobs on the market today and while I’ve been out of the call center space in a direct role for many years, every time I visit one I fall back in love with the energy, the team atmosphere and the constant buzz of support superheroes just getting it done. Yes, these things exist… and no, I have not been “drinking the Kool-Aid”.

As ANSWR’s Head of Customer Success, I recently had the opportunity to visit one of our customers during their call-center launch to see, first hand, the excitement of rolling out a cool new platform that fits into their teams existing workflow. Being onsite gives us a chance to see our product in action, sit with the team, observe their workflow, understand how we FIT into THEIR process and avoid the mistake of assuming they will fit into ours. During this visit, we launched, we talked, and we had some fun. Then we sit back, watch, learn and react.

This team of support heroes has curated over a 1k pieces of knowledge in a short time, making them immediately available for their team members and driving tangible results to their key efficiency metrics. Together, we identified a few ways that an enhancement on our side could improve their flow. These are the proverbial win/wins that we all seek to achieve.

You’re probably wondering, “Is an onsite visit necessary in the age of Skype, Hangouts, WebEx, etc.?” The answer is no, sometimes it’s not necessary or possible for us to be physically on site in every center for every launch. In those cases, we leverage technology to be virtually on site with video conferencing and real-time collaboration tools. We recently launched a customer in 5 locations across 4 countries and it went very smoothly. Although a trip to Mexico and the Philippines would have been great as well as a few   checkmarks on my traveling bucket list!  (my suitcase will stay by the door)

Regardless of whether we’re onsite in person or virtually, the most important thing to the team at ANSWR is ensuring our customers are successful and that our products are helping them maximize their support superpowers. It’s the only way to ensure that we succeed together.

Clearly I get excited talking about call center dynamics and how we help make one of the toughest jobs a bit easier. I guess I haven’t flown too far from the call center nest after all.

We don’t receive wisdom; we must discover it for ourselves after a journey that no-one  can take for us or spare us. – Jesse James Garrett


Learn more about how ANSWR can help you curate smarter and share better with your team.

Keep up with us on Twitter and LinkedIn.

Support Superheroes Work Better Together