Why You Should Have an HTML Email Signature

Email is often the primary communication method used by businesses and your email signature makes an impression on every recipient and all those people who may see your email as part of a chain forwarded up and down an organization. An HTML email signature block, instead of one created using plain text or Outlook's signature editor, not only looks more professional it avoids the annoying "all my emails contain attachments" issue in Outlook.

Microsoft Outlook is still considered the corporate standard for desktop email and one of the handy features available in Outlook is the ability to easily see which emails contain attachments as indicated by the paper clip icon (makes one wonder if this is the long-lost little brother of Clippy). But if you include your corporate logo in your email signature line as an embedded image, then Outlook will show every email you send as having an attachment -- even your own-line replies -- because of that embedded image. A better way to include your company logo is to use an HTML signature and link to the image file online. With that, Outlook won't see the logo as an attachment and it will still look fine when viewed by recipients.

And that's not the only benefit of using an HTML signature: you can also do much more to customize and format your signature. For example, the logo can be shown alongside your contact information, on either side. You can also include clickable links and icons for you social media pages, colored backgrounds, and more.

Here's an example of my email signature at it appears in Outlook or Gmail's composer view:

There are several ways to get an HTML email signature:

Create Your Own HTML Signature

If you're ambitious and know a bit of HTML, you can create your own HTML signature. You'll have to host the graphics files on a server somewhere. Mine are on Squarespace, but you can use a free service like imgur also. I didn't choose this route because getting everything to look just right would take me a lot of time. If you want to give it a try, you might start with this tutorial by Dustin Hartzler.

Use an Online Service

There are several online services that will allow you to create a beautiful HTML signature block. Some of the options are free but most are subscription services that allow you to make changes to your signature any time. For example, htmlsig is free for the ad-supported version or $5 per month for the basic, ad-free version for up to 50 signatures. WiseStamp provides a similar service, also with a free option or a $4 per month option.

Here are some samples of what your signature block could look like using htmlsig or WiseStamp:

Farm It Out

This is the option I chose. I use Fiverr and found a web designer who created the signatures you see above for $10. There are dozens and dozens of designers who can help you, so I suggest your run a search on Fiverr for "html email signature" and find examples that appeal to you. FYI, I chose designertweet to do mine. The designer will work with you via email to choose a design based on your logo and what you'd like to see. The result will be a text file containing the HTML you'll need to use for your signature. You'll still need to host the image files somewhere and modify the embedded links in the HTML to point to the proper location for those files. Most designers also include instructions on how to do this and how to use the new HTML signature in any of the popular email programs. If not, you can find that via Google.

Having an HTML signature is so easy and the result looks so much better than a standard Outlook or Gmail signature that you'll be surprised you haven't done it before. Get some great design ideas with Mary Stribley's "10 Best Email Signature Design Case Studies [With Tips On How To Create Your Own]" article.

Kenny Hoeschen
Tips on Drafting Vendor Form Agreements

My practice is tilted towards representing licensees and customers who are looking to license software from established software vendors. As a result, I have reviewed countless vendor software license agreements, hosted software/SaaS agreements, service level agreements, and all the related forms and attachments that make up those transactions. However, I also occasionally represent vendors and have assisted in drafting the vendors' form agreements.

In this article, I'll share a few things I've learned on the way by observing these transactions from both sides of the negotiation table.

/1/ Get the Business Team Involved Early

Drafting any new agreement involves considering and including a long list of contract boilerplate language; for example, limitations of liability, warranties, the license grant, venue, and termination rights. Of course, these provisions are necessary to include in the final agreement, but the vendor business teams must also be involved in structuring the form agreement.

The software teams should be involved in provisions related to warranties or service levels involving system availability, any third-party embedded software that may require additional licenses or terms, requirements related to the customer's technical environment, and similar areas. The finance department may wish to have input on the term of the agreement, invoicing and payment terms, and even acceptance testing language. And certainly the sales team will wish to get involved to ensure the agreement contemplates what their customers are typically looking in an attempt to avoid later roadblocks or objections.

/2/ Structure the Agreement to Make it Flexible

The attorney drafting the form agreement must consider the lifecycle of a transaction, which may include proposal responses to RFPs, product demonstrations, customer due diligence, and a number of discussions between the vendor technical and sales teams and the customer representatives. And these discussions all probably take place before any in-house attorney is asked to get involved.

