• Announcements

    • MannDude

      Current state of vpsBoard   02/04/2017

      Dear vpsBoard members and guests:

      Over the last year or two vpsBoard activity and traffic has dwindled. I have had a change of career and interests, and as such am no longer an active member of the web hosting industry.

      Due to time constraints and new interests I no longer wish to continue to maintain vpsBoard. The web site will remain only as an archive to preserve and showcase some of the great material, guides, and industry news that has been generated by members, some of which I remain in contact to this very day and now regard as personal friends.

      I want to thank all of our members who helped make vpsBoard the fastest growing industry forum. In it's prime it was an active and ripe source of activity, news, guides and just general off-topic banter and fun.

      I wish all members and guests the very best, whether it be with your business or your personal projects.

      -MannDude
ElliotJ

How To Contact Support, Properly.

45 posts in this topic

Hello @ElliotJ,

 

this is an awesome post and I wish more people would read it. We try to give equal support for all customers (even if discounted over 80 %...) but they need to learn that there are other (more important) customers or issues you have to deal with. They paid 2 bucks and expect you to answer within 15 minutes. (Which we often do anyways)

 

Thanks for the great read.

Share this post


Link to post
Share on other sites

We have had multiple clients open tickets with titles like "HELP HELP HELP MY VPS DOES NOT HAVE ENOUGH RAM FOR MY PROJECT! I AM LOOSING $1000 EVERY MINUTE"

and then just say:

"Can you upgrade it?"

1 person likes this

Share this post


Link to post
Share on other sites

Since this thread is chock full of hosts I think it is a good place to ask this question.

 

I have always wondered whether it makes sense thanking support personnel after they've answered your query? I suppose it is a polite thing to do and helps them close the ticket early. But it's also just a "pointless" reply that adds to their burden. I can imagine that they go through hundreds of tickets a day and if customers didn't thank them it would lower their burden a little. So which is better? Thank them or not?

1 person likes this

Share this post


Link to post
Share on other sites

Since this thread is chock full of hosts I think it is a good place to ask this question.

I have always wondered whether it makes sense thanking support personnel after they've answered your query? I suppose it is a polite thing to do and helps them close the ticket early. But it's also just a "pointless" reply that adds to their burden. I can imagine that they go through hundreds of tickets a day and if customers didn't thank them it would lower their burden a little. So which is better? Thank them or not?

I usually end up with a thank you reply and a comment on how the ticket was handled.

Then I close it myself.

That little extra, even if not read by the person behind it, could help me or the provider the next time I needed to submit a ticket.

Share this post


Link to post
Share on other sites

I usually end up with a thank you reply and a comment on how the ticket was handled.

Then I close it myself.

That little extra, even if not read by the person behind it, could help me or the provider the next time I needed to submit a ticket.

As client, I always say thank you and then close the ticket myself.

As a provider, I usually don't see it right away in the ticket queue since it's closed however the replies do get emailed to me so I see it a bit later and it makes me smile. Next time that customer submits a ticket? They get a little extra love :)

Share this post


Link to post
Share on other sites

Ok so hosts like to get thanked. Good to know :)

Share this post


Link to post
Share on other sites

As client, I always say thank you and then close the ticket myself.

As a provider, I usually don't see it right away in the ticket queue since it's closed however the replies do get emailed to me so I see it a bit later and it makes me smile. Next time that customer submits a ticket? They get a little extra love :)

 

As a client, that's what I usually do as well. Good to know it works out well that way from the provider's end. As @Abdussamad mentioned, I don't want a mere "thank you" message knocking the ticket back up to the top of the queue unnecessarily.

1 person likes this

Share this post


Link to post
Share on other sites

The thing is that a simple thank you is quite easy to send. I reply to tickets via email so it is quite easy to do. But if I have to close the ticket as well I will have to login to the client area and that might discourage me from doing anything. Also some providers don't let customers close tickets at all.

Share this post


Link to post
Share on other sites

WHMCS allows closing tickets, and AFAIK they don't allow response by e-mail. So if I'm in a WHMCS client area reading the response, it makes perfect sense to say "thanks" and close the ticket. And since WHMCS is so popular, that's pretty much always how it ends up.

Share this post


Link to post
Share on other sites

