Common Sense IT

Kim Albee of Einsof, Inc. talks about how to utilize technology to fulfill business goals.

My Photo

About

Recent Posts

  • Check out my new blog: www.salesxmarketing.com
  • How the Solution Cycle Empowers Companies
  • The Solution Cycle – A Breakthrough Concept For Managing your Online Initiatives
  • The problem of Vision
  • How the IT ‘Status Quo’ Hurts Online Business Implementations
  • The Promise of Technology for Marketing
  • Managing Email Marketing: It's All About Deliverabililty
  • Creating User Demand for Application Functionality
  • The Case for Web Services
  • Application Integration and Web Services

Managing Email Marketing: It's All About Deliverabililty

I have learned a lot recently about managing the sending of emails -- from your website or customer portal/community, or from your marketing DB.  There are a bunch of issues for effectively managing the use of Email technology and ESP's (Email Service Providers) that are great to know about, and to think through.  This post sorts them out so your common sense can go to work -- it's possible to set yourselves and your organization up to win and to improve your effectiveness at email communications.

Before you read further, it might be valuable to check out this article from Direct Magazine, entitled "Five Questions to Ask E-Mail Service Providers".  The article offers five steps to making sure your ESP can help you get your e-mail message safely past the filters -- so you can understand and measure whether your messages are getting delivered, or ending up in your recipient's spam or junk mail folder.  Here's a quick rundown:

  1. Insist on independent inbox and spam folder tracking -- where there are a number of email boxes at all of your key ISP's in your mailling list, so you can get some real data about the actual delivery of emails to their destinations.
  2. Check to see what other mailers the ESP you’re considering services, and think about spending more for a dedicated IP address for your mail.  If you share an IP -- who knows what's being sent, and that IP may end up on a blacklist, and not by your doing -- but you will suffer lost opportunity from mail that doesn't get delivered.
  3. Check into an ESP’s bounce management policies and capabilities.  Get familiar with "hard" vs "soft" bounces and what they can mean -- how does your ESP interpret this information?
  4.    Find out what spam filters the ESP uses for checking deliverability and how they check your HTML code for correctness.  You've got to check with things other than shareware like Spam Assassin.
  5. Look for an ESP with a full set of delivery features -- like blacklist monitoring, whitelisting, abuse board monitoring, etc.

If your head isn't swimming already -- then consider all of your emails being sent -- are different departments using different ESP's?  Are they integrated with your marketing DB, lead DB, customer DB, or customer/community portal DB?

Here's why that's important:  CAN SPAM Act.  It says a few things that you may want to monitor to keep your company out of hot water...

  • Beyond including a postal address and an unsubscribe link that works, you must also pay attention to ...
  • How you provide "opt-out" options.  If you do not provide specific opt-out options for every department or function that is sending emails, then when a user opts out, you must opt them out of EVERYTHING.  Currently you have 10 days to do that -- and that is being reduced to 7 very shortly (and we can guess that timeframe wiill continue to shorten).  So if you've got different departments using different ESP's, then you are advised to ensure that they can communicate that Do Not Email list and make sure they also get them updated accurately.

And if that's not enough, then take into account laws put in place in both Michigan and Utah, that say if you are sending emails for things like guns or weapons, adult content, etc., that you MUST check your email list against their supression file (a do-not-email list that parents can put their children's email addresses on), so that none of the "wrong" sort of emails get delivered to minors.  Here's the kicker -- those DB's are fee-based, soemthing like 7 cents per recipient in your email list.  Ouch!  If you're a B-to-C business that sends out any subject matter that they've outlined in their law, and have a list of 10,000 emails, that's an additional cost of $700 for sending to that list.

Check out an article about the laws imposed by Michigan and Utah, entitled "Michigan, Utah Impose Dreaded E-Mail Tax" posted at the Datamation website in July.