One way to stay out of the way of the early deal negotiations is to provide the business teams with a flexible contract that gives them certain freedoms to change the agreement to reflect the unique transaction being considered. Putting a legal document in front of the customer early in the process may also bog down or sidetrack the process. Instead, consider structuring the main body of the agreement to contemplate some of the different requirements that may come from the customer and keep the business terms segregated into the exhibits. With the negotiable items like contract term, license scope, pricing over time, and delivery schedule all contained in the exhibits, the vendor and customer teams can work together to structure the agreed transaction details before needing to get involved in the details of the main body of the agreement.

/3/ Consider How "Aggressive" the Agreement Should Be

Another area that will involve discussions with the business and sales teams is how aggressive the vendor wishes to make the agreement. This will depend greatly on the negotiation strength of the vendor, the willingness of the legal and sales teams to support what may be a longer negotiation, and the generally view within the market for strict contract language.

If the vendor has a strong position in the market and an established reputation, they may be able to present a very aggressive agreement and hold firm during negotiation, allowing little change. On the other hand, sophisticated customers will consider the contract provisions as part of the overall evaluation of the vendor solution and, if there are other viable options to the vendor's software in the marketplace, an overly aggressive form contract may make the customer consider the relationship with the vendor a "non starter" and move to friendlier pastures.

/4/ Position the Document for Negotiation

The other side of the equation when considering how aggressive to draft the form agreement is to look forward to future negotiations involving the document and consider how the business would like those to play out. Obviously, an overly aggressive agreement will require additional negotiation time from the business, sales, and legal teams. Another approach is to consider drafting a document that is generally fair to both parties with the hope of positioning it in that manner with the customer and fast-tracking the negotiation which will involve only a handful of issues. Of course, the risk in coming to the table with a balanced agreement is that the customer may still negotiate the agreement intensely which may lead to a long negotiation anyway or an agreement that now favors the customer over the vendor.

agreementsKenny Hoeschen
Service Levels: A Better System Availability Service Level

As I've pointed out previously, one of the primary service levels in just about any cloud computing / SaaS agreement is system availability. While there may be an exception in some cases where the availability of the system to the customer is far outweighed by other performance factors, it's rare that the availability service level is not considered the primary measure by which the vendor's performance is measured. This makes perfect sense since the customer's use of the system in a hosted environment is wholly dependent on the vendor keeping the system available and performing appropriately.

Is the System "Unavailable"?

The vendor's standard service level agreement most likely contains a default availability standard with service level credits in the case where the service level is not met over the period of measurement. For example, we might see a 99.9% System Availability Service Level measured 24 x 7 over each month. In this case, if the system is "unavailable" more than about 43.8 minutes in a month, the corresponding service level credit will be triggered. There are a number of items to look at closely when considering the appropriateness of this service level, but for the purposes of this post I'll focus on the term "unavailable."

With the vendor's starting language, "unavailable" is typically defined along the lines of "The Customer is unable to access the Services, excluding any downtime caused by an event outside of vendor's reasonable control." In some cases, the vendor may even require the customer to report a period of downtime before it will affect the service level. But this definition doesn't begin to capture the customer's needs for system availability.

A Better Definition

To begin, the concept of system unavailability cannot be dependent on the customer's reporting of the outage to the vendor. The vendor may try to persuade the customer that this makes sense because an outage that the customer is not aware of doesn't really affect the customer and therefore shouldn't trigger a potential credit. But one must remember that many systems may be used across company divisions by a large number of employees. An employee trying to complete the week's payroll entries in the accounting department in Poughkeepsie may experience an outage that doesn't allow her to complete her work yet may have no idea that the outage should be reported to the vendor or even where to begin to report it. Instead, the vendor is best suited to continuously monitor the system availability and report the metric to the customer.

Second, unavailability must be tied not only to the entire system but to the significant operations of the system. For example, it's entirely possible that a system is up and running but the availability to transmit electronic financial transactions isn't working. If that function is key to the customer's use of the system, then its unavailability should trigger the downtime remedies just as if the entire system were down.

Finally, as I'll discuss in more detail in a future post, a force majeure event should generally not provide an exception to meeting the availability service level. Essentially, a force majeure exception avoids the essential purpose of the system availability service level.

Sample Language

Here's an example of an availability service level that meets the customer's needs:

Vendor will provide at least 99.9% System Availability, measured on a per calendar-month basis. "System Availability" is defined as the ability of a Customer user to (a) access and transmit electronic payment information using the System, (b) record employee payroll information, and (c) generate ad hoc and month-end management reports. Loss of Service Availability caused by (i) Customer’s acts or omissions; (ii) Customer’s Internet connectivity; or (iii) Vendor's regularly scheduled maintenance windows as defined below will be excluded from Service Availability calculations.