WHMCS allows closing tickets, and AFAIK they don't allow response by e-mail. So if I'm in a WHMCS client area reading the response, it makes perfect sense to say "thanks" and close the ticket. And since WHMCS is so popular, that's pretty much always how it ends up.

Response by email works if the host sets it up.

Share this post


Link to post
Share on other sites

WHMCS allows closing tickets, and AFAIK they don't allow response by e-mail. So if I'm in a WHMCS client area reading the response, it makes perfect sense to say "thanks" and close the ticket. And since WHMCS is so popular, that's pretty much always how it ends up.

It takes all of two minutes to set it up properly to make email replies work. Try it in your next ShoveHost ticket ;)

 

The formatting is better if the customer does it directly from the WHMCS client area though, and it's faster and more reliable (I run the ticket/reply import script every minute, so there is up to a 60 second delay before I get the customer response).

Share this post


Link to post
Share on other sites

The formatting is better if the customer does it directly from the WHMCS client area
 

 

Definitely agreed. E-mail exchanges filtered through a ticket system are a mess. Gmail chokes and gags on them, so I prefer not to use them. And from the looks of them, the ticket system itself doesn't like them, so as part of the "how to contact support properly" post, I would say don't make a mess of your ticket by going directly through e-mail.

Share this post


Link to post
Share on other sites

Also, take a moment to READ THROUGH YOUR TICKET. You really don't want to be THIS GUY 

zqAJc.jpg

Who opens a ticket about your torrents being slow. SERIOUSLY. Of ALL the things you could do. I'll admit though, that guy did do a good job of testing to confirm the problem, and he wasn't like "WHY MY TORRENT SLOW! IM GONNA DISPUTE!". Threats for PayPal disputes are a great way to get yourself suspended/terminated for fraud, and have service denied due to high risk, by the way. 

1 person likes this

Share this post


Link to post
Share on other sites

Just wanted to bump this as it needs to be seen more.

2 people like this

Share this post


Link to post
Share on other sites

You should sticky it. EVERY CUSTOMER should read through this guide at least once.

1 person likes this

Share this post


Link to post
Share on other sites

If you really only want customers who have read these then add a checkbox to your checkout page affirming that they have read it, followed by a short quiz that prevents ordering if they answer incorrectly.

Share this post


Link to post
Share on other sites

I have a tip:  If you're submitting a ticket where the provider may need to `vzctl enter` your container (OpenVZ), or log in to your KVM-based VPS, give them the information they'll need to do so - root/Administrator password, etc - and explicit permission for them to do so.  I don't know if all hosts follow this policy, but I know of at least two hosts that won't go into your container/VM unless you've given them explicit permission to do so, and giving them the info and permission right away will just make the process go a lot quicker, rather than having to wait for them to reply asking for permission and passwords, then you reply, then have to wait for them to see it.

Share this post


