I recently moved from help desk work into a sysadmin role at a new company, and we're preparing to replace a very outdated ITSM system with SysAid. I haven't had much hands-on time with it yet, but it appears to offer significantly more capabilities than our current tool.
The implementation discussions will cover improving ticket creation for both employees and the help desk, troubleshooting workflows, reporting, asset information, and automation. I'd especially like to make sure the platform contains useful, accurate data and that automation can reduce repetitive help desk work.
For workstations, servers, and point-of-sale systems, I'm 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 employee onboarding and offboarding, password-reset and account-lockout guidance, automatic replies, and reminders or status changes when a ticket is waiting for a response.
For anyone who has implemented or migrated to an ITSM platform, what would you prioritize? What common mistakes should we avoid? I'd also appreciate practical SysAid-specific advice, particularly around asset discovery, CMDB data, integrations, self-service, change management, reporting, and workflow design.
5 Answers
Create an integration roadmap early. Identity services, directory platforms, collaboration tools, HR systems, monitoring, endpoint management, and your existing discovery solution can all improve ticket routing and lifecycle automation. Decide which system owns each piece of data, who will create and maintain credentials or API access, what sync frequency is needed, and how failures will be detected. Also test the licensing and discovery costs carefully before committing to a design.
Start by looking at what your existing system is missing and what information would actually improve your most common requests. More fields are not automatically better; unnecessary data creates noise and makes forms harder to use. Review the top recurring ticket types and identify which ones can use self-service, approvals, templates, or automation. Self-service only works if the user experience is quicker and clearer than emailing the help desk.
Keep the first release focused on a few high-value workflows: onboarding, offboarding, access requests, password and account-lockout guidance, common service requests, approvals, and waiting-for-customer reminders. Define clear categories, priorities, ownership, escalation rules, service targets, and reporting requirements before building lots of automations. A smaller set of reliable workflows is much better than a large collection that users and technicians don’t trust.
Treat the implementation as a full process redesign rather than just replacing the old ticketing screen. Build the employee portal first, make it easy for people to submit and track requests, and collect the information needed to route and resolve tickets. Also include change management and major-incident management from the beginning instead of leaving them for a later phase.
Be skeptical of automated discovery until you test it against your real environment. Use the proof-of-concept period to measure what SysAid can discover across endpoints, infrastructure, cloud resources, and less typical devices, then compare that with an independent inventory. Establish a baseline CMDB and track coverage over time instead of assuming the discovery scan is complete. Only send useful attributes from your existing discovery tool rather than importing every available field and creating unnecessary network or processing load.
For configuration items, the most useful basics are usually a stable identifier, hostname, serial number, device type, manufacturer and model, operating system, IP or network details where relevant, location, owner, lifecycle status, and last-seen date. The exact list should depend on which incidents, changes, and reports you need to support.
A phased rollout is fine, but make sure there’s a defined plan for classification, priorities, knowledge articles, service-level targets, ticket reviews, and onboarding or offboarding workflows. Otherwise the new platform can remain only a basic ticket queue for a long time.