I’m no expert on how to name a new product or company. But I can certainly spot a bad name when I see it. Here’s one sign that your name is going to be trouble: there are three or more ways to spell it, and none of them looks “right” to the average customer. In fact, I was trying to look up a company like that in our CRM system today, and it took me like five tries to get it right. Sure, your proposed name might be clever, but is it really worth all the missed opportunities when people — even existing customers — can’t find you? Stick with a name that normal people can actually say and spell, and you’ll have an easier time attracting repeat buyers and leveraging word-of-mouth.

If you ask a customer a question and they refuse to answer, it probably means something. Here are a few possible explanations:

1.) You haven’t earned the right to an answer, e.g. you’re asking them to fill out a 50 question survey when you routinely ignore their tech support requests.

2.) They feel nothing good will come from answering honestly, e.g. your company has a history of ignoring constructive criticism and never makes any changes to fix the underlying problem.

3.) They’re afraid to give you bad news, e.g. they don’t want the upgrade you offered or they plan on cancelling their account, but don’t want to tell you yet.

So if clients routinely ignore your inquiries, perhaps that piece of data is more useful than what you asked for in the first place.

I placed an order at Amazon.com last weekend and they shipped it the following business day. When I got the shipping confirmation, it said the package was sent UPS ground to arrive in… 21 days. Sounds a bit sluggish to me. I knew the order was being fulfilled by a different merchant (rather than Amazon itself), so I just ignored the estimate. Sure enough, the package arrived in a few days, just like I expected.

I’m going to guess that my ridiculous arrival estimate was generated by the merchant who fulfilled the order, since Amazon’s own estimates are usually pretty accurate. In this case, I bet Amazon just reprinted what the merchant gave them, without performing a reality check on it. Even though any sensible person could tell that the estimate was off by several weeks, Amazon made no attempt to let me know that I had received bogus data.

This brings me to my point: if you rely on third-parties to provide data that your customers will be seeing, it pays to do whatever you can to validate that info. With something like a delivery date, it’s especially easy to compare the data you receive against a set of rules to see if it makes sense. Otherwise, you could be giving your customers some very confusing messages, and hurting your brand in the process.

Sometimes we get so used to dealing with bugs in the products we use that we forget these defects even exist. In other cases, we’re acutely aware of the issue but we stop using that feature for other reasons, so the problem fades from view. For me, the file upload window in Salesforce.com is a great example of this dynamic at work.

A few years ago, I regularly uploaded a lot of files to Salesforce. The first few times I did a large upload, I tried to minimize or hide the window so I could do other work. Without fail, the window would disappear, but nothing was uploaded. Eventually, I learned that if you don’t leave the window in the front, the process is cancelled — without any warning, of course. From that point on, I became accustomed to this silly process, and didn’t think much about it.

Fast forward to the present. These days, I don’t upload files to Salesforce very often, but I needed to send a big document yesterday. So what did I do? Having forgotten the “right” way to babysit the window, I tried to minimize it after the upload began. And just like old times, the process was cancelled instantly. Apparently, nobody at Salesforce saw fit to fix this in the past 18 months or so. Because I only use the uploader once in a while, I got to rediscover this bug anew.

What’s my point here? I guess you could sum it up like this: Frequent users often become accustomed to bugs in your product, and may never tell you about them. New users, or those who are coming back after a long absence, are more likely to notice these issues. So the next time you’re thinking of ignoring a bug report because the person reporting it is a newbie, you might want to think about whether that perspective makes their feedback even more valuable.

If you’ve ever sold products to large companies, you’re probably quite familiar with Request for Proposal documents, or RFP’s. I could write volumes about how much I dislike the RFP approach to procurement, but that’s not my focus today. Rather, I want to talk about a peculiar feature of a recent RFP that we received. For some unknown reason, no matter where you click in the 100-page document, it immediately brings you back to the first page.