Link to post
Share on other sites

  • Similar Content

    • By Phill Fernandes
      Every now and then I come across a support representative that solves the problem but still leaves with that absent feeling. Almost like they didn't care about what just happened. I know from experience that at the end of the day it can become more challenging to efficiency convey the fact that you care about the customer and their problem(s). Regardless of the time of day it is imperative that you are able to do this effectively because in that moment in time you are the voice/face of the company you work for. If you mess up a relationship with a customer then the next person that interacts with that  customer will have to work twice as hard to not only fix the original problem the customer contacted you about but repair the broken and potentially lost relationship as well.
      Let's take a look at a chat log and see how the 3 As can properly be used to help the customer feel like they are actually cared about.
      In the above excerpt Kim (the representative) Acknowledged that John (the customer) was having an issue with his invoicing and demonstrated that she understood how annoying it could be if it was left unchecked. She also set a reasonable amount of time to work to get this issue solved. She also Aligns herself with the customer by stating that she would feel the same way if she were in the customers shoes.
      We also need to assure the customer that we are going to be able to solve their issue.
      In the above chat log we observed how to properly use the 3 As... Acknowledge, Align and Assure to demonstrate to a customer that care about them and their situation. We also observed proper positioning for when research is required.
      I hope this helps.
    • By Awmusic12635
      Subnet Labs is looking for technical writers to write and submit unique guides and tutorials to expand our knowledgebase. 
       
      Requirements:
       
      Must be written in correct English with proper grammar Must be fully unique and cannot have been posted elsewhere Must be on a topic not already posted (series are allowed) Screenshots or terminal output provided Proper descriptions given and fully explained Must be Linux based To get an example of what we are expecting you can visit the knowledgebase: http://impactvps.com/knowledgebase/
       
      Articles will be posted under your name and you will be given credit.
       
      Payment:
       
      $25 per article (via paypal) or $50 account credit
       
      Contact alex[at]subnetlabs.com with any questions or to submit an article
       
       
    • By HalfEatenPie
      There are a wide range of server and network monitoring software available out there. Just to name a few, you have Munin, Nagios/Icinga, Zabbix, PRTG, and of course ServerStatus by Mojeda and Mun.

      All those alternatives are fantastic. I could talk about the key benefits of every single monitoring software. However, for this tutorial we'll be jumping into something more general: Observium. Observium is "an autodiscovering network monitoring platform supporting a wide range of hardware platforms and operating systems..." While Observium's main focus is network monitoring, it also includes some hardware monitoring components available making it a pretty well-rounded monitoring platform.

      If you're already an Observium veteran, then fantastic! At the very bottom I'll be including some minor changes to the configs and additional modules I'm using in addition to Observium. Feel free to take a gander if you wish.

      Before we start, shoutout to @mitgib for getting me started on this several years ago when I was first fiddling around with monitoring systems! You're the man!

      The contents of this tutorial will be broken down into multiple posts due to certain limitations. We'll start with setting up the Observium server, setting up the Observium client, then end with minor tweaks and additional modules available. However, this tutorial will not touch upon the Unix Agent since... ehh... I think it's incredibly finicky and there's not a whole lot of documentation available. The instructions for the Observium Server is also available here on Observium's Wiki.

      Observium Server

      Jumping right in, we're going to be install Observium on a Debian 7 server. This is because Observium is actually developed on Ubuntu and Debian systems. However, RHEL and CentOS instructions are available here for those of you who are interested, and for the monitoring portion we'll include instructions on how to monitor RHEL and CentOS Servers. Just note Observium doesn't provide assistance on RHEL/CentOS or any other installations that aren't Ubuntu or Debian. For the purpose of this tutorial, we're going to assume you're running as the root user (because permission and whatnot).

      Begin by running:

      apt-get update While it may sound trivial, you want to download the latest package lists from the repositories. Anyways now install the packages required to run Observium:
      apt-get install libapache2-mod-php5 php5-cli php5-mysql php5-gd php5-mcrypt php5-json php-pear snmp fping mysql-server mysql-client python-mysqldb rrdtool subversion whois mtr-tiny ipmitool graphviz imagemagick Observium runs on top of Apache, MySQL, PHP, RRD, and NetSNMP (as well as Graphviz and fping). During the package installation process, you're going to receive a prompt to provide the MySQL Root password. Provide a secure password since that's pretty important and make sure you don't forget it!
      Create the directory Observium is going to operate out of:

      mkdir -p /opt/observium && cd /opt For the purpose of this tutorial, we're going to be using the Community/Open Source Edition of Observium. Download and unpack it.
      wget http://www.observium.org/observium-community-latest.tar.gz tar zxvf observium-community-latest.tar.gz You're going to have a new folder in your /opt/ folder named observium. Change to that folder:
      cd observium Login to the MySQL Command Line by typing:
      mysql -u root -p Provide the MySQL Root Password you set earlier. From here you'll notice the mysql>. This is the MySQL shell. From here, we're going to be creating our database and assigning a new user all permissions to the new database. From the MySQL Shell, enter:
      https://paste.ee/p/mr1Wy Link (Note: Moved to Paste.ee due to IPB not accepting SQL Commands)
      Now exit the MySQL Shell by typing:

      exit Now we'll find ourselves back in Bash and in /opt/observium folder. Lets copy the default configuration and edit it for our system.
      cp config.php.default config.php nano config.php Update the config.php file with the proper MySQL database information.
      Let's setup the default schema for the MySQL Database:

      php includes/update/update.php We're going to create the directory Observium will store it's logs. In addition, we'll also be creating the directory to store the RRD data files as well as modify the permissions:
      mkdir logs mkdir rrd chown www-data:www-data rrd Now this tutorial is assuming your server will only be running Observium for the webserver. This can be modified by using vHosts, however that's outside the scope of this tutorial. Open the default apache configuration file:
      nano /etc/apache2/sites-available/default and I'd suggest changing it to this:
      <VirtualHost *:80> ServerAdmin [email protected] DocumentRoot /opt/observium/html <Directory /> Options FollowSymLinks AllowOverride None </Directory> <Directory /opt/observium/html/> Options Indexes FollowSymLinks MultiViews AllowOverride All Order allow,deny allow from all </Directory> ErrorLog ${APACHE_LOG_DIR}/error.log LogLevel warn CustomLog ${APACHE_LOG_DIR}/access.log combined ServerSignature On </VirtualHost> Note: For those of you who are using Ubuntu 14.04, use this Apache2 Config...
      Spoiler
      <VirtualHost *:80> ServerAdmin [email protected] DocumentRoot /opt/observium/html <Directory /> Options FollowSymLinks AllowOverride None </Directory> <Directory /opt/observium/html/> Options Indexes FollowSymLinks MultiViews AllowOverride All Require all granted </Directory> ErrorLog ${APACHE_LOG_DIR}/error.log LogLevel warn CustomLog ${APACHE_LOG_DIR}/access.log combined ServerSignature On </VirtualHost>
      With the apache2 config files edited, we're going to enable a few modules. Enable the PHP mcrypt module:

      php5enmod mcrypt Now enable the Apache module rewrite to "prettify" Observium's URLs:
      a2enmod rewrite apache2ctl restart Now add the administrator account (level 10) to Observium:
      cd /opt/observium ./adduser.php <username> <password> 10 Finally, setup the cronjob so that it discovers new hardware and polls our servers regularly by:
      nano /etc/cron.d/observium and entering this as the contents:
      33 */6 * * * root /opt/observium/discovery.php -h all >> /dev/null 2>&1 */5 * * * * root /opt/observium/discovery.php -h new >> /dev/null 2>&1 */5 * * * * root /opt/observium/poller-wrapper.py 2 >> /dev/null 2>&1 Note: The last line of the above cronjob shows "/opt/observium/poller-wrapper.py 2". Older versions of Observium used the outdated poller.php which only created a single poller instance. This was great for initial testing or just a low number of servers, but for a large volume of servers this wasn't enough. poller-wrapper.py was then included with more recent Observium installations which created however many processes defined (in this case, 2). Change the number after poller-wrapper.py to the number of cores or instances you wish to run/use (e.g. for a VPS with four CPUs you can change the number to 4).
      Great! You've installed Observium Server! Now point your browser to http://<Server IP> and be on your way!

      Observium Client

      Observium mainly utilizes two types of pollers, SNMP and the Unix Agent. Only SNMP will be covered in this tutorial. The Unix Agent can/will be featured in a future post, or someone else can do it who knows.

      This tutorial will help you install and configure SNMP for CentOS, RHEL, Debian, and Ubuntu servers. This tutorial will not help you configure SNMP for Windows Server or other clients, however there are resources available to help you with that.

      To start, install the SNMPD package:
      For CentOS and RHEL:

      yum install net-snmp net-snmp-libs net-snmp-utils For Debian and Ubuntu:
      apt-get install snmpd To make life easier, we're simply going to scrap the default SNMPd Configurations:
      echo "" > /etc/snmp/snmpd.conf Now open the blank SNMPd configuration:
      nano /etc/snmp/snmpd.conf Enter the following configurations:
      rocommunity COMMUNITYNAME <OBSERVIUM SERVER IP> syslocation LOCATION syscontact [email protected] operates with the community strings, therefore you can change COMMUNITYNAME to something else (a single word though, no spaces or punctuations are accepted). For the purpose of this tutorial I'll be using vpsBoard. After you type in the community name enter your server IP (to prevent reflection attacks). syslocation is metadata used by Observium and other snmp services. Under LOCATION, enter the System's physical location, for the purpose of this tutorial I'll be using "Dallas, Texas, United States". syscontact is additional metadata required by SNMP. Frequently I just enter one of my own email addresses. In the spoilers is a sample configuration of snmpd.conf.

      Spoiler
      rocommunity vpsBoard 8.8.8.8 syslocation Dallas, Texas, United States syscontact [email protected]
      With the SNMPd configurations done, we have to restart the service!

      service snmpd restart We're not out of the woods yet! Make sure you check on the Firewall to allow Incoming UDP on Port 161! Simply for tutorial's sake, here's the IPtables for it:
      iptables -I INPUT -p udp --dport 161 -j ACCEPT Congrats! You've setup SNMP properly on the client server! Time to have Observium monitor it.
      Go into Observium's web interface (http://<Observium Server IP>). Login, and from the navigations go Devices -> Add Device.


      Enter the information you've configured SNMP to listen for (in this case, my sample configuration):


      Press "Add Device" and then wait for the next cron to run.

      Congratulations! You've added a server to your Observium installation! Now wait for data collection to occur!

      Here's a sample of one of my utility server (BuyVM VPS).

      Spoiler


      What Else?
      So that's the tutorial for the vanilla Observium installation. However, I personally recommend these minor changes to help with your use of Observium.

      Timeout Configuration
      Observium was originally created for ISPs and to monitor networks, not servers. Therefore, vanilla Observium has almost no tolerance for even the smallest network blip (such as a single packet not making it to the destination). So to help with that, we're going to add a few extra lines to the config file.

      Open up the configuration file:

      nano /opt/observium/config.php Add the following to the end of the configuration file:
      // Timeout Config $config['snmp']['timeout'] = 20; // timeout in seconds $config['snmp']['retries'] = 5; // how many times to retry the query $config['ping']['retries'] = 10; // How many times to retry ping $config['ping']['timeout'] = 1500; // Timeout in milliseconds The descriptions are pretty straight forward. With this configuration, Observium will now continually retry polling the server until a predetermined number of times before considering it "down". This is especially helpful if you have set Observium to email you during server downtimes (Note: You can enable this by editing the config.php file and installing sendmail or configuring smiliar mail services on the server).
      External Application Integration - Collectd
      So Observium is pretty awesome that it can also integrate with External Applications such as smokeping, RANCID, syslog, etc. For this tutorial I'm simply going to address Collectd, but a full list is available here. Please note the application monitoring section (such as monitoring Apache, nginx, MySQL, etc.) of Observium requires the Unix Agent which, again, is not covered in this tutorial (but maybe in the future).
      Collectd is "a daemon which collects system performance statistics periodically and provides mechanisms to store the values in a variety of ways, for example in RRD files." To be perfectly honest, it's very similar to the data collected by the SNMP poller, however Collectd comes with numerous plugins you can also monitor (and therefore monitor with Observium). Pretty awesome and keeps your life simpler.

      There's two parts to Collectd that we have to consider for Observium. The server and the client. Let's begin with the Server.

      Collectd Server
      For the server, install collectd:

      For CentOS and RHEL:
      Collectd is unavailable in RHEL and CentOS repositories, therefore you can either download the collectd RPM from collectd's website or build from the source package. Building from source or downloading the RPM and installing from collectd's website is outside the scope of this tutorial. However there are resources available online that can help you with installing collectd on CentOS and RHEL servers.

      For Debian and Ubuntu:

      apt-get install collectd Once you have collectd installed, edit the collectd configuration file at /etc/collectd/collectd.conf.
      nano /etc/collectd/collectd.conf Configure that file in any way you see fit, however make sure hostname and the network plugin is loaded. Observium watches for the hostname when determining if the server has collectd enabled:
      Hostname "observium.tutorial.vpsboard" LoadPlugin network <Plugin network> Listen "0.0.0.0" "25826" </Plugin> Restart the collectd service:
      service collectd restart Now we're going to have to edit Observium's configuration file to tell it where collectd has the RRD files. First, open config.php:
      nano /opt/observium/config.php Add the following configuration argument:
      $config['collectd_dir'] = "/mnt/rrdcached/db/collectd/"; That's it! The collectd tab should automatically appear for any servers that collectd is receiving the graphs for (assuming the hostnames match).
      Collectd Client
      The client and the server are very similar. The only major difference is the network plugin configuration.

      For CentOS and RHEL:
      Collectd is unavailable in RHEL and CentOS repositories, therefore you can either download the collectd RPM from collectd's website or build from the source package. Building from source or downloading the RPM and installing from collectd's website is outside the scope of this tutorial. However there are resources available online that can help you with installing collectd on CentOS and RHEL servers.

      For Debian and Ubuntu:

      apt-get install collectd Once you have collectd installed, edit the collectd configuration file at /etc/collectd/collectd.conf.
      nano /etc/collectd/collectd.conf Configure that file in any way you see fit, however make sure hostname and the network plugin is loaded. Observium watches for the hostname when determining if the server has collectd enabled:
      Hostname "observium.tutorial.vpsboard" LoadPlugin network <Plugin network> Listen "1.2.3.4" "25826" </Plugin> The IP (1.2.3.4) is the IP of the Observium Server, not the IP of the server being monitored!
      Restart the collectd service:

      service collectd restartThat's it! The collectd tab should automatically appear for any servers that collectd is receiving the graphs for (assuming the hostnames match).
      Final Thoughts
      Hope you've enjoyed this giant crash-course on Observium! It doesn't cover everything about it but it covers majority of it. If you have any questions, comments, or concerns feel free to reply. If I don't get to them then I'm sure someone else will come along to help! If you have any awesome changes to your Observium installation feel free to let us know here!


    • By KnownHost-Jonathan
      KnownHost is a high-end shared, VPS, and dedicated web hosting company in Birmingham, AL that prides itself on providing extraordinary customer service and support to its growing customer base.

      We're privately owned, profitable, growing and we're looking for enthusiastic, friendly, and knowledgeable employees to join our expanding team. We recognize that, along with our customers, our team is our most valuable asset.

      This is a local position in Birmingham, AL and the willigness to relocate is required. Inquiries from outsourcing companies and recruiting agencies will be ignored.

      Technical Support Operators staff the front lines of our company - namely our 24/7/365 helpdesk. They're responsible for providing our customers with extraordinary customer service and support on a daily basis and ensuring that going above and beyond is just part of the job. In addition to technical prowess, our Technical Support Operators need to posses customer service skills that are way beyond average and also have an attitude and personality that makes them suited to work with people (our customers and their co-workers!) and make those people happy.

      Please note we are a Linux only host, so Linux experience is a must.
      The primary responsibilities of our Technical Support Operators are:
      Provide customers support via our 24/7 helpdesk. Troubleshooting email delivery issues Troubleshooting cPanel, Plesk, and DirectAdmin related issues Troubleshooting DNS, FTP, SSL, Apache, and other service-related issues. Ensuring customer satisfaction Basics: All of our Technical Support Operators: Must be customer-focused, and willing to do whatever it takes to resolve customer issues. Going above and beyond is the standard at KnownHost. Our customer reviews reflect this. Excellent written English. Technical Support Operators currently primarily provide support over email, but may occasionally be asked to pitch in with live chat and phone support. Must be familiar with Linux shell (bash), Apache, PHP, MySQL, email (POP3/IMAP/SMTP), FTP, DNS and other standard web hosting applications and protocols. Must be able to work under pressure when bad stuff happens and get the job done. Multi-tasking is a must. KnownHost has a lot going on, and multiple brands. Must be able to ask customers for complete error message or derive the context of their problem if they provide insufficient information. Bonus: If our Technical Support Operators know this stuff already, great. If not, they'll learn it in training and on the job: cPanel/WHM, Plesk, and Directadmin control panels Knowledge of PHP, Python, Perl and/or Ruby on Rails. Can install PHP from source, enabling required modules. Also, can install a separate Python version that is separate from the operating system version. Iptables firewalls (CSF, APF, etc.) Common customer website apps, like Drupal, WordPress, MediaWiki, Magento, ZenCart, etc MySQL commands for support or troubleshooting, like importing/dumping a database, simple SELECT statements or "SHOW PROCESSLIST" Perks:You get the opportunity to work with great and very smart people, help our customers, and have a chance to be part of a growing and successful company. You also get:
      Competitive pay Flexible scheduling, including up to 20 days of paid time off. Frequent catered lunches Snacks, water, and coffee A variety of other perks , including free web hosting, company paid outings, and more. Because this position is full time and includes perks, we expect KnownHost to be your only hosting-related job.
      Interested in applying? Check out our careers page.
    • By Awmusic12635
      We are looking for a Level 2/3 support tech that is available for a night time US shift.

      Job Requirements:
       

      Additional Skills (Not required):
       


      Average day snapshot:
       


      Applying: