Working remotely from home means that as a worker, you should be many more times more reliable than the traditional office worker. The excuse of heavy traffic or car failure can’t apply. Major events or infrastructure failures can indeed hinder work but you must be prepared at all times for any situation (even if it means only informing your employer of the problem).

The following is a very basic checklist for being a reliable remote worker:

• Regularly updated and printed copy of all employee contact details. If you work for a large business, then the list can be limited to key co workers and managers. If your employer gives you a laminated copy with branding, then they are doing it right.

• 2 internet connections. This is, in most cases, even more crucial than a UPS because power is commonly less likely to have periods of interruption than internet access. A cellphone can be used for this purpose.
• A UPS (Uninterruptible Power Supply) suitable for at least a 60 minute power outage. Energy efficient computers (such as Atom based all in one platforms) should be able to operate for a few hours in contrast to a standard desktop computer.
• 2 alarm clocks. The most convenient is to use a normal desk alarm clock in conjunction with your cellphone. Replace the batteries once per year on the day prior to time off from work.
• An offline / cloud copy of all needed software to carry out your work. This is to be used if your computer must be replaced.

A backup internet connection is the most important point above but also the simplest to have in place (the correct cellphone cable and data access are all that is needed). If you are an employer, ensure all of your workers have a backup internet connection and perform a test of it.

A quick glance over Amazon’s product listings reveals that there are good quality UPS units available for under $200 (closer to $100 if you are lucky enough to make the purchase while there is a discount). If you are an employer, you can easily implement a purchasing programme for employees who wish to purchase a UPS. The $200 business expense is minimal for the level of assurance that is returned. Even a split purchase agreement could be considered: after 1 or 2 years, the company can then pay the employee back the original portion they paid as a further incentive. This kind of thinking and planning is vital for all employers of remote workers.

On that note, this should be the last blog post for 2012 and I want wish all readers a very special festive season. While I am a technology enthusiast at heart, I also love the business and management side of the web hosting industry which is why my next blog post will be of a more technical nature, I promise.

What if I were to tell you that your web hosting business could reach out to most of your clients and that it wouldn’t even be considered spam? While it wouldn’t necessary reach every client, it almost certainly wouldn’t be blocked. It may seem to good to be true, but you are actually doing it without even really knowing. The answer would be e – mail auto responses.

The most underutilised and overlooked point of contact in the web hosting industry by far, automated e – mail messages are most commonly found in the form of support ticket acknowledgements. They can also be in the form of invoices and receipts. The retail industry have already caught on to this, very often adverts can be found on the opposite side to the printed receipt.

The benefits of regularly tweaking your automated e – mail messages can be staggering once understood properly. Customers often complain on forums that their billing or sales tickets are not answered quickly. These forum posts could have been avoided if the web host involved only had the foresight to modify their automated messages to contain the available hours per department.

These e – mail message modifications can also simply be good natured and non commercial, for example they could feature a positive New Year message. There is no reason for technical support tickets to be clinical and lack engagement – a season’s greeting message would serve only to boost the reader’s mood.

Let me give you one real world example:

Let’s say a web hosting business has recently implemented a firewall unblocker section which is made available from their client portal. This area can be used to unblock a customer’s IP Address which may have become blocked due to failed login attempts. A good portion of the daily support tickets which are received involve the tedious task of checking and unblocking these affected customers. We can help lower the number of these requests simply by modifying the automated support ticket responder which acknowledges support ticket submissions with a message asking the reader if they are aware of the newly available firewall unblocker.

Even if only a very conservative 10% of readers actually take the time to absorb this information, you have just lowered this particular type of support ticket by a noticeable margin in less time than it took to answer one firewall block ticket.

Special offers can also be advertised this way but be careful not to transform communication into spam. If you choose the route of advertising instead of a season greeting or snippet of useful information, then limit it to one offer and an exceptional one at that. You can also take advantage of issued receipts but do not advertise anything on your invoices – this will look very unprofessional.

Your customers are contacted regularly in the form of automated messages – be different from the rest and use this as an opportunity to engage your customer for the better.

If I asked you if you would purchase from a shop which stored your credit card details, would you still do business with them? I am fairly certain that most people would hesitate, regardless of how good their service is. It also would probably make no difference to your opinion if I told you how securely this was stored (be it in physical form in a safe location or encrypted).

Some businesses actually do this and the web hosting arena is no different. Included below are types of private information which web hosts commonly store in their billing system:

• Your control panel username and password
• Your credit card information

The first point is far more common then the second. The average non – technical web hosting operation (believe me, they make up the majority of service providers) would not even consider this as a security concern. Let me use an analogy:

Many people hide a second set of keys to their household under a potplant or rock as to avoid being locked out. What if I were to tell you that your web host was doing the exact same thing but with access to your e – mail and files? This is because the web host in question assumes it is more convenient for the customer to login to control panel via their customer portal instead of accessing it directly. Is it really worth the risk of having every single customer’s control panel username and password revealed in the event of a security breach?

There is absolutely no reason for any web host to store usernames and passwords in their billing or portal areas. It’s careless. There must only be one copy of a username and password and that is on the server itself.

My next point concerns storing credit card information. There is only one instance where this argument has a leg to stand on but is still unacceptable in my opinion: Cloud Computing. Cloud computing allows for hourly billing and in such a circumstance it would not be possible for a customer to re – enter their unsaved credit card information to make payment every hour. There is a solution to this, though and that is to rather have these hourly billing customers make lump sum deposits to their account.

