Half of the battle when it comes to making business decisions in our current landscape is knowing what’s possible. Whether we’re talking specifically web development (HTML5, CSS3, responsive design, etc), or any other aspect of running a business – marketing, customer service, human resources, legal, accounting, strategy, and the like – it’s impossible to be even close to an expert in all of them. Things are changing too fast. The best that I can hope for is to have an idea of what’s going on, of what’s possible if we need to improve something in one of those areas. I need to do this in a relatively short amount of time. And so I skim. I skim my Google Reader, I skim magazines, I skim Twitter. Most of the time I just read a headline plus maybe a few sentences, and then move on to the next piece of news. My goal isn’t full comprehension, it’s getting a gist of what the article was about in 15 or 30 seconds, and then to move on to the next.

When I do this, I’m creating a “mental database” of what’s going on in the world. Often times when we encounter a problem, the first thing I do is think “I remember hearing about xyz company that had the same problem” or “there’s this cool new website/software/technology that might solve our problem”. From there, I usually only remember a small part of where I saw the article. Maybe I remember how I read it (say Twitter) or where I read it (say Wired.com) or who shared it with me, but I’ll start to dig backwards and usually find what I’m looking for in a matter of minutes.

Only then do I start reading more traditionally, aiming for full comprehension. I’ll send an article to my Kindle, buy a book, find other online resources, or whatever makes the most sense for the particular situation. So, to me, skimming is a great enabler. It’s a highly efficient path to more knowledge. I can consume vast amounts of incredibly resourceful material in extremely short periods of time, and then circle back and dig deeper if and when I find it necessary.

Cyber Monday 2011 at Detailed Image

That picture says it all. I couldn’t stand back far enough to get all of the boxes in the shot!

I’m writing this at 4:45 PM on Monday, so I’m not sure whether or not today will break our record for sales in a day. I think it will based on our pace, but if it doesn’t, it will be close*. Regardless, we’ve already surpassed last November in sales, and the year as a whole surpassed 2010 a while back so in some ways it’s kind of insignificant.

To me, the real significant thing about today was just how easy it felt. It wasn’t hectic like it was in previous years (see posts from Cyber Monday 2008, 2009, and 2010) but orders were coming in at just as fast of a pace, if not faster. Compared to say 2009 it felt half as busy even though we shipped out more orders.

Throughout the year we put all of these little efficiencies in place to save a minute here and a minute there. We also have worked hard to put together a team of people who work hard but also have a relaxed, positive attitude. All of those things really come together on a day like this. With a really small team – only five of us in the warehouse today – we were able to pack and ship a mountain of orders without rushing or scrambling around.

The number of emails that we received relative to the number of sales has been down as well (yes, we track that number), which again I attribute to all of the little improvements we’ve made throughout the year to our product pages, FAQs, guides, and blogs. It’s a day to celebrate the cumulative impact of all of those little wins.

Oh, and we *almost* filled up the entire FedEx truck. They had to pack the boxes in there pretty tight. I’m looking forward to the day when they have to call in for reinforcements!

*Update 11/29 – The pace picked up considerably in the evening and we ended up destroying our single-day sales record!

What is Text Expansion?

Text expansion is one of those things that’s somewhat difficult to explain, but once you see it or try it you instantly realize the value of it. Lifehacker did a great feature on text expansion last year. Here’s how they define it:

Text expansion utilities monitor your typing and trigger rules when you type a predefined phrase or key combination. When you type one of those pre-defined phrases, your text expansion utility removes your short version and replaces it with a longer phrase without requiring you to type the entire thing – saving you loads of keystrokes and time.

One of the things that I say over and over at the end of customer service emails is “Let me know if you have any other questions and I’ll be happy to help.” Now I haven’t actually written that phrase in years. What I type instead is “lmk+” and then {Tab} and text expansion takes care of the rest. I like using “+” followed by {Tab} at the end of my “trigger” to ensure that there’s absolutely no way that text expansion will be triggered by mistake.

Here’s a quick video I put together that shows just how fast I can respond to certain emails.

The beauty of text expansion is that I can piece together several different canned responses to create a unique email without ever actually typing anything more than a series of short triggers that I’ve memorized.

