The Problem:

This project began due to a fundamental problem that the company’s staff was dealing with on a daily basis. As community staff members who work in multi-family apartments that house hundreds of people, the employee’s number one priority is always to ensure residents are having the best experience possible while living at the community. This means preventing problems from occurring, or solving them as soon as possible if they do occur. This could be anything from a resident having a complaint about the poor landscaping behind the building, or a resident reporting a dead light bulb in the hallway. The onus was then placed on the community staff to ensure that these questions are answered promptly and that the problems were solved to their best of their ability.

The biggest problem that our employees faced was the fact that there was no organized system in place to collect, organize and manage the questions, comments and concerns from residents. Complaints, comments and concerns were coming in from a variety of channels. Employees were having conversations in-person or over the phone with residents to help solve their problems, but there was no documentation of it. Residents were messaging the community on Facebook, or leaving a message on the website, or calling into the office. There was no way to look back and know which residents had what issues or which employees were solving the issues (or if they were even being solved in the first place). Many times, these issues were written down on a post-it note, typed on a laptop or phone, or never recorded at all because the employee just relied on keeping it in their memory.

This was a major problem for the business because there was no way for us to track the efficiency of our employees or monitor our track record of delivering strong customer service. All of the interactions being had with our residents were done on an ad-hoc basis without any type of records being made for tracking.

The Goals:

• Build a Helpdesk ticketing system that allows internal users to create and manage tickets that pertain to questions, comments and concerns from residents

• Allow multiple channels to connect to the Helpdesk ticket so that residents to create a ticket from a wide variety of places that they prefer

• Decrease the amount of manual labor done by our staff by implementing automation to answer commonly asked questions

• Establish a dashboard for monitoring and reporting productivity

The Challenges:

• Onboarding staff to get used to using a new software solution instead of the casual ad-hoc ways they were used to

• Determining a way to collect and organize tickets based on importance, severity, etc.

• Establishing an automation system within the ticketing system to decrease the amount of manual labor required

The Result:

• Successfully delivered a Helpdesk ticketing system, saving the business an immense amount of money by avoiding purchasing a 3rd party solution

• Very well received by the users, citing improvements in efficiency and productivity

• An overall increase in customer satisfaction now that their problems are constantly being monitored and solved instead of being forgotten, lost or ignored

The Team:

• Lead Architect (Toronto)

• VP of Customer Experience (Houston)

• Customer Experience Manager (Houston)

• Product Manager (Toronto)

• Business Analyst (Toronto)

• 4 software developers (Toronto and Dublin, Ireland)

• UX Designer (Myself, Toronto)

The Tools:

Sketch, Invision, Outlook, Teams, OneNote, Confluence, JIRA

How was this all going to work?

The premise of the Helpdesk system was that we were going to allow residents to contact us through a multitude of channels for questions, comments or concerns. Those messages would then be automatically pulled into our internal software and turned into individual tickets that would be tied to the resident that created it. Once the tickets was created, our staff would be able to quickly see the message from the resident, as well as details about the resident, which apartment they lived in, how to contact them, and much more.

We needed to start with truly understanding the problems our staff were dealing with. First and foremost, it was important to understand some example scenarios of how staff members were handling interactions with residents at the communities. Once we learned exactly what going on at these communities and what problems needed to be solved, we would be able to empathize with both the staff and the residents and begin to make the experience better for both parties.

Phase One: User research and competitive analysis

Research for this project was heavily qualitative-based. Before the project was started, the only way for resident’s messages to be collected and tracked was through the resident portal. Residents were able to log into their portal account and send us a message and label it as either a Question, Comment or Concern. We would then receive this message into our internal enterprise software where it was listed in a basic table. That was the extent of the solution - a simple list of digitized messages with resident names and phone numbers attached them. From there, the onus was on the staff to periodically check the list and deal with each message one by one by calling the resident to follow up.

In order to find out what more was needed from the solution, we needed to rely on speaking with our staff members that were on the front lines dealing with residents everyday.

Through discussions via emails/messing and phone calls, we were informed on what the biggest problems our staff were facing at their communities. There was very little organization to how they were managing resident issues. Residents were contacting us about a question or concern, but their messages were being left unanswered for inconsistent amounts of time. Sometimes messages weren’t followed up on at all. Some residents would walk into the community office to speak with a staff member instead of typing a message on the portal, and there would be no record of the conversation or what actions were taken afterward. Staff members were bombarded with individual issues from residents and were required to work from their memories of conversations or post-it notes. Residents were frustrated that their questions and concerns were left unanswered or answered slowly due to mismanagement.

I started out with empathy maps to help put us in the shoes of the people going through the issues. Once we spoke to our staff members and residents about their problems and frustrations, putting that information into empathy maps helped make things more clear.

Since we were building our ticketing system from scratch, I wanted to stay cognizant of the fact that ticketing systems already exist. There was no sense in creating a brand new design that was completely different than what our staff members were already used to. Users appreciate familiarity between the apps that they use as it means that they need to spend less time learning how to use it. Our company used JIRA for managing tickets and deliverables, so I wanted to use that as a foundation to pull from for inspiration. JIRA offers many features that would be very valuable in our solution, and our team members were already comfortable using it, so it was a good place to start from for analyzing.

