XY Problem

I’ve been recently re-introduced to the XY Problem, I’m pretty sure it’s been discussed in the Support Driven Slack room in the past too.

The basic gist is this: Many times people ask questions for the solution to their problem (Y) while their problem is actually (X).

The XY Problem site is extremely condescending towards the question asker and not a great way to handle someone asking questions for help.

I find thinking about it has been better for to learn how to ask better questions and realize when I’m falling into a trap of not asking the questions of the problems that I’m running into.

It’s also a good way to rethink how a feature is handled if you find customers asking those types of questions on a specific feature all the time.

Ticket Mountain

This month has been a fun one for us at our support desk with bookends of major events at the beginning and end.

If you remember at the beginning of the month we helped launch new company websites. That was all hands on deck while we made sure to keep everything working smoothly for our customers.

To end the month a customer that was On Premise (We let bigger customers host our software themselves) had major server performance issues that caused them to move to our Hosted service on the fly.. Meaning moving databases, an figuring our their AD FS integration, moving miscellaneous server files and oh yeah new URLs for every end user to access the application through. It was crazy…

To illustrate that here’s our incoming ticket volume for the month, you’ll notice the ascent starts on Oct. 22nd.

Screen Shot 2015-10-30 at 9.44.18 AM.png

The volume of tickets ends up even being less than the actual amount in the graph as well. We had a conference line setup where we went from end user to end user resolving their discovered problems.

Here’s to a nice long extended Thanksgiving lull next month.


Comfort Zone

There’s a new festival coming to where I live, the whole purpose is stepping out of your comfort zone and maybe even not liking a session.

It’s made realize the internet is a place that’s more an more being tailored to your “interests”. Be it following the football game you’re watching on Twitter which makes you think the entire internet is watching the game or Spotify recommending music based on the music you’ve previously listened to. The internet is quickly becoming a feed of services dedicated to me and my interests.

It makes me see the value in stepping out of my comfort zone. Not always listening to what I like, watching a movie I normally wouldn’t like, or learning about about something I wouldn’t seek out.

Now excuse me as I go follow some people Twitter has recommended to me…

After I wrote this I realized there’s a great correlation to support with stepping out of your comfort zone.

When you work in an application day in and out a simple question can seem mundane to you or maybe even annoying to yourself, the service your supporting is your comfort zone. It’s always imporantant to take a step back and realize a customer isn’t living 40+ hours in your service a week. While a question might seem mundane always understand the customer is asking you because they don’t know the answer.

There will be a better day

There’s an uneasy fact about support: We’re here for when things go wrong.

On most days it’s for how-to’s or maybe a billing issue. But there’s a reason why awesome support blogs publish great articles like How to Handle the 7 Toughest Customer Support Challenges.

I don’t have a great post for today, but just the advice that there will be a better day. It’s hard to see when all is going wrong. It might take a rough day or two, but in the end you’ll resolve issues, concerns will be taken care of and at the end there will be a be a better day.

– Sent from someone who had a rough Thursday / Friday

Future of Support

Where are we going in support? What is being done to craft better customer experiences outside of faster response times? One of the biggest jumps we’ve made is easy to put together self service sites to cut down on the “easily” answerable support / how-to questions a customer might have.

But what about that error that isn’t easily reproducible? Those errors might look like:

Null object reference not found

The customer has no idea what they did to cause the error, and without a reproduce the logs might not be clear to engineering what the cause is. It might only happen a couple times a week, it’s an annoyance, but not happening enough to assign a developer to dig deep into it.

I went to an engineering talk yesterday that discussed how a local company sped up the prototype process from weeks to a few days for new features they wanted to put in front a customer to get feedback on by being able to easily modify the View and State of an app. In this specific case it was an angularjs app the company develops.

This talk gave me ideas on how an app if from the beginning architecture level was built with support in mind could allow those small nagging issues to be resolved quicker than ever.

The basic jist is this – An app goes from State > View > DOM. Using a house as an analogy the View is the rooms in the house, the State is how furniture and such is arranged, and the DOM is everything coming together when you walk through the house.

Where this can become a breakthrough is the State is a JSON file that holds the information of what the data looked like at that moment. For example: A support app would have Open, Complete, Solved as an option for ticket on a screen, the State would hold what status the ticket is in. If the status of the ticket changed from Open to Complete the State JSON would be updated to reflect the Closed status.

This puts in an amazing position where when we run into the dreaded:

Null object reference not found

When reported the current State and the States leading up to the error could be sent to the support rep could in a DVR like way walk through what happened for the customer in a Sandbox environment, and hopefully get that ever valuable reproduce. We would then learn if it’s a bug that needs to be fixed or maybe something as simple as making an error message clearer.

Maybe this isn’t 100% possible, but if an app is built with this in mind from the beginning it could open the flood gates of solving the nearly impossible to solve.


The biggest stress factor I have from Support is the unknown. Thankfully it’s not often for me, but that nagging feeling of what’s going to go wrong: The “today has been almost too slow” feeling you have on the ultra slow days, or maybe the irrational fear of waiting for the tickets to flow in after a change to a production environment.

User Onboarding IRL

While at most companies user oboarding isn’t something Support is responsible for crafting the experience, I always enjoy seeing how companies handle a similar process much differently – UserBoard.com is a favorite of mine.

A hobby of mine off the internet is playing board / card games. Much like the user onboarding of web service I always enjoy seeing how games handle explaining the rules differently. I bought Exploding Kittens recently and was impressed by how clearly the process of playing is laid out in the instructions sheet.


In a clear and concise manner about anyone can quickly figure out how to play – Step 1, 2, 3, done.

Compare that to another card game like Guillotine where the game uses confusing names, uses a card name that you’re not sure of what it means yet, and is printed on different sides of the instructions sheet. In the end game play is about as simple as Exploding Kittens, but seems much more complicated when reading how to play.


If there’s an onboarding process that you deal with everyday I suggest looking at it on with a fresh set of eyes and making sure it’s as clear as possible to someone who doesn’t go through the process daily, there’s always a small improvement to be found.