Setting Up Own ITSM Environment

The first step was requesting a new ServiceNow Personal Developer Instance (PDI) on developer.servicenow.com. Once the instance spun up, an admin account was received and the login completed for the first time. This was a "blank canvas" an empty ITSM environment where users could be created, work simulated, and the impact of roles on system behavior observed.

Three required personas were then created:

• ITS User the customer
• ITS Agent the Service Desk Agent
• ITS Manager the ITSM manager

Each account had different permissions. The User could only access the Service Portal. The Agent could view, edit, and resolve incidents. The Manager had full visibility across dashboards, reports, and all tickets. Assigning roles and testing logins made an appreciation grow for how much ITSM depends on access control, not just process flow.

Creating First Incident as a Customer

Once all accounts were ready, the mindset shifted into that of a frustrated employee. Logging into the Service Portal as itsuser, a real ticket was submitted:

• Short Description: Wi-Fi not working
• Description: Cannot connect to Wi-Fi in the lab.

Submitting it felt surprisingly real almost like reporting an actual campus network failure. The incident appeared in My Incidents with the status New, waiting for the Service Desk to take over. It was the first time viewing the platform from the user perspective: simple, guided, and focused on clarity.

Becoming the Service Desk Agent

Next, the itsagent account was logged into. This role immediately gave access to incident queues, workspaces, and the activity history of each ticket. Opening the Wi-Fi ticket, the exact steps a Service Desk Agent would perform were completed:

• Triage the incident
• Assign the case to self
• Change the state to In Progress
• Write work notes explaining diagnosis steps
• Resolve the case with a clear resolution message

This experience helped to finally understand the difference between customer updates, work notes, and state transitions. Everything had a purpose: Work notes served as internal communication. Additional comments were visible to the user. State transitions reflected progress in the lifecycle. Even resolving the case required selecting a proper "close code," showing that ITSM is built on consistency and documentation, not guesswork.

Returning as the Customer

After closing the ticket as the agent, the switch back into itsuser occurred. In the Service Portal, the Wi-Fi ticket now displayed the status Resolved, with the agent work summary included. This last step the customer viewing and closing their own resolved ticket made clear how user trust relies heavily on visibility. When users see their issue documented, updated, and resolved transparently, IT feels reliable and responsive.

Exploring the Manager View

Finally, the itsmanager account was logged into. Unlike the agent, who works with individual records, the manager sees the bigger picture. Dashboards showed workload distribution. Reports summarized daily and weekly statuses. It was the first time seeing how ServiceNow transforms raw tickets into operational insight. Managers are not just supervising agents; they are monitoring service health at a strategic level.

Reflection

Week 6 was the first true encounter with ServiceNow not as a passive learner, but as someone navigating different IT roles. By switching between customer, agent, and manager, it became clear how structured and interconnected the incident lifecycle really is. Every step, field, and transition matters, because each role depends on the accuracy and clarity of the previous one.

This pre-lab prepared for the much larger Week 7 simulation. It taught that ITSM is not just about solving issues it is about designing clear pathways, enabling role-based collaboration, and ensuring that every incident tells a complete and traceable story.