The help desk operative will converse with the caller / review email received and populate a record to log the fact that a request has been requested. They will create an SR using the Create Help Desk SR menu option.
The following blank SR screen is displayed. Note: Red asterixis next to fields are mandatory in order to save the record
On the SR screen, some fields will be pre-populated upon creating this new record and will also bring across details from other related records as the user selects the data. These are described below.
The SR screen is split into 5 sections
- Reference, Creator and Type details
- Reference – This will be the SR number which is system generated once the record is saved. This is the reference the user will need for any further updates of their call
- Created by – This will populate with the name of the person creating the record from the contact user record
- Service type – This will default with the type of ‘Help Desk’ as this is being created by a Help desk operative
- Reporter and Affected Person information – These are mandatory fields. These are for Who is reporting the issue and who is affected. Will initially populate both with reporter details, but can be changed if affected person is different and reporter is calling on behalf of someone else. Will detail Name, Email and Phone contact so that the person carrying out the work knows who to liaise with when on site and who will also be the approver to sign of the work has been completed satisfactorily
- Property Information – This is a mandatory field. Here the user collects the property which the issue is at. The reporter will confirm this during the call and the user will populate the Related Property field. Upon entering the Property, the system will search for the record and once found the user will select it. The following data will pull through that resides against the property record, namely the ‘Cost Centre’, ‘Site/Branch ID’ and the address
- The user will then need to confirm a Location if the property is broken down to this level. The location can be Rooms, Floors, Areas etc. The system will display a list and the user will select the appropriate option. This is key as this determines what assets are linked to that location and will show a filtered list. If no location is selected, then a full list will be presented and the incorrect asset could be assigned
- If this was from a tenant raising an issue, then there is a field to populate the related Lease that is associated to the Property (Currently manual, but can be automated if required)
- Service Request Details – This is where the user will determine from the Reporter what the issue is, the Category, Asset affected (If known), Priority
- Short Description – Mandatory field. High-level Summary needs to be entered in this field
- Description – Mandatory Field. Full description with as much detail that the help Desk operator can get from the reporter to aid in sending out the correct skilled trade to resolve the issue.
- Affected Asset – By selecting the Choose Asset Button, the user is presented with a filtered list of assets that are associated to that Property and location combination populated previously. Users will select the relevant asset in question and click on the ‘Select Chosen asset’ button (This is if they know the asset in question, if not leave blank)
By choosing the asset, data associated to the asset will be pulled through such as Asset Name, Asset Description, An Asset Tag number if coded, a GL code if assigned, and finally if the Asset is active or not
- Category – Mandatory Field. Next, the user will need to categorise the issue. With the information already collected, there should be enough detail to select the most relevant category from the Tree shown below. This information is split into hard, Soft, and Landlord type options and can be configured. This is key as this will determine which trade to assign. This Category Tree aligns with the possible issues that may be encountered in the relevant sectors and will be driven by the clients’ requirements.
- Reported and internal Priority – These are how urgent the issue is to be resolved. Priorities will be determined and driven by the client upon inception of the contract. These can be configured and added to as and when new categories are introduced. The reported priority is what the reporter thinks it is and the Internal priority is what the help desk operator has assessed it is from the information given by the reporter. Note the target start and finish times will be driven by the Internal Priority. Priorities could have a start by and complete by instructions. These can be different for each client. Example entries;
- P1 – Emergency (Attend straight away within 30mins)
- P2 Urgent (Attend in 2 hours but fix by 4 hours)
- P3 – Routine (Attend 8 hours)
- Non–Urgent (Attend in 5 days)
- Out of Hours
- Service Group, Service, and Commodity groups - are used for Finance coding reference where the cost resides for that category. Not all clients use this. But it’s there for future reference
- Key Dates section
- Reported Date – Date on which the SR was raised
- Required Date – used if requesting a service for a particular date and time in the future. Used for catering request, or for where a request is for a specified event etc
- Target and Actual Contact Dates – some contracts request a contact to confirm attendance and these allow the help Desk operative to document that these actions have taken place. They could back this up by adding a comment or note to the record for reference
- Target start and finish Dates – These are driven from the Priorities and will transfer onto the Work order so that the person carrying out the work will have an indication as to when the work has to be started and completed for KPI monitoring.