Pro Tip: Better Website Update Requests

Pro Tip: Better Website Update Requests

In a previous post, 7 tips for better tech support, I discussed some of the issues facing the client-vendor relationship when it comes to getting things fixed around the office. This also applies to requesting website updates.

This time, we’re going to take a look at some tips to make your actual support request more effective (read: it gets resolved faster). If I’ve left any off, leave them in the comments. If this seems like a rant, well, at least it’s the productive kind.

1. Set the stage with a good subject line

If I had a nickel, even a penny, for every time an email came through with “website” in the subject line, I’d be sitting on the beach, retired, sipping a cocktail with one of those plastic swords skewering fresh fruit picked off the tree behind me.

“Website” tells me nothing.

It could mean the website is down, the website has a broken link, or that you want to discuss the website in a strategic fashion.

Good Subject Lines

“Website update: new About section” – tells me more, doesn’t it? What am I expecting in the body of the email? That’s right, the updates to the About section. I’m on it.

“Question about search results” – I know specifically what you’re talking about, and am ready for you to lay out your search scenario in the email, so we can figure out what the issue is.

“Need help with ‘X’ feature” – Again, you’re driving me directly to the problem area.

Bad Subject Lines

“Questions about our website” – still too open-ended, it could mean anything.

“XYZ Company website” – no kidding…your email address, you@xyzompany.com, gave it away. Take away the company name, we’re back to “website”.

“I’m going to put the entire request into the subject line because I think it’s easier for both of us” – this isn’t an actual subject line, but you get the drift. Don’t do this, we’re only going to see the first 70 or so characters. If we use a help desk system, it will chop it off even more.

2. Be as specific as you can

Support personnel are not mind readers, nor do we know exactly what you were doing when something broke. While your email subject line may have given us a frame of reference, you now need to pull the rest of the request into a complete thought so we can get to work.

Content

New content, replacing content, graphics, moving things around, etc., are all task-based requests. Give us the exact marching orders, and the supporting content, you’ll be all set in no time. We do these in our sleep.

Training/How-To

Screenshots help if you’re trying to explain something you see on your screen, like an unexpected result of a content update. Being able to visualize where you’re stuck is a huge step toward getting you on the right track.

Copying and pasting the URL of the place you’re stuck is another good practice. That lets us go directly to the same page and proceed with the rest of the description of your problem. In many cases, while you have us there, we might even just make the update for you!

Also, explaining what you’re trying to accomplish (and why) is also very important. Knowing the expected outcome will make sure your support staff gives you the best solution and advice based on their experience.

It’s broken/I screwed up

When something goes wrong, refer back to my other post about getting good tech support. Screenshots, and explaining specifically what and where you are having the problem is paramount to getting fast, quality help.

3. One ticket per issue

You may have a handful of things to discuss or work on with your support staff, so the logical thing to do is create a big punchlist. That’s a great approach, however, I’d encourage you to break up the punchlist into chunks by type of request.

Additionally, while you can lump a group of content updates together as one ticket, it would also be prudent to break out Training/How-To or Technical issues into separate tickets, one request each. They will be prioritized and handled more efficiently that way. (This is another reason to have good subject lines!)

4. After the issue is resolved

Don’t send a “thank you” email back. It creates undue clutter in an inbox, and the technician may think the issue was not resolved (until they read your email).

When it comes time to send in your next request, do not reply to a previous email. Create a new one, so it’s handled accordingly in any help desk systems your team may have, and so it also reduces any confusion related to the previous request.

Summary

Website Update Request By Email

  • Be clear about your request or question
  • Include all support materials
  • Provide as much context as you can, as well as the desired result
  • Keep organized, one issue per ticket

 

About Stephan Hovnanian

I own Shovi Websites, a website design and email marketing company located outside Boston. I spend my days managing websites and staying up to speed with all the latest trends across the web so you don't have to.

NOTE: If you're commenting on the Google Plus Comments, please add +Stephan Hovnanian so I can follow up.


Google Plus Feed for this post

Powered by Google+ Comments

  • http://www.stuffedweb.com/ Sam Scholfield

    Good post Stephan! One to add: If it’s a bug with your website, then say which browser you are using. More often than not it’s a styling error that is caused by different browser having a different specification on how they display the code. If you let us developlers know which browser you use, we can replicate the steps you have taken in the correct browser to see the error.

    Not sure I agree with point 4, I personally prefer to recieve thank you messages, that way I can mark the issue as resolved. But I do see your point on clutter!

    I also completely agree with the subject line point. To add to this, don’t add ‘Urgent’ to the subject line unless your website has quite litterally crashed or there is a bug with a purchasing system. If it’s not business critical, then it’s probably not as urgent as you may think. All ‘urgent’ does, is make us develpers go “Oh *bother*, something terrible must have happened” and interrupts our planned schedule, which in turn makes support requests slower. If we find out it’s just a styling error or similar and not business critical, the next ‘urgent’ message you send may not get the attention it might need!
    – Sam

    • https://gplus.to/stephanhov Stephan Hovnanian

      Great comments and additions, Sam. Regarding the “thank you” email, I use Zendesk as a ticketing system. So a reply after I close the ticket will re-open it. But before I started using a ticketing system, the client’s reply was usually a good way for me to know it was resolved. Actually, most of them have been conditioned at this point not to reply, so when they want to show their appreciation, they’ll forward me the closed ticket email with their note of thanks. It means more to me when that happens, actually, because I know they went out of their way (versus having a “thank you” be part of their workflow).

    • https://gplus.to/stephanhov Stephan Hovnanian

      Also, excellent point about “crying wolf” when it comes to urgency. The other article I linked to above covers that as well.