I also love text expansion because I only have to think about a reply once. I get a lot of technical questions from non-technical customers. These questions require that I create a thorough response that resolves the issue and is also simple to understand, which can take some time and effort to craft. Once I get the wording correct, I can just add it to my text expansion script and the next time it arises I won’t have to think through that “perfect wording” again.

Using AutoHotKey With Dropbox

When I first wrote about text expansion back in 2009, I was using a product called Texter. Texter was created by the Lifehacker team several years ago (the last update was in 2007). It sort of works in Windows 7, which was good enough for me until we went on this customer service initiative and we needed a way for everyone to have access to the same database of standard responses.

After doing a little research I learned that AutoHotKey was the gold standard. I was a bit intimidated because it isn’t really a piece of software in the typical sense, it just runs in the background and allows you to write Windows scripts that can do all sorts of things, text expansion being one of them. I shouldn’t have been intimidated though – it took me all of 15 minutes to download it, install it, and get my text expansion up and running exactly the way I had it on Texter. I wouldn’t even bother using Texter. AHK is far more flexible and really simple to use. Their documentation is thorough, yet easy to read even for a non-programmer.

During my research I read a comment on Lifehacker by someone who used Dropbox to sync their AHK scripts across their computers. That was what I was looking for to tie all of this together. I downloaded it and installed it myself, and the AHK script ran fine from the Dropbox folder. Then I set Greg up with AHK and our Dropbox account and we tried modifying the AHK file on one computer and it synced perfectly across our computers. If one person creates a new standard response it’s instantly available to everyone in our company!

We created a cheat-sheet on our wiki so that everyone would have a simple way to look up each trigger and it’s purpose, as opposed to having to open and navigate through the long AHK file.

Another great thing about AutoHotKey is that you can run as many scripts as you want. We have a shared script, but I also have a personal script for some of my own salutations or standard responses for things that the other guys won’t ever need (like when someone asks me to review a book on my blog they get hit with “bookreview+”).

It’s an Investment

Text expansion is amazing. After using it for a few years, I can’t imagine using a computer without it. It is however, an investment, and like any investment it takes a little time to truly pay off.

In the beginning, it’s quicker to just type a reply, hit send, and move on to the next email. It takes an additional minute or two to standardize the response, add it to AHK, test it, and add it to the wiki.

After you start getting used to it a bit, it becomes just about as fast as copying and pasting from a standard responses document. You still have to look up the trigger on the wiki or by opening the AHK file, which takes just as much time as copying and pasting does.

The real benefit comes once you’ve memorized all of your commonly used triggers. Then you can piece together emails rapidly like I did in the video. You don’t need to type any part of the actual reply, you don’t need to think about wording it, and you don’t need to leave your inbox. You just answer emails really fast. Even if you do need to customize part of the email, you can freely flow from normal typing to text expansion without even thinking about it.

—

That concludes my three-part series on Creating a Better Customer Service Workflow. While our system is far from perfect, it’s a massive improvement from what we were doing before. We’re all able to work faster and more efficiently now, and even more importantly we’re in a position where we feel confident about plugging a new employee into our system.

In my previous post, Creating a Better Customer Service Workflow: Part 1 – The Problem, I gave an overview of the issues we’ve begun to face as we’ve introduced multiple people into our customer service workflow.

As you can see from the graphic above, our solution was simply Gmail. Well, a pimped out version of Google Apps Gmail that takes advantages of all of the unique features that Gmail has to offer in a manner that actually turns it into a pretty awesome customer service system for a small team. This solution sort of came about by accident. Since we use Google Apps Gmail on a regular basis, we’re always discussing all of the new features. One day Mike suggested that the combination of those would make for a pretty good customer service system. After some discussion, we all agreed, and we decided to give it a try.

How It Works

I’ve never been a fan of Gmail’s conversation view. In my personal Gmail, and in my Google Apps Gmail, I turn it off. However, for customer service, having these threaded conversations is ideal. This is the number one feature that makes Gmail an appealing customer service platform. It looks very similar to a ticketing system on the back end without having all of the downsides of a ticketing system I mentioned in the previous post.

Under our Google Apps account, we created support emails for our major sites, so detailedimage.support, lockerpulse.support, and sportslizard.support. Since we recently upgraded to the premiere business version of Google Apps, each of these accounts costs $50/year. We then routed all of our customer service emails to these new customer service addresses.

