What is the Digital Legacy Clinic?

The Digital Legacy Clinic is a project that I am a part of at CU Boulder that focuses on helping clients to sort through and memorialize their deceased loved ones' online presences, as well as offering advice for end-of-life planning of digital accounts and data. This clinic is completely online-based, so to manage each individual client, having a help desk organizational system was absolutely essential. I wanted to learn more about how to implement and maintain an organizational service like this for our project, so I chose to be a part of the help desk, and we decided to use ServiceNow to serve the Digital Legacy Clinic.

My Part in the Digital Legacy Clinic

The overall goal that I was working towards in this project was to create a ServiceNow instance to support our Digital Legacy Clinic, which included 15 people. This instance would need to be able to maintain email communication between us and our clients, organize cases for assigning to members, and be accessible for continuous research by the clinic. It was difficult to define the client scope initially as interest in our service was uncertain, so I needed to prepare our ServiceNow instance for any number of clients that might need our services. I knew that we wouldn’t need a super fancy instance, so I decided to focus on two major aspects: learning what core features of ServiceNow would be necessary to perfect for our launch, and learning as much as I could about our team’s needs to adapt the instance for our clinic.

Front End Implementation

For the customer-facing side of the service, we wanted a process that would be as straightforward as possible with no technological hoops to jump through, as the goal of our service was to provide technology support to those who might feel confused or overwhelmed by technology. This helped us solidify the idea of a help desk for the service, where clients could submit a ticket to us through a webform, and then would just email back and forth with us or set up a zoom call if needed to resolve the issues that they were having.

One of the most important things for us to figure out was how we wanted to create the webform. The goal was always to get as much of the client’s information upfront as possible to reduce the load of information that we had to get through emails and create a quicker and smoother process. However, as we discussed options for the webform such as requiring the client to list all the platforms or types of platforms that they needed help on, listing their relationship to the deceased, or other demographic information we realized how quickly this could be an overwhelming prospect for the client when they are already feeling overwhelmed by all of this. Thus, for our first implementation, we decided to keep the webform as simple as possible to see what sort of information the clients felt compelled to give to us, and learn more about their needs and goals in a more natural way. This is something we will continue to return to and revisit, but creating a low barrier of entry for the client felt like the most important thing for the beginning of the service, and we could learn what things were being left out that were most important to require information on later.

The other biggest question that we had on the client’s side was how to handle university breaks. This is something that is completely inevitable with our service being run by students, but we wanted to minimize the disruption to clients as much as we could. For cases that were currently active, we’d include in follow up emails that we will be out of office for the break, ensuring that our email gave the client something that they could do to advance the case in the meantime in case they needed results quickly. For cases that had come in but were unassigned, we had the email system set up to include this break message in the automated email after submitting a form, and when we could we’d still try and have personalized messages to clients letting them know that we are here for them and will help them with their case as soon as we can.

Back-End Implementation

Before we could get our hands on the ServiceNow instance, we first had to coordinate setting up the instance with the OIT team at CU Boulder. The process was fairly straightforward, although we did have to discuss and confirm what sorts of close codes we wanted to implement to resolve cases, which was tricky to decide on early in the process. Since we didn’t have access to the instance or the official CU Boulder ServiceNow training at this time, I started my own research by looking at how other companies use ServiceNow, especially in IT fields, as it felt like a good starting point. After a few weeks, we gained access to the ServiceNow instance, and that made it a lot easier to grasp the platform and how it could suit our needs.

I began by taking the official CU Boulder ServiceNow course, taking notes on every aspect of the platform that was brought up and speculating on if each feature would be useful to us or not. I compared notes with my partner on the ServiceNow project and discussed key areas with the clinic’s director, such as how we want to handle working primarily with clients outside of CU Boulder and what sorts of tools like reports and condition building could be useful for research.

Once we had discussed all of this, a member of the OIT team taught the clinic how to use ServiceNow over Zoom. My partner and I both took notes on areas of confusion or tension throughout the training to understand what might be difficult for both current and future clinic members learning how to use ServiceNow. Afterward, we worked on making the instance as helpful to the clinic as we could, fine-tuning the system to suit our specific needs.

A big part of this fine tuning came during the pilot cases that we did over the course of two weeks, where we worked with clients who were aware that we were still in a testing phase. We were learning how we needed to handle cases when they came in, which included immediately filling out areas in ServiceNow such as the nature of issue and creating a short description for us to understand the goals of the case. When assigning cases to clinic members, we saw how important it was to try and ensure that we were personalizing who got cases as much as possible, so that for example someone with a music production background could be the one to help with a case involving Soundcloud and Bandcamp, helping the client to feel a more personal connection to the person on the case and trusting their expertise more. All of this created a workflow that we could trust to consistently provide support for out clients.

Challenges and Solutions

One challenge early on was deciding what close codes we wanted to implement for resolving cases. This was difficult because we were so early in the process and didn’t yet have access to the instance or training. To address this, I began independent research into how other companies use ServiceNow, particularly in IT fields. This taught me that each institution develops its own language and ecosystem with the platform, which added complexity but also provided an understanding that our ecosystem would continue to develop as we did. I decided that we should use simple, straightforward close codes that wouldn't require us to structure our workflow in any particular way but that would be flexible to allow us to tag cases that were successfully resolved, not successfully resolved, or cases that might've just inherently been outside of the scope of what we do.

Once we started using ServiceNow, we faced a challenge with email confirmations for clients. Clients weren’t receiving confirmation emails when submitting tickets through the website because the webform treated the sender as our WebExpress email account. To solve this, we worked with the OIT team to create a parsing script that extracted the client’s email address and implemented it into the ticket. This allowed clients to receive confirmation emails and ensured we had their correct email on file.

During launch week, we discovered an issue where every client-submitted webform created duplicate tickets. This resulted in clients receiving two confirmation emails with no clear indication of which ticket was correct. After investigating, we confirmed with the WebExpress team that this issue was widespread across the university and had no immediate fix. To work around this, we manually consolidated duplicate tickets. While this wasn’t an ideal solution, it taught us the importance of staying organized and flexible when dealing with systemic issues. Despite these challenges, we successfully launched ServiceNow and continue to provide effective support to our clients.

Outcomes

The outcomes of this ServiceNow instance integration were substantial, as we were able to successfully support our clients needs through this platform. Throughout the pilot, we were able to support 8 clients, and in the first week of our launch we supported 17 clients. The infrastructure that my team created is continuing to support and manage new cases as they come in. Through discussion about what we want to focus on and boundaries that we will need to set in regards to the kinds of cases that we can take on and the scope of cases that we can handle, we feel well equipped to handle the continuing success of the clinic as it further develops.

Reflection

Being a part of this team to implement the help desk for the clinic taught me a lot about the kind of role that IT can play in larger scale projects like this. Because the help desk was the backbone of our operation in a sense, consistent communication with every team was necessary at every step of the way to ensure that each team who needed their work implemented into the clinic could successfully have it implemented. We also had to keep communication with other sources within the university, such as OIT and the WebExpress team, and sometimes these groups wouldn’t necessarily have us as a top priority when we had service breaking issues such as duplicate tickets being submitted every time a client filled out our web form, and learning how to handle these issues that might not have an immediate solution was a good thing to learn, even though it was also frustrating. Overall, I felt very fulfilled being able to work on the backbone of our clinic, and I feel much more prepared to continue to provide IT related institutional support and attention as well as implementing the communication strategies and habits that we developed here wherever I am working next.