Support Staff Guidelines

This Document will outline what is expected of the Support Team Members and guidelines on how you go about achieving them.

The primary role of the support team is to ensure calls from within the support desk are being dealt with, however there are other parts of the business you will need to cover from time to time. 

Working Hours - There are currently 3 shift patterns

  • 8- 5 - This is the early shift and it was created when we took Octavian on.  They have cover from 8am so any support calls that would be in the open Queue for them would take priority.  All other customers do not have any cover until 9 am so any work they request to be carried out that cannot wait would be charged as out of hours and they should contact the out of hours number. 
  • 8:30 - 5:30 - This is the normal shift, every user not on an early or late should work these hours 
  • 9 - 6 - This is the Late shift and it was created when we took Octavian on.  They have cover until 6pm, all other customers cover stops from 5 so only Octavian support calls should be dealt with from 5-6.  All other customers should request out of hours support using the out of hours number.

As you should be aware the main bulk of your work will be on support issues and you will work mainly from the in progress queue - please ensure you are fully up to date with the roll of each Queue here - 02 Helpdesk Queues


Working on a support call

Once you have been assigned or have picked up a support call a number of things should happen 

    • The call is assigned to you, it becomes your responsibility this doesn't mean you will carry out all the work or maybe even provide the resolution.  These responsibility include :-
    • Making sure the SLA for that call type is met 
    • Making sure the customer is kept up to date, they should be informed of the progress at least once every 24 hours
    • Ensure that you add notes to the ticket regularly so the team know the progress you are making if they need to work on the ticket in your absence
    • Making sure the call was logged correctly and letting the Helpdesk Administrator know if there was anything wrong
    • If you have not found a resolution within an hour, that you follow the correct escalation procedure.
    • When closing a ticket that the call type has been changed accordingly, ie it may have been originally logged as an issue, but since has been investigated and found to be a bug.
    • Updating the wiki if you answered a question for a customer that they could not find on the wiki or logging a ticket into the CS Q for an update to the user wiki.
    • Information in the call should be kept current and up to date this includes : - 
    • Notes of work done so far, this will help make sure the same thing is not done over and over again and also help make sure we can keep the customer up to date
    • Any helpful correspondence from internal e-mails that provide information
    • Details of any help or assistance you have requested and are waiting for

 

System upgrades

The team will also undertake system upgrades for internal test systems, customer test systems and customer live systems

 

Internal

  • For internal test system upgrades, a ticket will be in the in progress Q with the word 'RELEASE' and the product and version
  • The SS will need to ensure all staff members are logged out of this product on our test system
  • They will then upgrade the product as per the ticket
  • Once complete an email will need to be sent to VT email informing them the upgrade has been completed

 

Customers test upgrades

  • The upgrade will have been arranged by CS they will ensure that all the correct paperwork has been signed by the customer
  • CS will then need to confirm with the support team leader when a member of the team will be available to undertake the upgrade
  • A date will then be agreed between the team leader, CS and the customer
  • Once the date has been agreed a specified member of the team will be informed this needs to be completed and will be assigned this task
  • The day before the upgrade a ticket will be raised by CS and placed into the support  in progress Q with details of the customer,  product, version number and date of upgrade specifying this is for TEST.  
  • When undertaking the test upgrade ensure that the customers are off of their test system before starting any work
  • If a data refresh is required then complete this before upgrading the database - There is a guide for this under the support guidance notes on the wiki (–input link to guide here)
  • You then run the scripts to upgrade the database - There is a guide for this under the support guidance notes on the wiki (–input link to guide here)
  • If it is a VC customer once completed you will also need to ensure that the vision to sage services are running and working
  • Once the upgrade is complete, test to ensure it is working, then inform the customer they can now access their test system
  • Send an email to VT to inform them the upgrade has been completed
  • The board in the office and the customer details spreadsheet will then need to be updated by a specified team member

 

