I recently moved from a help desk position into a sysadmin role at a new company. We are replacing an old, outdated ticketing system with SysAid, and I want to contribute meaningfully to the implementation.
The main discussions will involve improving ticket creation for both employees and the help desk, troubleshooting workflows, reporting, asset and configuration data, and automation. I am especially interested in making useful information available in the platform while reducing repetitive help desk work.
For workstations, servers, and point-of-sale systems, I am considering tracking details such as hostname, serial number, manufacturer and model, operating system, location, assigned user, last-seen time, and boot time. Potential automations include onboarding and offboarding, password-reset and account-lockout guidance, automatic replies, approval workflows, and reminders when a ticket is waiting for a customer response.
For anyone who has implemented or migrated to an ITSM platform, what would you prioritize? I would also appreciate practical SysAid-specific advice, especially around asset discovery, CMDB design, integrations, reporting, self-service, and automation.
4 Answers
Make the employee portal simple and useful. Let people submit requests, check ticket status, find clear self-service instructions, and provide the information the help desk needs without making the form feel like an interrogation. Change management and major-incident management are also worth designing early instead of bolting them on later.
Start with business value instead of collecting every possible asset field. Look at the most common requests and incidents, then ask what information would actually improve resolution, routing, approvals, or reporting. For assets, ownership, location, lifecycle status, support details, criticality, and relationships are often more useful than a huge collection of rarely used technical attributes. Also make sure self-service is fast and intuitive, or employees will bypass it.
The biggest mistake is treating implementation as something to do halfway. Define the processes, ownership, required data, review cycles, SLAs, knowledge articles, and reporting before launch. A platform can technically be live while still lacking basics such as ticket classification, priority guidance, change approvals, and regular ticket reviews.
That is exactly what I want to avoid. I have seen platforms go live with only a few forms and categories configured, then remain in that basic state for months because the rest of the process was never planned.
Plan the integrations early. Directory services, identity and access management, HR, collaboration tools, monitoring, and endpoint-management systems can remove a lot of manual work, especially for onboarding, offboarding, account changes, and incident creation. Make a roadmap that identifies the owner for each integration, the required credentials or API keys, dependencies, and a realistic delivery timeline.
Our current system barely supports a user portal. I am also trying to understand how to handle change management in the new platform rather than continuing to track everything in a separate project tool.