Researching other ticketing systems was helpful in a sense that it made sure that we weren’t going to leave out any important features. The more we brainstormed about the feature requirements, the longer the list of required features got. The experience of our lead architect and VP of customer experience was instrumental in giving us a place to start from, and the user research and competitive analysis that was conducted was great to helping us get granular with our requirements.

Phase Two: Architecture and workflows

Once we learned the problems we needed to solve and the features we wanted to include in our solution, our next step was building the architecture of the solution. We created workflows to help visualize the paths that a ticket could take, from inception to completion. With the many different routes being a potentially confusing thing to monitor, workflows helped immensely in keeping the paths clear for us as.

To solve the problem of our staff members lacking records of previous interactions with residents, we implemented an Activity Log feature that chronologically listed any activities that occurred with that ticket. Combined with the ticket details (who created it, when it was created, etc), it became clear that it would be good to display this information at the same time in a split screen format to prevent users from having to scroll up and down or go back and forth between screens. The ticket details and the activity log could be seen at the same time.

We also needed to include the aspect of tickets being assigned to particular employees. Not only that, but we needed to ensure that employees spent less time thinking and prioritizing and more time problem solving. We wanted the system to prioritize tickets for users automatically. This is what sparked the decision to have multiple tabs - one for all tickets, one for tickets assigned to one person, and one for priority tickets that required action from our staff. The priorities for tickets was determined by multiple conversations had with higher level stakeholders, particularly the VP of Customer Experience and our Lead Architect. The type of ticket combined with the amount of time elapsed since it was created also affects the priority of the ticket.

Key Features for the app:

• Ability to create a new ticket, and create tickets on behalf of residents

• Ability to assigned tickets to other people and watch other tickets

• Ability to link an existing service request to the ticket

• Ability to message the resident directly from the ticket

• Ability to log internal notes and conversations that occurred with the resident

• Ability to mark tickets resolved and re-open resolved tickets

Phase Three: High-fidelity prototyping

The beauty of the UI for this project is that it was built with a standardized design system that I created for the company. This sped up the design process immensely because the foundation and rules were already in place for the UI, along with reusable components. This enabled me to jump straight to high-fidelity prototyping rather than starting with low-fidelity.

The UI design was built on 3 tabs, one of which incorporated a card system. The card system was a visually appealing way for users to quickly absorb information at a high level before diving into a more granular level if they choose. This “Requires Action” tab also took the thinking out of it for users. They no longer had to ask themselves “Should I help this person or that person? Am I still waiting for a reply from this person or are they waiting for me?”. The automation system that our developers created automatically prioritized tickets so our users were able to take action quickly in a to-do list type of way.

Phase Four: User testing, pilot launch and ongoing tweaks

User testing was carried out with a small handful of communities, allowing for a small group of users to test out the app and give feedback on its design. Overall, the sentiments gathered were positive. Through several weeks of testing and collaborating with users through a Teams group channel, we were able to learn about small details that users were struggling with.

For example, a piece of feedback we received was that around resolving tickets. Helpdesk tickets are able to be linked to service requests, and when the service request is completed the linked Helpdesk ticket stays open. This is an example of the types of small improvements and tweaks that were made to the design based off user testing with our pilot release.

The pilot testing continued for several weeks as we spoke with users about their experiences using the solution and what improvements they had in mind. Some suggestions were quick and logical so we were able to easily implement them, while others were put on the back-burner for further discussion and consideration at a later date. All in all, the user testing was highly successful in giving us insights about how users were using the product, as well as a great source of opinions from the users about ways to improve the design in small but effective ways.

Following the pilot launch and design improvements, the solution has since been expanded and released to all communities with great reviews.

Which goals were achieved and what was learned?

Our Helpdesk ticketing system has been a huge success since its release. We were able to achieve the goals of building a system where staff and residents can communicate in an organized way and keep records of the interactions on both ends. Residents were also given visibility into the status of their tickets through the resident portal app, meaning they no longer needed to rely on our staff to answer every detailed question or get an update about their issue. Residents are now able to contact the community and a ticket will be created automatically for our staff to then action based on priority. Whether it’s from social media, an email, a text message or anything else, tickets will now be automatically created for easier managing.

The next major goal that we will be working on regarding this solution is creating a dashboard to manage metrics about productivity. A key to ensuring this Helpdesk system stays efficient is tracking staff member’s productivity to see how effective we are at solving problems and delivering great customer service. Once the key metrics the business wants to track are determined, we will begin the process of designing a dashboard system where those statistics can easily be tracked and used for reporting.

A major lesson learned working on this project was our initial underestimating of the amount of complexity there was behind ticket routing. Tickets can be created by a multitude of people from a multitude of sources with varying urgency levels, and we spent a lot of time re-working our plans for how tickets would be directed and who they would be assigned to. Many of these complexities weren’t able to be uncovered until we got into the details of the design, but it was definitely a lesson to not underestimate the complexity that a workflow can have with a major project like this one.

Overall, the Helpdesk system is active and running well and our staff members are enjoying the benefits of increased productivity and clarity while our residents are being better served in a more organized and structured way.

Thank you for reading! Feel free to explore my other case studies to learn more about the wonderful products I’ve contributed to.