Stepping back for a second, the main downside of a shared inbox is that it can get messy if everyone isn’t on the same page. We made three simple rules: 1) every support email must have a minimum of two labels, one for the type of inquiry and one for the team member who is assigned the email, 2) emails should stay in the inbox until they are answered and then archived, and 3) if you’re passing an email to another person you should label it with their name, move it to the inbox, and mark it as unread.

Gmail has two features that make this super easy – address aliases and filters. We use address aliases to “tag” incoming messages from our contact form. For example, if someone picks “website issues” from the dropdown, the email will be sent to detailedimage.support+technical. Used in conjunction with filters, this allows us to automatically label every single incoming message with the type of inquiry and the person that should answer it. For instance, that email would be labeled “Site Issues” and “Team/Adam” because I handle all of the website issues.

This is absolutely huge. If I log in and there are 10 messages, I don’t need to look at all 10, only the ones that are labeled with my name. Given that there’s not a ton of overlap in our areas of expertise (I won’t be answering detailing questions, just like Greg won’t be answering technical questions), it would be a huge waste of time for someone to have to do this manually.

The last critical piece of the puzzle is Gmail delegation. Gmail allows you to grant other people access to your account to answer email on your behalf (like, say, a secretary). We took each support email account and granted access to each individual’s Pure Adapt account, making it super simple to switch between inboxes (remember, one of our goals was to not add complexity to our routine, and logging in and out of several Gmail accounts all day long qualifies as that). I’m the only one who answers questions on all three sites, so here’s what delegation looks like for me:

When you send an email, it says that it’s from “Detailed Image Support (sent by [user])”, where [user] is the sender’s individual Pure Adapt email address. This lets us search by sender. For instance, if we want to get a quick look at all of the sent messages by a new customer service employee, to check for quality or quantity or response time, we can.

As an aside, because of this new system we have all stopped using the Thunderbird mail client and moved to using Gmail directly in the browser. It was a long time coming. Thunderbird served us well for years, long before we were on Google Apps, but the time had finally come to ditch it and move to the browser. Gmail is arguably a higher functioning email client than anything available on the desktop.

The Advantages

The primary advantages of using a system like this is that it solves all of the problems I mentioned last post. We can all see, search, and reply-to everyone else’s email. If someone goes on vacation, someone else can just step right in and pick up the slack. There’s never an issue of a customer contacting us twice in two different locations.

This also compliments with our internal “User History” system well. The system allows us to look up and modify everything someone has done on our site. We can search by all sorts of criteria, like name, email, user ID, order number, tracking number, etc. One of the bits of information that gets displayed is their inquires through our contact form, along with a corresponding request number, making it simple to then take that number and search it in Gmail to find the ensuing exchange. Down the road, I may integrate these two things further so that the entire conversation is available to view in their User History, but for now it seems to work really well. With a few clicks you can literally find out everything you need to know about a customer.

It also should be noted that the setup time for this was a huge advantage. Less than a day of time total on my end to configure everything, document it all, and then have a meeting to kick it all off. Compared with the setup time on a ticketing system, or the development time of a custom system, this was a breeze. Gmail is also a familiar interface for all of us, and it’s likely to be a familiar interface for our future employees, which will help cut down on the learning curve.

For what it’s worth, as we all move towards using mobile phones and tablets as complimentary email devices, Gmail is very well supported. Not something we really took into consideration, but it is nice to not have to worry about our ticketing system not having a mobile website/app for every platform out there. Gmail works well across the board. I know for me, it’s easy to switch back and forth between accounts on my Android phone.

The Limitations

Like with any system, there are some limitations. Here are the big ones to me:

• Lack of stats. Even though we can search by user, and in Gmail you can see all of your account activity, we don’t have access to the types of stats most ticketing systems do. It would be nice to break things down by user, like average response time, number of requests handled, and overall time spent answering questions per day/week/month.
• 10 person limit. You can delegate a Gmail inbox to up to 10 people. Not a big deal for us for a long time, but it’s a downside for sure when you talk about system scalability.
• Conversation grouping isn’t perfect. If the subjects match, Gmail tends to group it into a conversation, even if it’s from a different sender. This has forced us to take any generic subject line like “Detailed Image Tracking Information” and change it to “Detailed Image Tracking Information. Order #12345″ to avoid this. Kind of a pain, but not a huge deal.
• No labs support. Gmail labs features don’t work when you’re in a shared inbox, whether you configure them in your account or in the master account. There are a few labs features I’d like to use, but we can’t.