Obviously, anyone reading through such a huge file probably intends to highlight important points or copy and paste some text into another file. But the “go back to the beginning if you click anywhere” rule makes that rather difficult. Frankly, I couldn’t even explain how the authors made this occur. Maybe they defined a bookmark or section heading wrong when they designed the file. Or perhaps they intended to “lock” the text so people can’t copy it. Who knows. As it stands, the result is incredibly annoying to the reader.

More generally, I’d like to point out that many of the teams creating these documents are quite overworked. Others are just lazy. In either case, they cobble together hundreds of questions from old RFP’s or stuff they copied from the web, and then expect the recipients to sort it out later. Maybe I’ve just been exposed to a lot of poorly-written RFP’s. But if I had to guess, I bet my experience with these documents is quite similar to what others have seen.

At any rate, if you ever need to create an RFP for your own company, I would strongly encourage you to give it a thorough review before you send it out. See if the questions make sense, and look out for annoying issues like the one I’ve described today. By doing that, you should get more accurate and concise answers from the responding companies, which makes your selection process a lot easier.

We’ve all been there: You’re typing a bunch of text into a website or application program and you’re just about ready to press Save. At that very moment, the computer crashes or you accidentally hit the secret key combination for “quit now without asking”. Sometimes, the program is smart enough to recover where you left off, which is great. Other times, all your work is lost forever. With these cases in mind, what really makes me crazy is when a program says it’s automatically saving drafts as you type — but then it gives you no way to retrieve the files later.

I know that it’s very difficult for some programs to provide autosave functionality, and that’s fine. All I’m asking is that when a program says it’s saving your work, it should actually be doing that — while providing you with an easy way to retrieve the files later. Otherwise, it gives users a false sense of security and creates hostility when people learn they’ve been lied to. In short, if your autosave or recovery feature doesn’t work exactly as advertised, you’re better off just taking it out entirely.

Inspired by a brochure I saw yesterday, here is some text to look out for before publishing your new documentation or product specs:

1.) “Need this updated.”

2.) “This can’t be right. Didn’t we fix this before?”

3.) “Clean this up before anyone sees it.”

If you’ve ever let this sort of thing leak out in your documentation or website, you know how embarassing it can be. My recommendation: highlight any placeholder text in a bright color like pink or purple, so it’s easy to see what needs to be dealt with in the final revision phase.

When I was in college, I took my car in for some body work. You see, some idiot keyed the whole side of it when it was parked, so they had to repaint the door and fenders. When I got the car back, the damaged area looked great. But the excitement wore off quickly when I noticed all kinds of scratches on the wheels, cracks in the glass, and other damage. Outraged, I asked the dealer what was going on. He said yeah, his people did all of that, but it’s not the dealer’s fault — these things happen when you take panels off for repair. Surely I had read this in the disclaimer before I signed it, he reminded me.

Of course, this story is fictional. But a very similar thing took place when I had my floors redone by iFloor.com, and I get the feeling it’s quite common with other home improvement work. Even though I only had the floors replaced, the installers managed to put cracks in the drywall and leave glue in areas that are nowhere near the floor. When I asked if they could come touch up the areas, they said it wasn’t their responsibility. Apparently, I was supposed to sign a form, aptly titled “Great Expectations,” that detailed all the ways they would be messing up my place. Ironically, I never received any such thing.

But even if I had read and signed a document saying they might trash the place, that doesn’t make it right. In other words, telling your customers that things might go wrong doesn’t give you a license to be negligent. Too bad iFloor doesn’t understand this. So now I have to re-spackle and paint lots of areas myself, and it certainly makes me hesitant to recommend iFloor to others. Their product is very high-quality, but they burn all the bridges when the installation takes place.

Whether you’re in the home improvement business or you sell enterprise software, my advice is the same. If you want customers to sign a disclaimer so you’re not responsible if things go wrong, fine. But at least put some effort into minimizing those problems. Even if you think you’ve trained people to expect common mishaps, they’ll still be mad at you when they’re left cleaning up the mess.