I am developing a web-browser-based contact form for our public web site. The form allows a user to enter their email address and compose a message. Upon submission an email is generated and sent to an internal email address that we aren't putting on the public site to reduce spam. This is generally considered to be a best and common practice.

There is a conversation going on at the management (PHB) level about this. Because for many years the site did not follow this practice (before my arrival) they are questioning whether sending a message via HTML form would present a poor user experience, which could aggravate a customer if they are contacting us because something is wrong (i.e. they are already "not happy with us").

It never occured to me to think of a web form as an "inferior" experience, and there are ways to obfuscate emails using JavaScript so technically I suppose we could find a way to meet their request should they in fact insist upon it.

However, on the substance of the objection--that web forms are inferior to native client emails--is that true?

4 Answers
4

The obvious upsides for you and the customer are context and efficiency. With a well-crafted form, you will ask the customer for clearly identified pieces of information that will help you respond to them quickly and accurately.

A customer who is bothered by the lack of native mail client support is probably somewhat fussy (big assumption, I know). That same customer is probably going to be much more bothered when you have to contact them again and ask for all the info they left out of their unstructured, free-form message.

If you want to support impatient customers who want quick and dirty answers without the hassle of a form, you should look into chat support through a vendor like LivePerson.

This. If you're looking for very specific pieces of information (vs. a generic contact form), a web form is vastly superior to just giving people an email address and hoping they know what to do.
–
Rachel KeslenskyJan 25 '13 at 3:55

1

@plainclothes - I doubt the user will be bothered if you ask for extra info as it shows that the site is looking at the issue. It will annoy the user if he can see that he sent the info in the original email or web form showing the website has not read it.
–
MarkJan 25 '13 at 11:34

But if you can get that information up front you'll make it so much more efficient. Forms help you get there.
–
plainclothesJan 25 '13 at 17:44

"on the substance of the objection--that web forms are inferior to
native client emails--is that true?"

Oh yes web forms are massively inferior to the users email client. All the ones below are from experience.

With an email client I can write the way I want to, often web forms seem to restrict the text to 50 columns.

With a client I can cut and paste screen shots or attach log files.

With a client I can see what I sent in my outbox rather than the web site swallowing it and I have no idea if it got sent and allows me to resend it when you don't reply.

Basically allowing me to use an email client puts me in control and not have the annoyancies of what you have not got around to code in your small email client which is what the web form is.

Also when I want to email about a web error - what is the chance your web site is not working?

As your bosses note when users find a problem adding impediments to the user reporting the issue is not good customer relations. This especially occurs to experienced users who can provide useful feedback if you allow them.

The converse is for inexperienced users it is easier to write a short not on a web form. Unfortunately there tend to be a lot of these so Gresham's Law seems to apply and the better function tends to be lost which makes responding a massive pain.

I'm of the opinion that log files and screen shots and whatever else the customer may want to provide is better received via a dedicated customer support ticket after the complaint has been validated. Obviously, the follow up should be quick while the info is still fresh in their mind and the logs are still useful.
–
plainclothesJan 25 '13 at 0:26

The email should of course create the ticket in the first place. Why should the customer have to wait possibly losing the data when they have to reboot or just restart apps? The follow up has to be within say 5 mins to be useful or else the customer is doing something else and has forgotten stuff. Why annoy him?
–
MarkJan 25 '13 at 11:14

1

@plainclothes: that is only because it is easier for the recipient, not because it is easier for the sender! I just want to send a message saying "hey, help me on this" instead of having to fill out all sorts of fields that are probably not applicable to my situation, but deemed "important" the recipient (worse if they have made them mandatory).
–
Marjan VenemaJan 25 '13 at 12:36

For "Help!" situations, you should have chat available.
–
plainclothesJan 25 '13 at 17:42

I wouldn't call a web form that sends email an inferior experience but it is a different experience.

On the plus side it's quicker and easier than starting (or switching to) an email client (there's still no alternative to mailto links that work with web based emails, is there?) and the structure of the form can help you get the info you want.

But a normal email client provides meny things the form doesn't, like a record of email sent and received, reply/dialog capability, and other things.

Having both the form based communication ability and a published email address is the best from a customer standpoint.

Redirecting to web based email is often complicated, requiring 3rd party add-ons, etc., so mailto links are (still) often problematic.
–
obeliaApr 13 '13 at 15:31

Two out of the three major browsers support it natively (3/4, if counting Opera) . Chrome+Gmail combo even asks you nicely whether you want to do it. I wouldn't call it so complicated. But if your main target are IE users, then yes it may not be the best choice
–
PowerKiKiApr 25 '13 at 6:25

Some answers have stated strong advantages of native e-mail client. They are real.

But the Web form has a strong advantage too. It is handy to use when I don't have a ready-to-use e-mail client at hand. Or when I don't want to launch it. I am on the Web, I stay on the Web. Quick. No hassle.

Have both.

The good approach is the one chosen by Bare Bones Software, for example. A native contact e-mail link, and a contact Web form. And they tell their snail mail address too, and phone number, and fax number. This is good. And send to the user a confirmation of his/her message. So that s/he have his/her message in his/her mailbox.