That’s basically it. All in all, a relatively simple solution to what was becoming a big problem for us. We’ve been using it for about a month now and it’s been a huge improvement.

In my next post I’m going to discuss how we use synchronized text expansion to speed up our response time.

We’ve recently overhauled our customer service workflow so that it’s simpler, more scalable, and more efficient. These changes apply to all of our sites that generate a lot of customer questions – Detailed Image, LockerPulse, and SportsLizard, but primarily you can assume that I’m talking about Detailed Image throughout, given it’s relative importance. This is the first of three posts. In part one, I’ll discuss the problem with the way we did things previously. In part two, I’ll go over our solution, and in part three I’ll outline one of the major changes that has drastically increased the speed at which we can answer any given email.

Life Is Simple When It’s Just One Single Person

When any small business is first getting off the ground, you usually just have one person answering customer service inquires. In most cases, this is how it should be: KISS. There’s no need for the added complexities that come with multiple people providing customer service.

Whether a customer emails you or submits an inquiry through a contact form, the workflow is pretty much the same: you get the email, you reply back, you and the customer continue to email back and forth until the issue is resolved, and then the conversation is forever archived in your email to be searched and referenced by you, the sole customer service agent. Everything is nice and simple, kind of like this:

With Two People, It Gets Complex

Unfortunately, as soon as you introduce a second person into the system, all hell breaks loose. Now, emails can go to either of you. You can each search your own emails, but you can’t see the other person’s. It looks a bit of like this:

This isn’t catastrophic – it’s how we operated for several years – but you run the risk of having several recurring issues. The largest deals with customers who contact both customer service people, either inadvertently (because they’re anxious and they want a reply) or intentionally (if they don’t like what one person says, they try another to see if they can get the answer they want). This can result in double work being done, confusion, and, if a customer happens to get a different response from each party, an inconsistent (and unfair) customer service experience. You also can run into issues when someone takes a day off. If they don’t check their email, important inquiries can go unread and unanswered in a timely manner.

Now, we combated this with some common sense. We’d forward customer service emails to someone else when people went away for any extended amount of time, and we’d do our best to chat with each other when we were unsure of a situation. This worked, mostly, for the better part of five years.

Eventually though, these problems became too big to overlook. We needed a way to avoid those mistakes. Everyone had to be able to see, search, and answer everyone else’s conversations without adding time or confusion to our already busy days. Preferably, this new system would save us all time.

We also needed a system that could be easily taught to an employee. This was really what pushed us to make the change now. We will be hiring soon, and one of this person’s big responsibilities will be to answer Detailed Image customer service. We need to be able to monitor what they’re doing, jump in at times, and not have to worry about fragmenting things further by creating another separate email account.

Ticketing System? Not For Us, At Least Right Now

Most companies choose to solve this problem by using a ticketing service or ticketing software. We’ve all experienced this many times as customers. You send an email or submit a question through a contact form, and then you get an email letting you know that a ticket has been created, either immediately or after someone manually creates it. Then you might get an email a little later saying “Your ticket has been assigned to Matt”. And then eventually you get a reply to your question. If you then want to reply, you either have to visit their website, create an account (sometimes), and reply in their ticketing system, or you have the choice to reply via email between those asterisks….you know, the ones that look like this:


******************************************************************************************
TO REPLY TO THIS MESSAGE PLEASE REPLY BETWEEN THESE LINES. EVERYTHING ELSE WILL BE CUT OFF
******************************************************************************************


At the end of it all, you get an automated email asking if it’s OK to close the ticket. Sometimes you then get another email asking you to rate the person who helped you.

Now, ticketing systems have some real advantages on the back end, but my partners and I don’t like this customer experience at all. I recently submitted questions to two different companies, both of which we are paying customers, both of which use Zendesk. Zendesk seems to be the new leader in this space, at least for web apps. In both cases, I had to sign up for a separate account to reply to the ticket. In one case, it took two days for the ticket to be created, and another two to get a response. In both cases, despite my questions eventually being answered, it felt like a very cold experience.

Contrast that with when you contact a company and you get a real email back. It feels much more personal, much more friendly. You can just click reply and say what you need to say. It doesn’t matter what email program you’re on, it doesn’t require you to reply in any way that’s different than any normal email, and you can attach anything you want and it will definitely get to us. In short, email is the simplest, quickest, and least stressful way for a customer to participate in a customer service exchange. At least that’s how my partners and I feel.

A ticketing system might eventually be in the cards for us. It might be unavoidable when we have 10 or 15 customer service reps. But what about when we have two or three or four? The more we thought about it, the more we were against a ticketing system right now. There had to be an intermediary step for us, one that preserved the advantages of email while still solving all of our problems. We contemplated building our own custom system, but the time and work involved seemed too complex. What to do?

In my next post, I’ll outline our solution. More to come…

One of the more difficult things has always been figuring out at what threshold we need extra people in the warehouse beyond the scheduled team. What we’re really trying to quantify is: how much physical work needs to be done to get all of the orders out? For years we always relied on the total dollar amount of orders in our shipping queue. This is a good metric, but it has some noticeable flaws, especially on busy days. For instance, if we’re running a 20% off sale, that number will appear to be lower than the actual amount of work that needs to be done (an order that usually costs $100 will only be factored in at $80). Or, if we have a buffer on sale (as we do this month) and we’re selling a lot of them, it could make it appear as if there’s more work than there actually is because there’s a big difference in how long it takes to package a single $130 item than $130 in $10 – $20 products.

Given this, we asked ourselves, what numbers do we have that will help normalize this data a bit and give us a simple number that we can work off of on a daily basis? We decided that we could get a much better idea of how busy we were if we factored in total dollar amount being shipped, total number of packages being shipped, total number of items being shipped, and total weight being shipped. We then came up with a maximum threshold for each, the absolute most we think we can do in one business day given our current team, which we guessed to be roughly 20% higher than our previous maximums. These maximums will likely change any time we add staff or introduce a new efficiency.

We weighted each of these factors equally to come up with a simple single percentage that gives us a better approximation of how busy we are. We can view it in “real-time” for what is currently in our shipping queue, and also have a report so that we can compare it to the past. Our maximum is roughly five times larger than our average day, meaning that on average we’re around 20% capacity but that we’ve fluctuated up to about 80% on our busiest day. I’m not sure if this is normal for e-commerce companies or not. I certainly think the seasonal nature of our business, combined with how often we run sales, factors in to the variation quite a bit.

Here’s a shot of the variation from before, during, and after a recent sale (read from bottom up, so the 15% day is the first day in the example):

I’m really excited about this. It’s a very simple metric, which is why I think it works. It’s hard to try to think in terms of packages and revenue relative to our staffing capabilities, but it’s easy to think in terms of percentages. In both the short term and long term this should help us out quite a bit with our warehouse staffing decisions.

Back in 2008 we migrated all of our email to Google Apps. Along with email, we also moved all of our documents and wikis. It’s almost impossible to quantify how well this has worked, between the time-savings, cost-savings, and collaborative features. I almost can’t imagine running an organization without it. Over the past few years the Google Apps Blog has done countless stories on large companies and organizations, including many governments and municipalities, who have ditched all of the costs of hosting their own email and documents in favor of Google.

For a long time we’ve been planning to upgrade from the free version to the Permiere version, which costs $50 per year per user, and offers features like more email storage, more business security features like forced SSL, a 99% uptime guarantee, and 24×7 support. These things aren’t necessary when you’re first starting out, but there comes a point where $50/year/user is a ridiculously cheap price to pay for those things. I’m a big believer in “you get what you pay for”, especially in business. You can only get just so mad when a free service goes down or temporarily loses a little of your data or doesn’t respond to a question you have. We’re at the point now though where we can’t afford to have those things happen. A day without email would be close to catastrophic, which is why we’ve now upgraded.

We also upgraded because we’re in the middle of a massive overhaul of how we do email, particularly how we handle customer service, in preparation for hiring a customer service employee soon. We’re planning on using even more of the Google Apps functionality in our day-to-day workflow, which just heightens the need for all of those things that the Premiere account offers.

Of course, Google and Gmail have had their fair share of outages and data loss, so we’ve also signed up for Backupify, which automatically backs up everything in our Google Apps (and Flickr and other services) for $19.99/month. In an absolute worst case scenario, like if Google ceased to exist, we could be back up and running in less than a day with very little data lost. Another no brainer for us at this stage in the game.

When I was completing the sign up process, I had a moment where I thought “I’m also happy that we’re paying because this is a way to pay Google back for all of the great free stuff they’ve made available to our business”. Of course, then I thought about all of those services and realized that over the years we’ve paid G a boatload of money for AdWords…so maybe I’ll just stick with all of those other reasons for upgrading.

Lately we’ve been trying to take a critical look at everything we do. As we grow, you can only do so much and still keep your sanity. We’ve been trying to ask the critical questions: Is this something that we need to keep doing? Can I do it less often? Can I delegate it? Can I outsource it? Can I automate it?

One of the tasks that had been taking up an increasing amount of my time is something I call “LockerPulse source management”. The RSS feeds that we pull from are sometimes published with invalid code that we can’t parse, or sometimes the sites are down temporarily. Since we check each site every 15 minutes, it can be a waste of resources to constantly poll and attempt to process a feed from a site that’s down for even a day or two. To combat this, I had been running a check a few times an hour that would kick me an email if a news source hadn’t been processed in over an hour (4+ failures). If I got one of the emails, I’d manually investigate and deactivate the source in our system if necessary. Then, at least once per day, I’d check to see if those sites were back, first by visiting, then by validating with the w3C validator, and finally by putting it through a simulated parsing in our system. If it passed, I’d reactivated the feed.

Over time, as we’ve added news sources and added college sports coverage, this became a 30 minute-per-day task for me. Even worse than being 30 minutes, was that it was in several small chunks. So maybe three or four times per day I was doing this source management for 5-10 minutes. The thought that I had to check on it was always subtly in the back of my mind.

A few weeks ago we talked about delegating it. Then I thought some more, and realized that everything I was doing could be automated. Even the W3C check just required using their API. Over the weekend I put this in place and now I have a system that’s constantly deactivating, testing, and reactivating all day long. It does a better job than I ever could, and it takes zero effort from me. All of this took me only about 3 hours to set up and test.

In retrospect this should have been blatantly obvious, and something I should have done much earlier. But it was one of those things that at first only took a few minutes a day, which I saw as negligible time. By the time it had grown I had just become so conditioned to it that I didn’t realize just how much time it was taking up. 30 minutes/day over a year is 10,950 minutes, or 7.6 full days saved. Not to mention the mental effort expended on starting and stopping something a few times a day, or the tiny bit of stress I had every time I opened my inbox and saw an alert.

All of the tiny, seemingly negligible, efficiencies like this that you can put in place now will eventually come to help your business in the long run. Especially when the “break even time” is less than a week like it was in this case. A few minutes here and there compound over time to make a huge difference.

Yesterday we launched a dedicated mobile site for Detailed Image. Above are a few screenshots. Overall I’m extremely pleased with how it came out. The functionality is nearly 100% of the full site. That said, the story of how this mobile site came about over the past two weeks is much more interesting than the functionality of the site so that’s going to be the focus of this post.

Why a Mobile Site?

I think the main answer to this is obvious – more and more people are browsing the web from mobile devices. The second reason, and what threw me off course on the scope of this project, was to simplify functionality. The Detailed Image site when it was launched in early 2009 was one of the few e-commerce sites that really pushed the use of AJAX. Some features, such as a dropdown notification after adding a product to cart (instead of being taken off page), or adding/removing products from your cart, or applying a coupon code, greatly benefit from a usability perspective. Initially, that level of javascript processing wasn’t possible on mobile phones. In 2009 the majority of the people trying to buy from an iPhone ran into issues and couldn’t complete their purchase. If you recall, it was one of the four major reasons that people failed our checkout.

My Original Strategy

Given that reasoning, our original strategy was to build a completely separate mobile site at m.DetailedImage.com similar to how we built our scaled back mobile site for LockerPulse. The mobile site would have stripped down functionality, removing the need for javascript in the shopping process to accommodate phone browsers. Just to get all of the portions of the site critical to shopping (home page, browsing, item pages, registration, checkout, etc) I figured it would take 1-2 months plus testing time. While the back-end functionality would remain the same and utilize all of the existing classes, the front-end would be totally new.

