IT Incident Management process & Support handling
TMF Support uses Odoo helpdesk module with different stages to process support requests and incident handling In what follows are the different stages described.
Support stages explained
NEW
Description
support email inbox
email template
The following email template is automatically send: "Ticket created"
TRIAGE
Description
Team has read new ticket and makes priority assessment. The ticket is assigned to a TMF team member.
email template
The following email template is automatically send: “Team member is addressing your support request”
Actions
Determine priority Use Odoo stars
- 1 star: within 2-5 business days
- 2 stars within 1 business day
- 3 stars: immediate attention
1st line
Description
Ticket is being handled
email template
The following email template is automatically send: /
Actions
Initial investigation. Attempt to fulfill the request without escalating to the dev team or a 3th party. (ex. Change configuration)
1st line: incident
Description
Ticket categorized as incident report and ticket is closed.
email template
The following email template is automatically send: “Thank you for reporting incident”
Actions
a) Incident is caused by new bug → create bug report on Gitlab b) Incident is caused by known bug → log incident and link to bug report in Gitlab c) Incident has no clear cause → log incident in Gitlab incidents
When in doubt: create an incident in Gitlab. The only reason not to log an incident in Gitlab is that the incident has a very clear cause (=bug) and the bug has not been logged yet. To spare time you don’t want to create an issue for the incident AND the bug. Try to give the incident a severity (You can only do this after creation of the incident). If you are not sure which severity level you should choose, choose the higher one.
2nd line
Description
Escalation within TMF team. Ticket cannot be handled immediately or the ticket cannot be handled by the assigned person and needs help from the team.
email template
The following email template is automatically send: /
Actions
a) Create offer b) File new need in integration project for the member c) Open bug d) Write script to fix If another team member needs to be involved you can create a TODO in Odoo within that ticket for that person
3th line
Description
Escalation to 3rd party to handle ticket. (Ex. Invers)
email template
The following email template is automatically send: /
Actions
Communication with 3th party vendor
DONE
Description
Support request fulfilled
email template
The following email template is automatically send: "closing ticket"
CANCELED
Description
Ticket is outdated and is not being handled. This closes the ticket without the partner by notified.
email template
The following email template is automatically send: /
Common support requests
Could not determine the start status of this reservation
This error is thrown by the backend when the backend could not determine the start status of a reservation when the user tries to end the reservation. This happens when the reservation was started while the cloudboxx was offline + the user did not have bluetooth enabled.
The backend tries to determine the start status based on the events in the logbook of the car, however if the cloudboxx has not come online there are no events. In most cases when this error is thrown there is an underlying cause. For example the cloudboxx antenna does not work anymore and the cloudboxx never comes online.
You can solve this issue by setting a start status for the reservation in the database. However the trip info data for the reservation (and in consequence the billing) will not be correct.
In firebase database
go to /cars/{carId}/status --> download json file to computer. {carId} is the ID of the physical vehicle used in the reservation. It can be obtained from the Control Center URL
go to /reservationDetails/{reservationId}/originalStartStatus --> This path should be null. Import the json file from step 1. {reservationId} is the ID of the reservation details. It can be obtained from the Control Center URL
end reservation via control center
optionally if the cloudboxx is still offline: change QNR in control center to mock-{the original QNR}
optionally if the cloudboxx is still offline: end the reservation via control center
optionally if the cloudboxx is still offline: change back the QNR in control center: (remove the appended mock-)