Customers Live Upgrades

  • The upgrade will have been arranged by CS they will ensure that all the correct paperwork has been signed by the customer
  • CS will then need to confirm with the support team leader when a member of the team will be available to undertake the upgrade
  • A date will then be agreed between the team leader, CS and the customer
  • Once the date has been agreed a specified member of the team will be informed this needs to be completed and will be assigned this task
  • The day before the upgrade a ticket will be raised by CS and placed into the support  in progress Q with details of the customer,  product, version number and date of upgrade specifying this is for LIVE.  
  • NO upgrade should be undertaken without the date being agreed with the team leader and a ticket being raised and placed in the support in progress Q.
  • When undertaking the live upgrade ensure that the customers are off of their system before starting any work
  • You then run the scripts to upgrade the database - There is a guide for this under support guidance notes on the wiki (–input link to guide here)
  • If it is a VC customer once completed you will also need to ensure that the vision to sage services are running and working
  • Once the upgrade is complete, test to ensure it is working, then inform the customer they can now access their live system
  • Send an email to VT to inform them the upgrade has been completed
  • The board in the office and the customer details spreadsheet will then need to be updated by a specified team member

 

Keeping the Wiki up to date

There are 2 main parts of the wiki that needs to be kept up to date - support internal pages and pages that the user can see, for example the user manual

 

Internal Support Pages

  • Helpdesk/support team procedures - these are the support team procedures that need to be followed - this will usually only be updated by the line manager or the HDA will be asked by the Line Manager to update.
  • Support Guidance Notes - This is any helpful guidance notes, or steps to follow when investigating a support issue - Any member of the team can add to this section

 

User Pages

  • Support would normally only update the user manual pages on the Wiki
  • Once an email has been received that a new release of a product is available, a specified member of the team will need to check the release notes to see if any updates are required to the Wiki and make the required changes
  • We are currently undertaking to rewrite all the user manuals, all team members are involved in the rewrite, but the changes are being written off line and sent to a specified team member who has the task of updating the live Wiki pages


Testing

There are 2 types of testing we get involved in, testing specific issues and full run through testing

 

Testing specific issues

  • The Development Manager will request a product is tested and all outstanding issues on that version be tested
  • Liaise with the testing team (or in their absence, the Line Manager or Development Manger) as to which issues they would like us to test
  • Go to the outstanding issues to be tested page on JIRA
  • Read the issue to be test and complete the relevant test
  • If the issue has been resolved then add a comment that it has been tested and now works and close the issue.
  • If the issue has not been resolved, add a comment as to what you did to test and why it has not been fixed, reopen the issue
  • When you have completed your testing, then inform the testing team/Development Manager of the issues you tested and whether you have closed or reopened them

 

Full system test

  • If undertaking a full system test, you will be allocated a specific section of the system to test by a specified person
  • Once you have completed this section update the testing spreadsheet with your findings and details any issues found
  • Inform the specified person that you have completed your section so they can then ask the next SS to test their section
  • If you have issues accessing the test system inform the specified person asap so they can resolve this and testing can continue

 

Weekly Tasks

  • Email to be sent out on a Monday detailing all bugs raised in the previous week - this is usually undertaken by the HDA or in their cover in their absence
  • Checking if any jobs/services have failed that we have not be notified about via an automatic email – to be confirmed
  • Check closed tickets have been assigned the correct categories - This is usually undertaken by the HDA

 

Other General Tasks

When an email is received from Development about a new release for test, create a ticket for the support team - HDA or their cover

Ensure the board in the office is kept up to date with current releases/current customer versions -HDA or their cover

Ensure the customer details spreadsheet is kept up to date - specified person

Monitor the open Q and ensure tickets are dealt with and moved over promptly - HDA

Monitor the initial review Q and ensure no ticket are sitting in this Q that should be in other Q's - HDA

Monitor the with Customer Q and close any ticket that is over 24 hours old and the customer has not responded - HDA (or SS if it their own ticket)

Monitor the resolved Q and close any ticket that is over 24 hours old - HDA (or SS if it is their own ticket)

Monitor the In progress Q and ensure that the customer is being kept informed of progress - HDA

Monitor the in progress Q and ensure the ticket notes are kept up to date - HDA

Send emails to SS/VTI if tickets have not been correctly updated or customer has not been informed of updates - HDA

Arrange team meetings - HDA on behalf of Line Manager

Liaise with CS in regards to tickets possibly being closed with the wrong category - HDA

Raise Echosigns for any chargeable work - HDA

 

Copyright Ontech Solutions 2017-2024. All rights reserved, no part may be replicated or distributed without the express permission of the owner.