Many web hosting customers pay yearly for their service – is it really worth while storing their credit card information simply so that payment can be more convenient once per year?

Ask your web host if they store your credit card information and / or control panel authentication details. If they answered yes then point them to this blog post.

When you think of live technical support, you often imagine live text or phone based discussions – it essentially means technical support which is given in real time. It can also correctly be assumed that there are basically only 2 forms of live technical support currently being offered in the web hosting industry:

• Phone support
• Live chat

While both of these can mostly be seen as ineffective (depending on how they are implemented), there is one further form of technical support which is almost totally ignored by the web hosting industry: Remote Desktop Support.

Remote desktop support is used extensively in the corporate IT support sector but not in the web hosting industry, which I find strange. It allows for a support technician to login and fix any client side configuration settings or perform all needed tests immediately and without any delays (such as informing a client on directions to perform a traceroute, for example).

A good example of an approach to offering this service is the use of TeamViewer. It requires no installation or technical setup and doesn’t even need any special open ports or port forwarding configuration. It also supports Windows, Apple and Linux based operating systems.

The implementation of this technology can be extremely flexible and powerful, for example all that you need to connect to the customer’s computer is a short set of numbers and then a further short password. You can probably already see where I am going with that:

• Technical support help desks can have fields for these needed values. This allows for immediate access and resolution for the customer.
• Customer records can have these values stored for automatic retrieval.

The service can also be offered at a premium, for example an extra $10 per month over and above the customer’s current monthly fee. There is no significant extra cost to the service provider because the TeamViewer service is hosted externally and the live support operators should have no problem in troubleshooting an e – mail client, so training is not essential.

There is no doubt in my mind that live technical support in the form of remote desktop support will become mainstream one day, all it will take is for an industry leader to see the bigger picture and offer it as a unique selling point. Competitors will soon follow the lead.

What I decided to write about today is a topic which has always intrigued me: business processes. I have had my fair share of jobs throughout my life (having sought employment from a young age) and it always brought me joy to discuss the various business processes / procedures with my employer and how they can be improved. To this day, I still see meet one of my very first employers for coffee, even after having left work there for nearly a decade.

Communication during a time of crisis commonly follows the same formula, that is a contact number is provided for employees to phone and state the emergency. Depending on how advanced the telephony setup is, it may either direct this call to one or even multiple contacts – hopefully reaching an individual which can help remedy the problem.

I personally believe this kind of setup is mostly ineffective and I will tell you why:

• Most of the time the call is going to only reach one person and if this person is unavailable then co workers will be left guessing as to what the situation might be.
• Assuming the intended person is reached, this individual must then contact other employees and notify them what is happening. This may even be prior to the start of remedying the crisis.
• A very expensive call rate will be charged should the employees be located overseas.

The alternative is fairly obvious but often ignored by organisations as a tool for communication. Many businesses seem to have forgotten the flexibility and power of SMSes (however dated the technology may currently be). SMS gateways can be developed to achieve almost any possible solution and there are even third party providers which can handle most of the technicalities on your behalf.

We can easily see the benefits of an SMS setup when using an example of a work – from – home employee’s computer or internet failure:

• One SMS message can immediately be forwardered to any number of co workers on shift, thereby keeping them up to date (in real time) as to what the situation is.
• This same SMS message can also be forwardered to workers which are not on shift, but rather on call / willing to work extra hours.

I am not saying that traditional phone / VOIP systems don’t have their place (because they definitely do), but it depends on the actual function which it is needed to serve. Taking into account that emergency situations specifically are often very simple to describe and therefore don’t require the overhead and inherent delays of voice communication.

The solution is to rather have any emergency communication instantly reach all important parties and SMS is the tool to achieve this. You could be even more prepared as a business though and offer both SMS and telephonic based communication mediums for use in a moment of crisis.

I recently purchased a D-Link 2500U because it allows telnet access to manage using command line. This feature is not often provided for ADSL modems (not to be confused with the routers with an integrated ADSL modem). Besides, I can’t resist a Linux powered device.

I then decided to experiment with the route command and split local and international traffic. There was surprisingly a Local Router project with a 2500U script, however their use of route proved to be incorrect in syntax.

Here is my modified script if any of you need it or are interested:

#!/bin/sh
# Your router's IP Address:
host="ipaddress"
# Your router's login user:
user="username"
# Your router password:
passwd="password"
# Your router's local interface:
if="interfacename"
# Download new list of local routes
wget "http://developers.locality.co.za/routes-rs.txt" -O localroutes.txt
modify()
{
while read i s
do
if [ "$i" != "#" ]; then
echo send \"route add `echo $i | sed 's/,/ /'` $if \\\\r\" >> localrouter.sh
echo expect \"# \" >> localrouter.sh
fi
done < localroutes.txt
}
echo "#!/usr/bin/expect --" > localrouter.sh
# Perform login
cat >> localrouter.sh << EOF
spawn telnet
expect "telnet>"
send "open $host\r"
expect "ogin: "
send "$user\r"
expect "word: "
send "$passwd\r"
EOF
# Add routes
modify
# Exit
cat >> localrouter.sh << EOF
send "exit\r"
send "!\r"
expect "$ "
EOF
# Run script
bash localrouter.sh

ifconfig can be used to obtain the needed (local) interface name.