< back to full list of articles
7 Steps Toward Highly-Effective Web Sites, Part 1

or Article Tags

How do you save money, stay safe, and get what you need as you develop

your Web site to sell your books and promote your company? Simple, you

think about the Internet strategically. You demand that Internet initiatives prove themselves now, not in the future. You push your technical personnel to give you data–raw numbers, hits, visits, click-paths, e-mail counts–whatever might help them and you figure out how users convert to customers.

More specifically, I suggest a seven-part system. Read on for the first steps and watch for Part 2 of this article for the rest.
Step #1: The Sacred Torch of Uptime

First assumption: You’re on the Web for business reasons, not vanity. And since your goal is to sell your books and services, time plays a huge factor in how high your numbers can go.

No amount of marketing whiz-bang can make up for lost sales from people who can’t even get through your Web site’s front door. This no-brainer–”Keep your site up and servers running fast”–is as fundamental to your Web success as dribbling is to basketball. Slam-dunks get the applause, but you don’t get down the court without basic skills.

How many customers click off your site because it loads slowly or incompletely? A lot. And you can’t sell them if they never make it inside.

Quality ISPs refer to uptime as a sacred torch–there’s absolutely no excuse for unscheduled outages. Sure, things break and people make mistakes, but this generation of hosting solutions is entirely redundant and designed to prevent the effects of entropy.

How far do the major players take it? When I toured a state-of-the-art data center in the Southeast recently, a technician informed the group that if the world ended its sites would operate for another seven to ten days without a human around.

Sound extreme? Maybe, but do a little math. If your site is not accessible for an average of only 20 minutes a day, you’re losing almost a week of sales annually. If your site goes down every time a local power grid has trouble, you’ll probably have worse numbers.

Every site’s goal should be to load faster than its competition with no downtime.

Test #1: Uptime

How do you evaluate your ISP’s attention to uptime and the ability to keep you up?

Here’s a quick test:

  • Casually ask your ISP about uptime. Quality players will respond energetically and in detail, especially since redundant connections, backup power, and fail-over hardware requires a major investment on their part. If they’re committed and qualified, they’ll tout it. If they’re not, they’ll impress you with some quick numbers and move on.
  • Get an uptime guarantee, sometimes called a “network service level agreement” or SLA. If the operation is confident, they’ll issue you one. The guarantee probably won’t yield much cash in the case of downtime, but make sure it voids any time commitment on your part. That way, you’re free to change providers if downtime does occur.

 

Step #2: Find Quality Partners with Global Resources

You need to find hosting partners who share your commitment to uptime. At the same time, you want to avoid situations that require you to sit on hold with technical support while your site is broken. You want responsiveness coupled with reliability and infinite resources. Can you have both? Yes.

Work with smaller, customer-facing technical firms that have solid partnerships with technical and telecommunications giants. Working with smaller firms day-to-day means your site gets the personal attention it needs, and if something goes wrong, you’ve got the owner’s home phone number. It also means your site evolves quickly, development times are short, and the people involved are accountable.

In turn, these smaller technical firms should have relationships with companies such as IBM and AT&T, the big dogs that bring in the “burstable bandwidth” the multi-million dollar data centers and the infinite technical support staff. The world of bandwidth, co-location, and server management is shaking out, and only a dozen or so of the biggest players will remain when the dust settles. They’ll run the heavy machinery, and you should demand access to it.
Test #2: Hosting Provider

So how do you evaluate small ISPs and development houses? How do you

figure out how deep their resources run? Here are some tried-and-true

methods:

  • Ask them for a list of their tech partnerships. This will get you started. Dismiss those that push their own abilities to the point of discounting partnerships and major players. No one can do it all themselves anymore. That’s a fact.
  • Get specific. Where will your site be physically housed? Inspect the location. Is it behind three feet of concrete with 24-hour security personnel? Do you have to go through a mantrap or biometric scan to get in? How many backup diesel power generators are onsite, and how much fuel is in the underground tank? This may sound like overkill, but this kind of hosting is the currently the industry standard, even for your mom-and-pop Web host. Accept nothing less.
  • Get documentation on the network resources. Where does the Internet

    connectivity come from? There’s always an “upstream provider” such as

    AT&T, UUNet, or some other telco. What should you look for in an upstream

    provider? For starters, ask how many of these Internet backbone connections come to your box? One, two, three? You need at least two.

 

Step #3: Inject Marketing Requirements Early

It takes a lot of different skills to build and manage Web sites for maximum sales and exposure. These skills rarely coexist easily, since designers will want things elegant, programmers will want things to fit neatly into boxes, and marketing folks will care only about the traffic and sales numbers. Whose requirements take priority?