Now, as though that would be enough -- but there's this thorny issue about what are the "statistics" that are most useful when managing your email deliverability.  I spoke with Pivotal Veracity, which offers and partners with many ESP's, providing their deliverability statistics.  Here's what they said:

  • As a base level, you want things like Number Emails Sent, Number that bounced, Number of emails opened, number of emails where a link was clicked.
  • Added bonus is to do domain-level statistics -- so the same as above, but on a per-domain basis for each campaign sent.
  • The BEST is to add the Placement data -- that is, where does your email get delivered at the major ISP's -- to the inbox, or to a junk mail folder?  This is what you can use that will help you determine things like where you could improve your email messages to get better results, and look at various opportunity costs that will assist you to improve your email communications.

So, it's a big world -- and it adds to your integration scenario, and introduces additional "systems" that need to be integrated to your marketing/customer/portal databases.  Knowing about all of this allows you to create workable solutions that are manageable in the total marketing systems mix.

September 13, 2005 in Integration of Systems (webservices, "composite apps", etc), Leveraging the Internet | Permalink | Comments (1) | TrackBack (2)

Application Integration and Web Services

Silos of information are out.  Integrated applications are in.  So how do you start?  Let’s take a look at integration technology called Web Services, and the issues that you’ll need to think about when integrating applications using this technology.

Web Services have been prominently talked about as the technology that allows an easier integration of applications – that works across platforms and implementation similarities.  So you can integrate a Java application with a .NET application in a fairly transparent manner.

Optimize Magazine recently published an article that examines “What’s Next for Web Services?” – and in a nutshell, says the following:

  1. The need for flexibility is driving the interest --- yep.
  2. Speed to deployment and reusability of services is nice too --- yep.
  3. People are actually thinking about interoperability – how to actually have applications talk to one another – let’s call it the “Anti-Silo” Movement. – very refreshing.
  4. There’s more interest in software architects and to designing a model-driven systems architecture that can bring different applications together in a thoughtful way – knowing that a system is always evolving –- don’t get lost in analysis paralysis – think “iterate”.
  5. Pay attention to performance.
  6. Pay attention to redundancy and uptime – absolutely!  A must-have for the view of reliability in the eyes of the users.
  7. Pay attention to your user interface and the user experience, as you bring all this functionality together – the ongoing issue that is also ever-evolving.
  8. Always think about having your systems be browser-based – absolutely… with the occasional need for hand-held support as well.

In my experience, exposing web services and writing web service clients to backend systems for point-to-point integration and customization is a very straight forward process – but it takes thought and communication to ensure that the methods exposed are understood.

The security issues are fairly straight forward to address, and having systems communicate across the Internet is not all that painful when you think about performance up front.

A recent blog post at ZDNet takes a broad look at Service Oriented Architectures (SOA), which is what encompasses Web Services, and the common issues found with web services implementations.  Check out “Politics, business, technology — in THAT order”.

In my view – any dialog with a vendor when evaluating software applications needs to look at the availability of a web services-based interface for integration.  Any vendor that doesn’t have this capability, should have a commitment to offering it as an option.  If they don’t, even if you like the functionality, maybe you’d be better served over the long haul to move on to a vendor who is interested in integrated applications that allow you to provide what you need to your end users.

September 01, 2005 in Integration of Systems (webservices, "composite apps", etc), Leveraging the Internet | Permalink | Comments (0) | TrackBack (0)

The benefit of technology is in the implementation

Computer systems power businesses.  A common question and issue faced by many businesses is how best to invest in their computer applications.  Of course, you want to invest as little as possible for the biggest bang possible.

While the most flexible solution is to write and own your own system – so it works exactly how you want it to – that approach may not be the most effective use of technology for your enterprise.  Owning the code means that you pay for all the bugs and all the fixes and all the upgrades to that software.   The same could be said for where your applications are hosted – on premise or at a hosting provider.  Do you need to own your server hardware and Internet bandwidth?  There are pros/cons and tradeoffs of any approach.

