Yes, one can also add non-IT assets to Assets Inventory. Depending on the domain and industry, one can define Asset Type, Asset Sub Type and Asset Category and add any number of IT as well as non-IT assets. Also, depending on Asset Sub Type, one can also define the specific fields that should be displayed for that asset. This is incredibly useful, especially when one needs to add new Custom Field for asset, depending on the business requirements.

Yes, tussom offers Approvers as well as Reviewers before the Knowledge Base record is published. One can define Reviewers and Approvers that wil play the respective role after the Knowledge Base record is created. Once the KB record is reviewed and approved, it can then be published either to end users, Support Engineers or both.

Indeed. tussom offers a very flexible way to configure or define reconciliation rules. You can set the reconciliation rules based on whether the CI (Config Item) was added manually, was imported, integrated or discovered. You also have an option of including 'last updated' CIs or to include duplicate CIs to run reconciliation. Once the rules are executed, the CIs are then added in Golden CMDB.

Yes, you can define different SLA criteria for different customers in tussom. You can log in as a tussom Administrator and define SLA criteria for different customers based on Category, Ticket Type and Severity etc. You can define the SLA criteria for only Category or Ticket Type or Severity individually as well.

Change Management record is logged when there is a request for a change in the system. The change can be altering any property of the system like upgrading existing application to new version, integrating with other application etc. It is required to keep a track of what has changed and also to get necessary approvals from stakeholders as it would impact several users and possibly incur costs.

Service Request is usually logged when users need services. That service may or may not need change in the system. If it needs change in the system, another Change Request is logged and associated with the Service Request. The service may need approvals based on the organization policy.

Both Change Management and Service Request Management can have different workflows depending on the process identified in the organization. A Service Request may get serviced if its subsequent Change Request is not approved by CAB (Change Approval Board).

A Defect ticket can be created depending on the roles and permissions granted by tussom Administrator.

A Defect ticket can also be created from a Problem, if the person has appropriate roles and permissions to do so. Following are the steps -
1. Open the Problem ticket for which you need to create a Defect ticket.
2. Click on the 3 vertical dots that are displayed to the far right of the buttons provided in the Incident ticket.
3. Different submenu options will be displayed. Select 'Create Defect' from the list of submenus.
4. A screen to create Defect ticket will appear. Fill up all the necessary details in the fields displayed and click on 'Create'.
5. A new Defect ticket will be created and automatically linked with the Problem ticket.
6. The Problem ticket screen will be refreshed and the new Defect ticket created will be displayed in 'Related Items' tab of Incident ticket.

Note: The Problem ticket will ALSO be displayed in the 'Related Items' tab of Defect ticket. The Problem ticket cannot be resolved without resolving the respective Defect ticket.

Finding RCA (Root Cause Analysis) is the one of the core objectives of Problem Management that helps to reduce the number of Incidents. tussom offers 2 types of RCA in Problem Management - 

1. Interim RCA
This is applicable when a Problem ticket is created for S1 (or a critical) Incident. Since it is important to keep stakeholders updated about the progress, an interim RCA needs to be derived and shared it with them. An SLA is also set to ensure that the interim RCA is provided on time.

2. Final RCA
This is applicable for all Problem tickets. The Problem Manager can set the email ids of the stakeholders, select an approver to review the final RCA and update the details based on RCA template that is configured. A notification is sent to the approver, post which a pdf of RCA provided is generated and sent to respective stakeholders via email. An SLA is also set to ensure that final RCA is provided on time.

A Change ticket can be created by a Change Manager or Change Coordinator, depending on the roles and permissions granted by tussom Administrator.

A Change ticket can also be created from a Problem, if the person has appropriate roles and permissions to do so. Following are the steps -
1. Open the Problem ticket for which you need to create a Change ticket.
2. Click on the 3 vertical dots that are displayed to the far right of the buttons provided in the Incident ticket.
3. Different submenu options will be displayed. Select 'Create Change' from the list of submenus.
4. A screen to create Change ticket will appear. Fill up all the necessary details in the fields displayed and click on 'Create'.
5. A new Change ticket will be created and automatically linked with the Problem ticket.
6. The Problem ticket screen will be refreshed and the new Change ticket created will be displayed in 'Related Items' tab of Incident ticket.

Note: The Problem ticket will ALSO be displayed in the 'Related Items' tab of Change ticket.

Sometimes, the requester calls to reschedule the activity after the Service Request is logged. It becomes tad tricky if the SLA is applicable for that ticket and if the requester has asked to reschedule it to later than SLA time.

tussom offers to reschedule the activity without impacting the SLA. Following are the steps -
1. Open the Service Request that has been requested to start at a later time.
2. Click on 'On Hold' button to open relevant screen.
3. Select "Scheduled" from 'Next Status' dropdown.
4. An additional field called 'Scheduled Date' becomes visible. Set the new time to reschedule the activity.
5. Update 'Summary' and 'Detailed Description' to provide necessary justification to reschedule the activity.
6. Click on 'Submit'. The SLA will be paused from this moment till the new time set in 'Scheduled Date' field and the status is set as 'Scheduled'.
7. The ticket status will be automatically changed to 'Work in Progress' at the 'Scheduled Date' time and the remaining time in the SLA is resumed.

Note: The scheduled Service Requests are also displayed in the 'Scheduled Requests Calendar'. The Service Requests in red color are the ones that have not been resolved as per the schedule, the Service Requests in gray color are the ones that have been scheduled and dates are not past it. The Service Requests in green color are the ones that have been resolved as per the schedule.

Yes. The parameters to define SLA criteria are Ticket Type, Team, Category, Severity and Asset. In case of multitenancy, one can also define these separately for different customers/tenants as well.

One of the core SLA criteria is dependent on Category. When a new Category is set in the ticket, the new SLA, if defined for that Category will get applied to the ticket. The new SLA start time is considered when the new Category is set. If no SLA is defined for the new Category set, the SLA will not be computed.