That’s easy–the marketing folks. You’re not on the Web to win awards or invent a new operating system–you’re there to sell your company, sell your books, and make money. Anything and everything you build should be shoved kicking and screaming under the marketing microscope: Does this feature or button increase my visibility and my sales?

The friction between the various site objectives–attractive design, efficient programming, and effective marketing–will be intense. Programmers will whine that the system won’t support the kind of selling the marketing folks suggest. Designers will roll their eyes when you replace nice graphical buttons with ugly Web text.

But you’ve got to do it.

Make it known to everyone involved that, for you, sales wag the dog. If a particular design element or technical feature increases your sales and qualified leads, then it stays. If not, it gets replaced with the next big idea. Challenge everyone–in-house and outsource vendors–to keep proposing these big ideas and publicly reward the creators when they work.

Pretty soon you’ll have a team that is focused on your bottom line and continually feeding you new initiatives that you can take to the bank.

Test #3: Outside Developer Marketing Test

Since many PMA members work with outside design and technical firms, a question has probably popped into your head: How do I evaluate the marketing expertise of a technical partner?

That’s not as hard as it seems. Just don’t mention marketing and see what happens. After one meeting and a 10-page site proposal, you’ll have plenty of proof one way or the other. During that meeting and in that proposal:

  • Did they ask about your sales goals or current marketing initiatives?
  • Did they propose new Web and e-mail based initiatives?
  • Did they propose detailed tracking of visitors to test initiatives?
  • Did they propose technologies and production techniques that are

    search engine friendly?

  • Did they propose site features that are 100% accessible across all

    computer platforms and browsers?

Avoid firms that value design or whiz-bang over marketing. It’s a company culture that’s not easy to change and why should you have to try? There are lots of projects out there that can benefit from splashy gateway pages, spinning logos, and flash intros. Your publishing business isn’t one of them.
Step #4: Keep Your Site Portable

Vendor lock-in accounts for most Web horror stories I read and hear. It

even beats security breaches (covered below), both in terms of frequency

and cost.

Here’s what happens. A publisher wants to establish a presence on the Internet. The publisher finds a developer or a piece of software that can help do that. This publisher buys into a solution and launches the site. Weeks, months, or years later, there’s a problem. The site starts crashing, a new feature can’t be added, or orders of the new book can’t be integrated with a new order management system and has to be re-keyed by hand.

The publisher starts shopping for a new solution since the old one has obviously been outgrown. But the publisher quickly realizes that major pieces of their site are not only owned but also controlled by the first partner, and can’t be taken to the new partner. Publisher is stuck, angry, and sad.

Proprietary tools are extremely common, whether you’re dealing with a big company like Microsoft or a small, hometown development firm or ISP. It’s an old-world tactic–lock the customer into your products and services by making it extremely difficult and costly to work with someone else. Such companies refer to their solutions as “proprietary” and voice concerns over letting another firm (or sometimes even you) look over their code.

If you’re just starting out, avoid vendor lock-in like the plague. If you’re already tied to a vendor, start working your way toward portability–even if you’re 100% satisfied.

Review contracts, get digital copies of source photography, copy, and Web

pages, and also regularly updated copies of your site on CD-ROM. A good

technical partner will understand your concern and work with you to make

sure you’re comfortable with your situation. A bad one will ignore your

phone calls and resist at every turn. Flag on the field! Somebody is about to get penalized. Make sure it’s not you!

[level b subhead] Test #4: Reading the Fine Print

So, how do you maintain portability? Here’s a checklist:

  • Make sure all development work is done under written contract. Read

    the fine print.

  • Most developers will demand copyright over their code (there are complex legal issues here, but they have valid concerns), and that’s fine. What you care about is your license to use that code. First, do you have access to the source code? You should. Can you (legally and technically) take your site and run it somewhere else? Can others legally modify that code in the future to add features? All answers should be “yes.”
  • Arrange to get copies of all source code regularly on disk.
  • Evaluate your developer’s response to your questions concerning portability. Are they responsive and helpful? Do they fight it?

It’s a new world. In the old days, only musicians had to worry about being tied to their first agent. Technical portability assures you that your Web initiatives can grow and thrive unhindered. You may find yourself using one fantastic vendor all of your life. But maintaining portability will keep them on their toes and assure that they keep you in the front of their minds.


A former magazine executive editor at Rodale Press, self-publisher David Taylor is a partner in the Savannah, Georgia-based Web development firm Color Maria, Inc. (www.colormaria.com). You can purchase his latest books at www.freelancesuccessbook.com or www.peakwriting.com, both

located behind double firewalls hosted in an Atlanta data center once

used as a NORAD command post.

Connect With Us

1020 Manhattan Beach Blvd., Suite 204 Manhattan Beach, CA 90266
P: 310-546-1818 F: 310-546-3939 E: info@IBPA-online.org
©2016 Independent Book Publishers Association