Initially I had this in my dev plan for early 2011, prior to our Spring rush. Then I looked at the stats and saw that about 6% of our visitors were coming from mobile devices. I decided to try to bust ass and get it done prior to the Holidays – even an increase in conversion rate of a percentage or two amongst those mobile users would make it worth my time. However, as I sat down to map the project out I started to freak out a bit (this was only last Monday, some 11 days ago). There was no way that I could get it done prior to the holidays and still get everything else done that I had planned. In addition, I wasn’t really looking forward to all of the tedious testing. What to do?

When I mentioned my plan to work on the mobile site, George pointed out that many people were in fact checking out OK on their devices. That prompted me to look into the data a bit more. Turns out that all throughout 2010 people have been checking out fine using their mobile devices. Only 1 failed checkout, in February, and I’m pretty sure it was one of the other reasons that caused it. All in all, lots of sales through mobile devices, almost all on iOS and Android. It does make sense – given the advance in the Webkit browsers that both use, any javascript issues from early 2009 that I assumed were still there are now gone. Just for good measure I picked up my Android phone and tested everything I could think of – no issues.

That completely changed my approach. Now we’re not talking about functionality at all. We’re talking strictly aesthetics, which led me to the idea…

My New Strategy

What if we simply just served a new stylesheet to mobile users? It would be inserted into the header after all of the other stylesheets so that it would over-ride the main styles and display them properly for mobile devices. I remembered MOBIFY, a company that will “mobify” your site in minutes with the same approach.

I whipped open Firefox, opened up Firebug, and within minutes had proved my concept to myself. From the LockerPulse site, I remembered all of the “rules” for mobile design – full width, no sidebars, variable font sizes, small images, etc. It was pretty easy to show myself that it was possible. I was so excited – the benefits of doing it this way are astronomical (see below).

Instead of spending months, I spent a handful of days going page by page through Detailed Image and re-styling the pages, although once the template was done many of the pages already looked just fine. Only ~150 styles were required to transform the entire site. We benefited immensely from haven written all W3C compliant HTML and structuring our CSS well. I had to write one small javascript function, do tiny bit of work with the HTML served (such as changing the doctype to a mobile doctype), and build in the device detection from LockerPulse, and we were all set.

How it Works

When someone is determined to be a mobile user, we simply change the doctype declaration and add in the new stylesheet and javascript function. Everything – including both blogs, the guides, reviews, and the entire shopping process – still has the functionality that it does on the main site. How do we determine if someone is a mobile user? There are a few ways:

• URL variable – the URL variable “mobile” can be toggled on any page of the site to put you in or take you out of “mobile site mode” (i.e. www.detailedimage.com?mobile=on). m.DetailedImage.com simply directs there. There are links in the footer of both versions to go back and forth (no visitor ever actually has to use the URL variable).
• Cookie – once the URL variable is set one way or another, the rest of your session will remain that way unless you change your mind and click one of the links in the footer.
• Device detection – if there isn’t a URL variable or a cookie, we use a class I built for LockerPulse to detect whether or not you’re using a mobile device. Given that it’s been proven on LP, this was a very quick implementation.

Pros/Cons

First, the pros:

• Way faster – took less than two weeks from idea to implementation!
• Little/no maintenance, very scalable – assuming we stick to our coding/styling standards, new pages should look just fine without any work. Occasionally we’ll need to do something minor like hide an element, shrink an image, or remove a border.
• Cool features that help mobile browsing – I never would have thought to include the autosuggest for the search box in a mobile version, but it’s maybe even more important because of how tedious it is to type on a mobile screen. In the same manner, drilling through products by criteria such as brand, price, and usage become even more helpful on a small screen.
• The entire site – the blogs and the guides are a large portion of our traffic. It’s great to get those into a readable format for someone who has a few seconds to kill on their phone.
• No redirects – no redirects to maintain, and if the device detection happens to be wrong there’s no messy incorrect redirects going on.

Of course, there are a few cons:

• Extra HTML – a dedicated site would have only the HTML necessary for the mobile site. Our mobile pages serve up some elements, only to have them hidden with CSS.
• A lot of requests – in the same manner, we have our main stylesheet, only to have an additional request being made to another stylesheet that over-writes a large portion of the original stylesheet.

Clearly, the cons are NBD (no big deal) given the relative advantages of the pros.

SEO Impact

But how does this affect how search engines see the site? Good question. Thankfully Google answers it in full in their recently updated SEO guide (I know I’ve said it before in my essay, but it’s a must-read for any site owner – who better to get your advice from than the search engine itself?).

