If there’s any offer that should have a conversion rate of 75% or more, it’s the renewal. In other words, the customer has been doing business with you and likes the product, but their existing subscription period or term is almost over. To extend this relationship, all you need to do is get the customer’s consent and verify their payment info.

Despite how easy this sounds, companies screw it up all the time by asking for tons of extra data. As a buyer, these hiccups and annoyances make me think the company doesn’t value my business, and I start to look elsewhere. After all, if renewing with the existing vendor doesn’t save any time compared to finding a new vendor, what’s the incentive to stay put? In many cases, there simply isn’t one.

How can you prevent this? Start by paring down the list of things that you’re asking renewal customers to provide. Do you really need the password they chose when they first created an account two or three years ago? Is it critical for the customer to recall the exact way they typed their mailing address before they moved to a new home or office? Probably not. Yet companies insist on this meaningless data all the time. And when customers can’t provide it, the companies just send them packing with the ever-familiar “Sorry, you’ll have to create a new account.” Next stop: a competitor who sucks less.

Ok, now for the solution: If someone has an existing relationship they want to renew, but they don’t have the other account credentials like the old password or mailing address, then just take their payment info and be done with it. Sure, they shouldn’t be able to change any of the terms of the deal without verifying some other info (e.g. resetting their password), but it’s foolish not to take money from those who just want the existing service to continue unfettered. Since the real loser in the overly-complex renewal is the buyer whose time gets wasted, your customers will thank you for acting sensibly, too.

I tried a new breakfast place on Sunday. The server was friendly, the food came out quickly, and everything tasted right. But nobody offered a single refill of coffee after the food arrived, so we sat there with empty coffee cups for quite some time. During that span, our server was apparently on break, but at least two other servers walked by several times each. One of them even sang Happy Birthday to a customer in the table next to us.

From what I can see, the management and staff at this restaurant have yet to recognize the value of teamwork in a service business. With a small amount of extra effort, the servers could fill up other tables’ coffee cups as they walk by, rather than being blind to these other customers. Sure, it wouldn’t increase the tips for their own tables, but more customers would leave happy. Ultimately, that means more tables filled and more revenues to go around. But as it stands today, I’m certainly not going back.

Teamwork is a huge asset when you’re trying to deliver a consistent experience for customers, as others on the team can compensate for one person’s off day. Experiences like mine, where teamwork is nonexistant, serve to illustrate just how powerful this impact can be.

When working with any type of software tool, the ability to quickly test and refine your work is usually a given. In other words, you can typically preview what you’ve created on your computer screen and make any desired corrections before it goes live. We see this all over the place, like in the form of your browser’s Print Preview option, or your blog software’s choice to Preview a Post. With this in mind, I was quite surprised to come across an email design tool that provided absolutely no way to send a test copy of the message.

Let me provide some context. The tool I was using is intended to let you write email messages in both HTML and plain text format, and then send them to one or more contacts. It gets most of the basics right, including showing you a preview on-the-fly. But when you’re ready to test out your email by sending yourself a copy, you’re out of luck. There’s no button to Send a Test Message or anything like it. Alas, the only workaround is to add yourself as a contact in the system, and then send yourself the message. By this point, you’ve wasted an awful lot of clicks to accomplish what should be a straightforward task.

In the end, the best approach is to think about your typical customer’s workflow. Once they finish with tasks A and B in your software, what do tasks C and D look like — even if they’re performed outside your product? Can you add a preview or testing feature to save people time or hassle when completing the overall process? Maybe the answer is as simple as letting them send a test email, or showing how a banner ad looks in various website designs. By asking the right questions and helping users streamline their workflow, you can increase customer satisfaction and drive greater usage of your products.

There are many anecdotes that teach us to be wary of unusually low prices. In my experience, this is especially relevant when you’re buying something that involves an ongoing or recurring relationship with the seller. Regardless of how you scored the deal — whether by taking advantage of a novice sales rep or using questionable negotiating tactics — someone at the provider is eventually going to re-evaluate your account. And when they see how grossly unprofitable it is, they’ll either raise your prices, reduce your service level, or terminate the relationship altogether. In each case, you’ll probably be worse off than if you had just struck a fair deal in the first place.

Most people have a difficult time explaining problems with their computer or any other piece of technology. Instead of providing useful details like what they were doing when the problem took place or what sort of error they received, the typical person just reverts to saying “It’s broken.” To make things easier on customers and technology providers, I propose a simple solution: explain computer problems just like you’d tell your mechanic about problems with your car. Here are some questions to get you started:

“When did the noise start?” In other words, how long have you been having the problem?

“What does it sound like?” Describe the problem and any error messages you saw.

“What are you typically doing when you hear it?” What action immediately preceded the problem? In other words, what were you trying to do and what did you expect to happen when you got the error instead?

“Does it happen all the time or just some of the time?” How consistently can you reproduce the issue? Can you make it occur right now if you want to?

“Have you changed anything lately, like the gas you use?” Did you switch to a new web browser, upgrade your computer, or install new programs?

If users were to compile even a little bit of this information before reporting an issue, the time and effort required to resolve problems would drop significantly — leading to a better customer experience. Similarly, tech providers might want to offer up a similar list of diagnostic questions when the usual report of “the damn thing’s broken” arrives at the call center or in the support mailbox.

I received a package from a reputable mail order company yesterday. Inside, in addition to the products I purchased and a packing slip, was an envelope entitled “Special offers for our most valued customers.” From the title, I would have expected to find a collection of highly-targeted, exclusive offers inside. Instead, what I got was a pile of ads for unrelated garbage, like hunting knives. This is exceedingly lame. If you’re going to spam people like this, don’t set overly high expectations by sugar coating what’s in the envelope. “Promotional offers from our sales partners” would be more like it.

The way you end your error messages can have a big impact on how the user perceives them. Here’s a quick overview of what each type of punctuation says to the reader:

– Period or no punctuation: Simple and direct, the message comes across without any specific tone.

– Question mark: Polite and unintrusive, this is like saying “Perhaps you ought to consider…”

– Exclamation point: Loud and confrontational, this tends to make the message seem like an insult. It should be limited to cases where you need to warn the user about a truly dangerous situation.

– Emoticon: Playful and informal, I’ve never really seen smileys or other emoticons used in error messages. However, I think they can be useful when you’re trying to impart a more casual tone or offer advice.

Although these may seem like subtle differences, they can affect how the user interprets your messages, and ultimately how they feel about your product.