Packaged applications (either on-demand or on-premise) today, are being made available in a more modular fashion on all available operating systems and platforms.  And with the advent of  Web Services, the platform question doesn’t need to be a driver of your selection (for example, you don't have to have everything written in .NET or in the same language).  It’s possible to more easily integrate disparate systems and put together  a “composite application” that will provide business benefit more easily than at any time in the past.

The issue is that we (technologists) hype different technologies, like Service Oriented Architecture (SOA), and get enamored with the technology, and forget that without effective implementations, that technology will never produce anything of value.  Hence the recent post “SOA enters the trough of disillusionment” – you bet – because it’s not about the technology.

We forget that the technology itself will never provide the “silver bullet” that companies have been hoping will arrive, for as long as I can remember.  The true silver bullet is the work that is done to intelligently leverage available technologies into the applications that benefit the business, and deliver the intended results.  It's all in how you use the technology.

What’s still needed is the strategy and the overall blueprint of an organization and how it can utilize technology from the available options – how much custom code is necessary?  Where should an organization invest to get the best leverage for their business?  And this sort of strategy requires thought – but doesn’t need to take forever, which is another concern of most business people – analysis paralysis.

The bottom line is that effective applications are delivered when the IT projects and processes are managed thoughtfully – when business users are getting what they need, and being more efficient and effective in accomplishing their strategies.

Why the success of the on-demand vendors like Sales Force dot com?  Because they deliver what is of value to the business in recording and utilizing the information they need – quickly and effortlessly.  They have implemented technology effectively, delivering results to the business units using their “software as a service” model.

I’ll leave you with the post from Mitch Betts blog post at Computerworld: 
- to me, ideas are worth nothing unless executed. They are just a multiplier. Execution is worth millions.

August 31, 2005 in Integration of Systems (webservices, "composite apps", etc), Making sense of IT | Permalink | Comments (0) | TrackBack (0)

Security: A look at SSL

High on the list of integration concerns, that is, making two applications talk to each other and share information or data, is ensuring that security exists between the two applications.

Another security concern is that if you choose an on-demand vendor or system, that information your company owns is sitting outside of your corporate firewall.  How do you ensure that data is secure?

Many times, not knowing how to examine the issue or ask the right questions gets in the way of a company choosing the best solution for their needs.  This is the tail (of security) wagging the dog (business need and the best functional solution).

I am interested in starting a series of posts that will explore and examine the whole notion of security in a way that will make sense to non-technical folks, so that any issues that arise in the application evaluation process can be thoroughly examined and explored so the best solution can be selected.

The internet has brought to light the need for security, and most of us use the internet to access our bank statements, purchase products or services, and send and receive all manner of emails.

Most of us are familiar with the lock at the bottom of our browser that shows up when we are viewing something securely, or we are completing our credit card purchases.  That is the main security technology that most of us are familiar with -- SSL:  Secure Sockets Layer.

About.com  has the following definition of SSL:

"SSL security technology helps to improve the safety of Internet communications. SSL is a standard for encrypted client/server communication between network devices.

A network protocol, SSL runs on top of TCP/IP. SSL utilizes several standard network security techniques including public keys, symmetric keys, and certificates. Web sites commonly use SSL to guard private information such as credit card numbers."

The Visa website talks about SSL like this:

"SSL provides you with sound privacy protection by encrypting the channel of communication between you and the consumer. Using a mathematical formula, SSL puts the information you exchange into a complex code. Think of it as a kind of armor over the information. Even if intercepted, your data would be extremely difficult to read."

Basically, SSL provides point-to-point security between Server A and Server B, so that data that passes between the two applications is secure in it's transport.

To truly integrate applications safely, however, there are a few more security concerns that we'll cover in subsequent posts... just know that distributed systems have existed for over 20 years, and the Internet is making it easier and easier to create the cross-organizational integration of work and systems that will lead to greater productivity and greater potential for effectively using technology for business advantage.

August 22, 2005 in Integration of Systems (webservices, "composite apps", etc), What about Security (SSL, etc)? | Permalink | Comments (1) | TrackBack (0)

Categories

  • Enabling Sales & Marketing (CRM, Portals, Extranets, etc)
  • Integration of Systems (webservices, "composite apps", etc)
  • Leveraging the Internet
  • Making sense of IT
  • Thinking about ROI
  • What about Security (SSL, etc)?

Subscribe


  • Subscribe in NewsGator Online

On effective
Marketing Interactions