Google does two things that are really smart – they have separate sitemap syntax for mobile sites, and they use a separate user agent when crawling mobile sites. The first lets you submit your mobile sitemap to them. In our case, the URLs I submitted were exactly the same as the ones in our regular sitemap. The difference being that they’ll send Googlebot-Mobile instead of Googlebot to visit those mobile URLs. By adding Googlebot-Mobile to your device detection, you’re serving your mobile pages to the mobile crawler and your normal pages to the normal crawler. It’s explained in full in their guide, but basically they just want you to show them what you show a visitor of the same criteria (mobile vs non mobile) and you’ll be fine.

Business Impact

Bottom line: I just got a two month project done in two weeks, and got it done better. For me, this serves as a reminder to always challenge my own assumptions. Things change fast in the web world. What wouldn’t have worked in September 2009 worked just fine in September 2010.

Author of Never Check Email in the Morning Julie Morgenstern suggests waiting for one hour before you open up your email inbox in the morning. Accomplishing something out of the gate sets the tone for the rest of your day, Morgenstern says, and once you’ve launched your email client, you’re “open for business” and paying attention to incoming requests.

In theory it sounds great. But I’m going to play contrarian to that viewpoint. Working under the assumption that you don’t literally roll out of bed and check your email (I don’t particularly think that’s healthy, I like to hit the gym up first thing in the morning), and working under the assumption that you have good email habits like I’ve outlined in prior posts (filtering non important emails, only checking email at set intervals, keeping your inbox empty, etc), then I think checking email is the absolute smartest thing to do when you first sit down to work in the morning.

Here’s why. As a business owner (or, really anyone with an important job) you’re constantly running into little “emergencies”. It seems crazy to think that whatever little productive task you’re accomplishing at the beginning of the day is more important than putting out a fire. If our server is down, I get a text message alert and I’m on it no matter what time of day. Otherwise, anything important I get notified via email. I auto-filter out the unimportant stuff (like newsletters and notifications of sales that come through DI) so that my inbox generally consists of customer service questions, email alerts of odd things that happen on our sites, emails from my partners, and stuff related to my blog. The blog stuff can wait, and usually does. The rest of it is far more important than anything else I would have been working on.

On any given day my project work typically involves working on programming a feature for DI or LP, or working on some marketing initiative related to one or the other. A routine customer service question for DI might involve someone having trouble checking out or applying a coupon code. An email alert might involve someone who hit refresh during checkout and got charged twice. My partners might have noticed a bug on one of the sites. Which seems more important to you? Taking care of your customers is and always will be more important than establishing positive momentum on my work day. For me, I’m more stressed out working on programming something when I know there could be stuff sitting in my inbox that is holding up someone from getting their order shipped out today. It doesn’t make a difference if the new feature is delayed by a few hours or a few days even, but it does matter if there’s a customer waiting on a reply or something is seriously wrong with one of our sites.

Essentially, for me it boils down to this. Emergencies always supersede project work. And if you are trying to provide great customer service, that too should also supersede project work.

I feel like this translates well to other jobs too. No matter what type of work you do, there’s always unforeseen things that should immediately jump to the top of your priority list. If you have clients that have a major issue with their site, you’re better off all around just knowing about it right away and fixing it ASAP. They’ll be happier and you’ll be happier. And if it isn’t a major issue, you’ll feel better emailing them an ETA on the fix, and they’ll feel better by hearing from you.

Now of course, if you took this too far you’d have your inbox open all day long and constantly be interrupted. Which is why I prefaced this by saying that if you’re like me (you have projects and customer service, both of which are important) you’ve got to be relatively strict with when you have your inbox open and when you don’t. The big difference with the morning is that it’s likely been 12+ hours since your last email check. Adding an extra hour, especially when you have shipping windows like us, doesn’t make sense. Not checking email again until noon or 4 PM isn’t a big deal because those people are waiting a few hours at most. I’ve added a quick email check to my day around 1 PM because I know that’s the latest I can contact someone in the warehouse and get something adjusted before FedEx arrives around 2:30. I tend to check around 8:30 AM, 1 PM, and 5:30 PM, and it works out great – prompt replies for customers, especially during business hours, and still plenty of time with my inbox closed so I can get stuff done.

Anyway, in theory the idea of waiting to check your email might make sense, but in practice it just doesn’t work for me.