PlumberSurplus.com Ecommerce and Entrepreneurship Blog | About | Contact | PlumberSurplus.com Store

Windows 7: The Upgrade, Review, Tweaks, and Compatibility

Posted on February 9, 2010 by josh

As an IT Manager at a small to mid-size business, it's always a delight to see any system updates that are useful, well-designed, and fully functional. When these things are encompassed in an operating system, it's even more delightful. We operate a few different web properties and I've always wanted to maintain a good variety on our network (mostly for live testing purposes). You know, some users on Windows XP with Internet Explorer, some on Windows XP with Firefox, some on Windows Vista with Google Chrome, some on Mac with Safari, etc. I have been using Windows XP for some time, so when Windows 7 was announced, I was half dreading the transition; especially since I was due for a system upgrade and I knew I'd need to lead the charge. Also, Vista hadn't proven to play well with all of the software we used on its initial launch.

So, when I finally ordered my new system and started my transition from Windows XP to Windows 7, I was naturally trepidatious. I was also transitioning to a 64bit OS. How big a headache would it be? As it turns out, it's been the best operating system transition I've experienced thus far. New Dell laptop, check. Fresh install of Windows 7, check (also, the install was faster than I expected, and I didn't have any of the install issues that have been reported by some users). The only two things that have been a hindrance were easy to fix. The first was obtaining new drivers for a network printer; no problem. The second was some software with known compatibility issues on 64bit operating systems; no problem, Windows 7 has some great features to help with this, which I'll explain shortly.

While trying not to sound like a broken record with every other reviewer of 7, here are some reasons why I love the new Windows:

    • It takes all the best features of Vista. The aero interface and more "favorite-present" functionality work well. While I haven't always been a fan of all of the wizards Microsoft includes in progressive versions of Windows, I like the additions that were made to 7. For most of my users, and most home users for that matter, I can see how the "hold-my-hand" style menus and wizards are useful.

 

    • I love keyboard shortcuts and Windows 7 adds some really useful functionality. One useful shortcut is WindowKey+P to switch monitor modes (Computer Only, Duplicate, Extended, or Projector Only). We use multiple monitors at Gordian Project, so the strong multi-monitor support is appreciated and works well. Another set of new keyboard shortcuts for multi-monitor that I love is the ability to manipulate an active window; WindowsKey+UpArrow to maximize, WindowsKey+DownArrow to Restore/Minimize, WindowsKey+LeftArrow to dock to the left side of the active screen, WindowsKey+RightArrow to dock to the right side of the active screen, WindowsKey+Shift+RightArrow to move the active window to the monitor to the right, WindowsKey+Shift+LeftArrow to move the active window to the left monitor. Pretty cool.

 

    • The taskbar now includes keyboard shortcuts, too. Press WindowKey+{Position#OfTheTaskbarItem} to open up or switch to the taskbar item in that position. The new taskbar may bothersome (one user has complained to me that it's sometimes difficult to discern which items are open and which are shortcuts), but I think it's a drastic improvement. The last keyboard shortcut that excited me is WindowsKey+B to access items in the system tray. This one has been a long time coming. You might be say that I should just use the mouse, but I hate to take my hands off of the keyboard and anything that saves me time while I'm working is a welcome improvement.

 

  • The last thing that I've noticed, so far, about Windows 7 that's impressive is the improved compatibility engine. Not only does Windows 7 do a great job of utilizing the generic compatibility engine to make recommendations on compatibility settings, Microsoft has also made available Windows XP Mode. Windows XP Mode leverages Windows Virtual PC in a unique way that blew me away. First you download and install the Windows XP Mode package. Then, you download and install Virtual PC. This gives you access to a full version of Windows XP as a virtual pc, which, in itself, is pretty useful. But Microsoft took it a step further. Any application that you install in your Windows XP Mode virtual pc appears in the start menu of your Windows 7 machine! So, you can "Publish and launch applications installed on virtual Windows XP directly from the Windows 7 desktop, as if they were installed on the Windows 7 host itself." Not everything I needed to install and use is compatible with the 64 bit version of Windows 7, so this feature alone makes the upgrade far less daunting...at least for me.

For those of you IT managers out there wondering whether or not you should upgrade, I recommend it.

 

Electronic Data Interchange (EDI) Solutions that will Save Your Company Dollars before You Pick a Provider

Posted on January 22, 2010 by josh

Whether you're a business that buys or sells, you've probably heard of EDI. For those of you that haven't, EDI is an acronym that stands for Electronic Data Interchange. EDI is used when two entities want to share a standardized form of data. For example, a buyer sends a seller a Purchase Order EDI file. The seller then sends an acknowledgement EDI file. Then the seller might send a shipment notification EDI file, followed by an invoice EDI file. Makes sense, right? Seems easy…

We've built our own flavors of data interchanges before. However, we had not used the ANSI X.12 industry standardized EDI. We leveraged everything from simple flat files over automated email or ftp to xml via web service, each with agreed upon formats between us and suppliers or vendors. It's easy to do. You say, "Here are the fields and format we're going to send." They say, "Great! Here are the fields and format we're going to send." You both work to parse the data appropriately and agree on a delivery methodology and transaction schedule. So, why use the ANSI X.12 industry standardized EDI? Great question. I'm still trying to figure it out.

We were sort of forced to build it. By "sort of", I mean we were completely forced to build it. As in, one or more strategic partners says, "Oh, if you want to do business (/continue to do business) with us, you'll use this form of EDI." OK. No problem. How hard could it be? One would think that it wouldn't be that hard, as EDI has been around since the 1980's. This was back when data networks and a high level of computer competency was not a mainstream requirement of modern business, especially small businesses. Even the modern version of the standard still looks like it was built in the 80's. It also looks like it was built by a group of guys that desperately wanted job security. Yes, the files are in a standardized format. However, each file includes a copious number of optional elements, and a field representing one piece of data in one file type. For instance a Purchase Order file is formatted completely differently for the same piece of data in the next file type, like shipment. As I was working on the EDI project for our company, it occurred to me that this must have been the inspiration for XML. Someone was staring at this, saying to themselves, "No! Don't make me redefine the field for each stinking file type!" Also, the file has a flat file format, but it's delimited in the weirdest way. You have to build your parser to count out segments and account for optional fields. At least all of our partners utilize each of the standardized documents the same way, right? Nope. Each one takes their interpretation of the standard and we end up having to apply parsing logic by file type and by sender. Doh!

Pay Per Kilocharacter?

But, dealing with the building and parsing of files isn't the really irritating part; and truthfully, we're going to have to do something special for each of our business partners whether we use standard EDI or homebrew XML solution or something else. The REALLY irritating part is the delivery medium that you may be forced to use to communicate with EDI partners. As I understand it (and I could be wrong), back in the day, a very few telecommunications companies controlled data networks. These companies were regulated by government, and in order to charge for specialized services, like assisting in the transfer of critical business EDI files between two business entities, without regulation, they needed to create a new kind of service. So, Value Added Networks (VANs) were born. VANs serve as a go between, like a post office, offering various file transfer mediums, levels of security, tiered and specialized reporting, storage services, et al. You send a file up to your VAN, who holds a mailbox for you, and your VAN checks your file to ensure that it includes the right headers for the appropriate file type, stores your file and alerts your trading partner of a new file ready for exchange. That's it. That's what a VAN does, nothing that you couldn't do yourself. It's not like I can't store the files myself. Storage is cheap. It's not like I can't find a file transfer medium that works securely (simple things like FTPS or SFTP should not be tough for any IT guy to set up really cheaply). The best argument I've heard in favor of using a VAN, so far, is that it eliminates the need to let others have some access to your network. This came from one of our partners. To this I say, "Fine. We won't connect to your network. You can push and pull files on our network." Again, setting up the file transfers is not that hard and also doesn't expose your network to uncommon risk. It's dumb to pay the VAN for services that you can build yourself for very little money and effort. Plus, the VAN charges you by something called the kilocharacter. This is how you know it's from the 80's. A kilocharacter is represented by 1000 characters in your EDI file. Seriously, I feel so ripped off. Twenty years ago, you would have had to have a direct data link with the VAN. I would have really felt ripped off if that was the case today.

Paying Sticker Price

If you do have to do EDI through this type of channel chances are you'll be put in the position of explaining to your boss why your company has to spend money to send an order. It will end up being only pennies, maybe nickels depending on your volume, per order, but you won't feel any better about it. My advice if you're stuck in this position is this: Negotiate, Negotiate, Negotiate. When I started looking around for the right VAN solution, I was surprised at the breadth of offers. After getting quotes I went back to the same places and pitted them against one another. Not a single vendor stuck to their original quote. Everybody folded in one way or another. I finally found the two that would meet my needs that would give me a good price and I focused in on them. Just when I thought I had done a great job of negotiating and had gotten the best price I possibly could have, I went to my boss with my final contract terms for VAN services. He balked. "Why do we have to spend this much, again?" I explained it to him. He told me to go back and get better terms and better pricing. Feeling like I had done the best I could, I told him I would see what I could do. Surprisingly, when I went back and told the two vendors that I was going to have to decline because the price was too high and the terms weren't as good as we wanted, I was able to negotiate even better pricing and even better terms from both vendors.

Key Takeaways

The point here is this, if you can avoid having to use the antiquated and expensive ANSI X.12 industry standardized EDI, avoid it. If you can't (and chances are if you work with any large companies from traditional verticals, you can't), do this: Ask your partner to skip the VAN and exchange files directly with you. If they won't, get your customer or supplier to pay for it. If they won't, negotiate the heck out of the VAN services, then go back and negotiate again; you can get much better than published pricing on VAN services. Finally, if you're transacting via EDI with more than one customer or supplier, don't count on the files being used consistently across all of them. Portions of the standard are open to interpretation.

 

Google Site Speed Ranking Factor and SEO Dilemma

Posted on January 7, 2010 by josh

Google has recently made it obvious that site speed is an important issue. So important that they've discussed including site performance as a possible contributing metric to search rankings. Consequently, we've been paying very close attention to site speed and elevated it as a key area of focus for the development team. One area where I'd like some feedback from the SEO community or other web masters is the area of images.

Among the results from the multitude of tools that we've used to tune our site performance (another good topic for an upcoming blog post), most have recommended we serve static content from a separate, cookieless domain or, even better, use a content delivery network. For our sites, that mostly means images. Great. No problem. We know that we can make pretty significant gains. Take this page: http://www.plumbersurplus.com/Cat/Bathroom/543. This page contains nearly 180 images. Nothing large (the entire page's contents amount to 572 KB), there are just lots of images. {UPDATE: Since I wrote this post, we've reduced the number of elements on this page considerably.}
 
performance image
 
So, currently, we serve most of those up from www.plumbersurplus.com/images... on the webserver. A handful of the images are master page content that we're going to continue to serve up from the www domain, but the rest need to be separated out to another domain or taken off of the page. We know that on a typical low end DSL connection each of these images takes about 175ms to download. We also know that if we serve up all content from the same domain, then most browsers will limit the number of simultaneous downloads of resources. In fact, most older browsers will only allow 2 resources to be downloaded from the same domain at a given time. Additionally, since www.plumbersurplus.com is not a cookieless domain, the client is transferring cookie data with each and every request! Oy! With an older browser allowing only 2 downloads at a time, assuming 180 images at 175ms each, that means the client can download all images in about 16 seconds (180 images / 2 at a time = 90; 90 * 175ms each = 15750ms = 15.75 seconds).

That is way too freakin' long.
 
Instead of allowing all that content to be downloaded in serial, we would be well served to parallelize resource downloads. We can do that by serving up content from alternate domains. Too many alternate domains is bad, because the DNS lookups take some time, too. But eliminating the cookies and allowing the downloads to run in parallel should improve load times considerably. When I brought this up to our manager of SEO, the STOP sign came out. We don't want to wreck whatever SEO value we've garnered from images.

According to analytics, we get a significant enough amount of traffic from images that making a change to our image domain could be detrimental. So, here's the dilemma: Which ranking factor do we chase, existing images SEO or improved site speed? We decided to tip-toe into an image subdomain by changing the way images are served on a few pages on OutdoorPros.com: http://www.outdoorpros.com/Cat/Skateboarding/85 and http://www.outdoorpros.com/Cat/Skateboard-Decks/26/List. Images on these pages are served from images.outdoorpros.com, a cookieless domain. In addition, those images are still available from the www.outdoorpros.com/images... subfolder so that links to existing images aren't broken.

Before we go head first into serving up all image content from the images.outdoorpros.com subdomain, we want to see that content get indexed. We did this a few weeks ago. No index. In looking for a solution to the index problem, I've found lots of people saying it took as long as 6 months to see an index of their images. We've been around linking to images.outdoorpros.com to see if we can siphon an index of the images.outdoorpros.com subdomain, but haven't had any luck yet. Although we really have little reason to believe there will be issues with this, we would like to make sure before making site wide changes.

I'd love to hear recommendations on how to get the new image subdomain images indexed. Or, better yet, I'd love to hear an educated opinion on the move to an image subdomain as it relates to SEO and the balance between SEO and the SEO benefits of improved site speed (aside from the other known benefits of improved site speed, like improved conversion rates).


With Google rolling out ranking factors based on page load time, it's obvious to say that if our site is slower, our pages will rank lower, and if our site is faster, our pages will rank higher.  In the most basic form, the lower our ranks, the less we sell. The longer we wait, the more we risk severe and unpredictable consequences. In all probability, of the more than 200 ranking factors (who knows?), site performance will only be a slight influence. So, it's likely that the sky is not falling, but we don't know. Barry Schwartz, in the aforelinked searchengineland.com article, even says that "virtually no one complains that their [Adwords] quality score is low because of having a slow site." Despite this assumption, we still want to make this transition as quickly as possible in order to improve site performance.

Comments please!

PayPal to Retire Pay Later

Posted on December 2, 2009 by josh

For those of you who are using PayPal, and loved that PayPal offered a "Pay Later" service, you'll be sad to hear that PayPal Pay Later is being discontinued.

PayPal Pay Later


Today, we received a notice from our account rep:
...we have just been notified that PayLater, effective February 20, 2010, will be retired and no longer marketed.
 
We are removing PayLater as part of an overall strategy to optimize our credit product offerings.

 
As a merchant using PayLater today, you will be required to remove all PayLater marketing, including: banners, PayLater learn more product pages and “No Payments for 90 Days” Pay Buttons no later than February 20, 2010.
 
Please let me know what questions you have or how I might help you with the removal process.  We were delighted that PayPal offered the service, since most of the development had already been done when we integrated with PayPal.

Now we have to figure out if we even want to offer a comparable service from another vendor such as BillMeLater. One troubling note, though, is that PayPal reporting doesn't include data on the effectiveness of the PayLater campaign in our PayPal accounts. We wish we had the data, as it would help us to make a decision about how to prioritize a replacement product.

At least they gave plenty of notice...

 

Google Wave: First Impressions and Future Communications

Posted on November 30, 2009 by Josh

I was lucky enough to get an early developer invitation to Google Wave. When I saw the email in my Inbox, "Your invitation to preview Google Wave", I was giddy. I wasn't sure if I should try to sell the invite on eBay or crack it open it and try it out to satisfy my techno lust and curiosity. I opted to dive in. So as I signed up with an existing Google account, the whole time reeling with the notion that I'd be waving away, right away, only to be completely deflated when I was finally signed in. The irony of the beta is that when you first sign on to Google's new revolutionary communications platform, there's nobody with which to communicate.

So I sat and stared. Clicking around... Settings... nothing... Help... nope... Crickets... chirp... chirp... New Wave... useless without someone to communicate with... "Hey! I am pretty sure I'm supposed to get some invites with this thing. How the heck do I invite my friends and colleagues?!" I could not find a way to invite others. So, Wave was utterly useless at this point; well, I could wave at myself. How embarrassing. Sitting there waving at myself. I had work to do, so I decided to come back later. The following day I logged back in to show a colleague the interface and eureka! I had received a wave from Google with the opportunity to invite some others. The note, "Google Wave is more fun when you have others to wave with, so please nominate people you would like to add. Keep in mind that this is a preview so it could be a bit rocky at times." So, away I go, inviting all my nerdy friends and colleagues who I know will appreciate harnessing the new technology.

Days later, they get their invites and I start messing around. The interface is smooth and elegant. It's much like email, but cooler, more flexible. I have had some time to interact with others and there are some very cool features.

 

Google Wave User Interface


I like it. However, there is a bit of a culture shock with Google Wave. It's a different way of communicating. It doesn't feel natural at first. Most of us spend a significant portion of our lives in front of our emails. We're accustomed to the ping pong, linear functionality of email. There is a reason and order to email as we know it today. I send a message. You receive it.

Then you send a message. Google Wave does that, too. However, it adds a real-time element to communication that makes it feel messy at first. While I'm typing, the recipient can see what I'm typing and synthesize a response before I've fully communicated my idea. This is a very unnerving concept when compared to the elder email. It makes me want to be even more careful with my selection of words. I like the feature, but it's weird. I've used email and I've used chat, but this is more like a melding of the two. It sounds good on paper, but after using it, I'm less confident that everybody will love it. I do, but not everyone will. Thankfully, you're supposed to be able to turn off the feature.

Traditional email has also become a staple of mobile users. I haven't had a chance to try the real-time communication features of Wave on my iPhone, but, in true Google fashion, the interface is simple, clean, and elegant (and, curiously enough, Wave is in Alpha on iPhone... I feel so privileged):


Google Wave on iPhone


I can see how Wave will be useful if the parties with which you communicate are using Wave. At this point in the beta, only those with Wave accounts can communicate. It makes it tough to leverage for regular use at this point, since users have to make a concerted effort to open it up and use it. Several months ago, we switched our company's email services over to Google Apps and the user adjustment to threaded conversations and labels was hard enough. I don't anticipate that I could get everyone waving any time soon certainly not during the beta, despite the fact that I like it.

Not all of my associates have enjoyed it. Here's a snippet from Wave illustrating this:


Not everyone is a fan of Google Wave


As you can see, not everyone is a fan. That's OK. Though I agree that it will not meet the monumental expectations, I doubt, very seriously, that it will be Google's Segway. Until more people get to using Wave, I'm not convinced that it will revolutionize the way we communicate so immensely. It takes some of the best elements of the way we communicate now and packages them in a clean interface. I think users will get over the uneasiness quickly and traverse the learning curve, mostly because the product is a Google product and comes with a great deal of hype. The communications platform is pretty amazing and the technology that is used is pretty fresh. At the end of the day, though, I get the feeling that most people will simply settle in to what's most comfortable for them.

If you'd like to wave at me, I'd be happy to send you an invite. Real comments on this post will receive a reply.

 


Little Giant has been hard at work engineering pumps that their most loyal customers have been waiting for. PlumberSurplus.com is your destination for the new Little Giant TSW Sump Pump System and their NXTGen Condensate Pumps.

Gmail Crashes: Users Scramble for Relevant Updates

Posted on September 3, 2009 by josh

You may already know that Gordian Project users are in the cloud.  Well, on Tuesday, we hit our second bump in the road with Google Apps. An outage. You may say to yourself, "An outage? With Google Apps? Really?" Well. Yes. Really. Totally freakin' down. Apparently, Google had an issue Tuesday morning that brought down the email interface for apps users.  Déjà vu?

Here is the error I got in Chrome:

Google 502 Error Please try again in 30 seconds

 

At first I thought to myself, "Hmmm. That's weird." So I literally waited 30 seconds and tried again. Same thing. So I asked the person next to me to try. Same thing. So, I tried my iPhone and got:

Google iPhone 502 error

 

OK. Seems likely to be a global problem. So, I alerted users on our network that I was aware of an issue with Google Apps and was looking into it. Because the error says, "Please try again in 30 seconds.” I figured it would be a temporary outage and waited only a few minutes. The problem persisted. So I checked Google News and, sure enough, there's a widely recognized outage. From the news, I noticed two things that were particularly interesting:

  1. I wonder if the "tip-toeing" of wave into apps created yesterday's havoc.
  2. Google has an Apps Status Dashboard

So, after I found out that there was an Apps Status Dashboard, I checked it out and here's what I got:

Google Apps Status Dashboard

Google, why didn't you show this to me on the 502 error page? Instead, you told me to try every 30 seconds. I can't imagine how many people wasted hours of their day refreshing every 30 seconds to try to get to critical email. You may remember this article highlighting good custom error pages.

After the incident was stabilized, Google posted an incident report here. According to the report, Google "underestimated the increased load that some of the new updates placed on request routing." Not sure what the "new updates" were, but it doesn't seem like Google should underestimate the anticipated load.

Noting the red "X" by Google Mail, I clicked on it at 1:48 PM to find:

Status report at 1:48

 

It says there will be an update at 1:53 PM, so I waited until 1:58 PM and clicked again:

Google Apps Status Dashboard update

 

Hey! Wait just a second! Ten minutes ago there was not an update at 1:02 PM. What gives Google? Don't you know that 45 minutes after I announced it to everyone, people are still coming to my desk to say "Hey Josh. My email's down."? Please, just tell me what I need to know when you know it! Also, I love that there is a link to the "How to use IMAP or POP", where the first step outlined is to "Enable POP or IMAP in your Google Apps email account". I can't get to my apps account! Then I realized, I already had IMAP enabled on my account and had it set up in Outlook. So, I started up Outlook... only to be woefully reminded of why I wanted desperately to switch to Google Apps to begin with. I quit Outlook before I even used it, as it was either Outlook or every other application, and a choice had to be made. Instead, I waited for the Google update. At 2:40 PM I refreshed the Status Dashboard to find:

Google Mail Status Resolved

 

Hooray! We're back up! Not without a few lessons.

    1. Google, or any other cloud service provider, when a critical service goes down, don't show me an error that tells me to retry every 30 seconds; especially if that's not really what you want me to do. Send me to the place with the relevant information. I know, based on your incident reports, that you "published ongoing reports to the Google Apps dashboard, Gmail Help Center, the Enterprise and Gmail blogs, and the GoogleAtWork and Google Twitter feeds, to help provide customers with the latest status and available workarounds.", but the error was unhelpful. Please don't make me Google it.

 

    1. IT managers, if you're going to start using SAAS and cloud enabled services, find out, in advance, what the notification mechanism is for outages. In this case, it would have been a simple thing to have added the Apps Status Dashboard to one of my feeds.

 

  1. Don't count on Google Apps, or any other cloud service being available 100% of the time. If you have a critical meeting or a conference call that requires you to have a cloud stored document or email or presentation up and ready to go, make sure it's ready and pulled up long before your event, or make sure to store it locally, as well. Also, based on Google's comments, it may be good to enable IMAP on your account just in case you can't web-surf your email; at least then you can get to critical emails with Outlook or Thunderbird.

 

When eCommerce Payment Processor’s Fail: A Shift in Philosophy

Posted on August 14, 2009 by josh

On July 2, 2009, at approximately 11:15PM PST, as I was lying snugly in bed, I had nary a clue that Authorize.net was going down. Apparently, there was a fire at the data center. Many of you have probably already read this story; or, perhaps you are/were a customer of Authorize.net's and were made aware by errors. I wanted to share our experience with the major outage and why the lesson is valuable for others in eCommerce. I could be writing a blog post about how much it sucks that Authorize.net even went down, given that it was only one data center scorched. I could be asking, "Where in the world was the backup data center? "Rackspace, how does a sprinkler system kill backup generators? Where is the backup for your backup's backup?!" I could also be writing about how quickly the status was updated on the situation thanks to some smart person at Authorize.net building a Twitter account that day. But this is a post about a shift in our philosophy.

So, as I slept I had no idea that our payment gateway, Authorize.net, was getting wrecked by a fire. When I woke up at about 7:30AM I had already received a text from one of the managing partners alerting me that we had received a pile of errors related to Authorize.net failures. Let me explain what that means for us. An error from our order system that there was an Authorize.net failure means that an order was placed, but no payment was collected. You might be saying to yourself, "Why in the heck would you guys place an order without first confirming that payment could be collected?!" Well, the reason is simple and goes back to our roots. Early on in our eCommerce venture, we prayed for orders every day. Our strategy on many fronts, including payment processing, was to protect orders; in this case, let the customer place the order on the customer site without failure or error (or some other barrier to transaction) and clean up the mess manually. As a consequence of this strategy, when we made a call to Authorize.net for payment processing and it failed, we would have a placed order in our system with no payment from Authorize.net. So, an email with the customer info would be forwarded over to the tech team to review and contact the customer to process a manual payment. This was a good solution for us, early on, as we didn't want to miss a single transaction. We needed the business!

This process worked for us for a good long while, since downtimes on the Authorize.net front were very rare, but when they did happen it was usually only one or two and could be resolved easily. Well, we hadn't had this issue in quite a while and it had not occurred to us that we would need to update our strategy as we grew. Then we grew. By a lot. The consequences of having more than ten times the volume of four years ago becomes readily apparent when your payment processor goes down for more than eight hours. The morning that Authorize.net went down meant that we had a few dozen orders that were placed without payment but had already begun processing for shipment at warehouses across the country. So, we had quite a cleanup effort on our hands. First, ensure that the orders don't get processed out the door, since they haven't been paid for. Second, disable the Authorize.net payment method until we can figure out what happened or is happening and identify when they're back up. Third, contact all of the customers to see if they would like to complete a manual transaction over the phone or retry their checkout using Google Checkout or PayPal (two services that we did not offer at launch). Four, document and share the happenings with the management team. Finally, fix our outdated checkout so that orders do not get placed when the authorization transaction fails.

Our checkout process and a redesign have been on our radar for an update for some time now. This, however, is one issue that escaped us until it became a pain. Hopefully, this will help us to think critically about updates to our site as we examine where we were, where we are, and where we're going.

 

How to Use Metrics Based Customer Connection Rates

Posted on June 16, 2009 by josh

We were recently able to upgrade our phone system. We had spent time, energy and effort to build a better system under the assumption that it would improve a number of important metrics. More importantly, the new phone system made it easier for us to see those metrics. Consequently, I was able to get better reporting on phone utilization, especially as it related to customer service. One of the first things that struck me was our maximum load. We had gone from 8 lines available to 23 lines available. With 8 lines, extra calls would roll over in to voice mail, creating havoc later in the day as we scrambled to try to call people back. Many times, people would call two, sometimes three or more, times to try to reach us. Also, with eight lines, it made it very difficult for us to make outgoing calls during peak periods. With 23 lines, surely we would handle the load. Not so fast! Over the first few weeks I checked our maximum load on all 23 lines and, on several occasions, we had exceeded our maximum load during peak calling periods! We nearly tripled our call capacity and still had overflow. Thankfully, the overflow is not frequent enough, at this point, to justify another 23 lines.

Alrighty then, what about our connect rate? Given all the customers that try to reach us, to what percentage do we actually connect? I was more struck by this metric than our load. Let's just say it was less than half of what we would want it to be. It turns out, we were literally turning away hundreds of calls a week, probably mostly due to long hold time. Even more striking, our average hold time for a connected customer was approaching 30 minutes! 30 minutes?! Dreadful! Sales customers simply will not hold for 30 minutes to buy something. What made this even scarier was the fact that our mix of callers (known by the queue that they select when calling) was more than two-thirds sales calls. We were turning away hundreds of sales a week. This means we were turning away customers who wanted to buy something (and were probably at the end of the buying cycle) in order to provide support to customers we had already acquired.

OK. Now we know. What do we do? We could hire 10 more reps. Nope. Don't have the budget. OK. We don't have an unlimited budget. What else can we do? We could slow down marketing and sabotage our own SEO to get fewer sales calls. Nope. That's dumb. So what do we do then?! How can I get more work out of existing resources? How can we add hours to the day to get more done?... wait... Eureka! We needed more hours in the day! It was ultra-clear that our call and chat volume was much higher earlier in the day than late in the day. Once the clock gets to about 3:45 pm, things tend to slow down. With reps struggling during our rush periods to perform administrative and follow up tasks, it would be near impossible to be more efficient during regular 8:00 am to 5:00 pm business hours. So, why don't we have some reps come in at 7:00 am, instead of 8:00 am, to finish any lingering issues from the previous day and get a head start on the new day before we start taking calls and chats? We could even perform some proactive functions that prevent customers from calling for support reasons in the first place! Why didn't we think of this sooner?! Oh yeah, we didn't think of it sooner because we didn't have great data to stare at.

The effect of having half of our customer service team come in one hour before business hours has been exponential in its positivity. We still have load issues, two or three times a week, during peak times we exceed our capacity. However, our connect rate has doubled! Our hold time has gone from nearly 30 minutes on average to less than 10 minutes! Interestingly, sales are up, but we have reduced our volume of calls and chats by about 10%. Fewer calls and fewer chats, coupled with increased sales, is a strong indicator to me that we are servicing customers more efficiently. We still have a great deal of growth opportunity, but one simple scheduling decision has drastically improved our ability to service customers and, as a positive consequence, also greatly improved morale in the customer service department. Go team!

 

Mobile Capabilities: Changing the Framework of Shopping

Posted on May 8, 2009 by josh

I was struck recently by a video I watched on Fora.tv, Google's Vic Gundotra: Mobile Phones as Answer Machines. In the video, Vic Gundotra describes how he was having lunch with a friend and his four year old daughter. His friend asked him a question and he replied, "I don't know." His daughter piped in, "Daddy, where's your phone?!" At first he thought nothing of it, but then he and his friend realized that his four year old had surmised that when information was needed, one could simply pull out a phone to obtain it. Remarkable! I have a two year old, and even he has displayed what I perceive as a shift in thinking about information retrieval from my generation to his. We were recently watching "Mickey Mouse Clubhouse" on TV and I said to him, "You and I are going to go to the store." He got in the car, climbed into his car seat, and asked me for my iPhone. He turned it on, unlocked it, and started the YouTube app so that he could continue to watch "Mickey Mouse Clubhouse" clips in the car. Naturally I had to search for the clip, but I am amazed that he is aware of this resource portability.

 

On the iPhone at 2 years old

 

Until I owned a "cloud-enabled" phone, I was skeptical of the mobile revolution. Sure, I have recognized Generation Y as the text message generation, but until recently I hadn't seen the utility in being connected to cloud applications via a sensory-based platform. My 49 year old father-in-law once proclaimed to me that online shopping would never overtake physical retail shopping in overall revenues. Though I am sure people will still want to go to the grocery store to make sure their melons feel ripe, I'm not sure I believe that the shopping experience or buying decision process will look anything like it does today in 20 10 5 years. More and more, I use the cloud to make buying decisions. What's more, I find myself diving ever-deeper into my phone while I'm shopping in physical retail stores. Whether I'm doing price comparisons, or reading product reviews, or searching for similar products or services, I find that I'm more inclined to trust information found from reliable sources in the cloud than I am information found at a retailer's store. 

I wonder… how will cloud-connected customers affect eCommerce and vice-versa? More specifically, how will this affect PlumberSurplus.com, OutdoorPros.com, and any other venture we decide to undertake? Well, in order for us to be able to make an impact in mobile, we have to know what success looks like in order to understand whether or not we can execute in an easy and scalable way. With this type of marketing in its infancy, how can we really measure this? 

I came across this article today, Search Giants Encounter Challenges in Mobile Ad Market.  In the article, Frank Reed discusses a company that starts off with mobile ad campaigns running on five mobile Internet networks. After only one day, the company pulled Google and Yahoo campaigns because they were not effective. Frank cites two reasons as the primary hurdles for behemoths like Google and Yahoo in the mobile ad market: "First, the ads that are run on their traditional platform don’t often translate or fit well in the mobile environment... Secondly, the position of the ads on a mobile device will not correspond to the ‘top of the page’ and ‘right hand column’ look that is now ingrained in everyone’s way of seeing and reacting to the ads." These seem like relatively easy problems for resource heavy organizations like Google and Yahoo to overcome over time. However, it's a good indicator to me that mobile advertising isn't mature (certainly not mature enough for a small business like ours to throw money at).

In order for us to be able to be effective in mobile, I think three things need to happen. First, testability. We need to be able to stare at an anticipated baseline of performance and easily test and measure performance. Second, match ad campaigns to targets. Mobile advertising seems like a moving target at this point. This seems pretty tough to do. Finally, figure out how to take advantage of the sensory aspect of today's mobility. Phones have eyes, ears, skin, they know where you are, they know where you've been, they know who your friends are... how do we leverage these to create an experience that leads a customer to buy?

No matter what happens, at this point, I'm pretty convinced that the way my son finds information and shops when he's my age will be very different than the way I do those things now. I can't wait to see what happens next.

 

Internet Downtime: Leveraging Perceived Disasters for Optimal Performance

Posted on April 28, 2009 by josh

I was about to leave my house for work the other morning, when my phone rang. It was Vanessa. I say, "Good morning, Vanessa!" She says, with a pinch of panic and frustration in her voice, "We're down." I panic for a moment; my mind was whirling through yesterday's development activities and I was trying to remember any update or job that we scheduled that could have taken us down. It occurred to me that I was still pretty depressed after watching the Lakers lose to the Jazz in game three of their playoff series and this would not help my already poor disposition today. Thankfully, she was referring to the internet connection at the office and not any of our eCommerce sites. Whew!

Getting the internet connection back up should be easy. We had recently faced an issue with one of our ISPs, so naturally I thought it was them, again. So I go through some steps to test that connection... Everything looks good there. So, I test our backup connection... Everything looks good there, too. Hmmm. I run through some other issues via remote connection, but I can't see why she's down. So, I proceed to work, since I don't have any other network savvy employees on site to help. I know that I'm going to be there late, as I stopped to troubleshoot remotely.

I show up to the office at about 8:10 AM, fully expecting chaos and disarray. I was pleasantly surprised that when I walked in I was greeted by smiling faces and mild applause. People were delighted that I was there to fix the internet connection. But what's more, is people were delighted to be at the office. Folks were chattering and laughing and seemed genuinely happy. It made me feel nice when I walked in. Knowing fully the weight of my responsibility, however, I rushed past everyone to get to the task at hand. A few of my more technical colleagues pointed out that one of our building two access layer switches was freaking out and was lit up like a Christmas tree. Indeed it was. A switch had simply gone bad. So, I ran to my pile o' old equipment to find an extra 24 port switch and a crossover cable.

I worked feverishly to plug in the first few users to test my dead switch theory. ¡Viola! It worked. So I started the task of migrating everyone on the dead switch over to the temporary switch. As I am doing this, I notice noise in the office. Somewhat annoyed, I turn to find people are still talking and laughing. Granted, we work for an ecommerce company and, as a consequence, working without an internet connection can be a challenge. But I was, again, surprised by what I saw. The noise and commotion was coming from people who were cleaning their desk area, vacuuming, cleaning our whiteboards, discussing business strategy, etc. The whole office full of employees was happily chugging along like busy bees in a hive. People were communicating and moving and working outside of their normal routine. As I was getting everyone back online, I noticed folks settling into their desks and getting back to their routines. The noise died down and it was back to business, but a nice tone was set for the day (aside from the catch-up that now had to ensue subsequent to our downtime).

There are three simple observations I had on this morning, few but all important:

  1. Always have at least one backup access layer switch.
  2. A little bit of "downtime" can be a good thing. I'm certainly not suggesting that someone pull the plug on the office internet connection to create downtime! I simply mean that it was nice to hear the camaraderie when I walked in. Maybe I should come into the office 10 minutes early and just greet people as they come in?
  3. Losing the routine for a short period created interesting work of even mundane tasks. People seemed excited to be able to do something other than what they always have to do. Maybe, as a manager, I should consider mixing it up a bit and allow some of my employees to work on other things on occasion?