Integrated Research is a company offering real-time payments monitoring, unified communications and call center quality management in the B2B Enterprise Space. At the time of writing, there were SaaS licenses offered to customers to monitor their communication environments.
I worked on the Collaborate portfolio in the suite of products we offered. It allows UC and Voice Engineers primarily to monitor their Unified Communications systems such as Zoom, Cisco Webex, and Microsoft Teams. This is offered as a Cloud or On-Premises product for both Enterprise and Service Provider Customers, extending to This extends to older telephony technologies for Enterprise and Call Centers.
For the Collaborate product, we catered mainly to advanced UC (unified communications) Engineers who need to monitor how their company (or client's) video conferencing or call center systems perform. From our internal research, we saw that users would depend on a range of tools and software to complete day-to-day tasks.
KPIs
A key piece of software they would use for managing support tickets was ServiceNow, a separate platform that can help them delegate, review and close tickets once they have been resolved. Engineers and Help Desk Staff usually have set KPI’s so working efficiently is both important for the business and their own professional reputation.
Whilst they could set Alerts in IR's cloud platform, users still needed to manually closer alerts in ServiceNow
Any time lost for users or double data entry (which I was aware of before I started the project) takes away time that might be better used for solving the problems within the tickets, as opposed to the arduous admin work to manage them.
Early notes taken during a User interview held with a customer (Credentials have been anonymised for privacy purposes)
I started out the project in close collaboration with one of product managers who had close ties to the customer using Service Now and began an investigation of our product (Collaborate Cloud) as well as ServiceNow to get an idea of how both platforms allow users to set alerts, what statuses might look like as well to aid what questions I’d like to ask in user interviews.
Once I had a grasp of these concepts, I scheduled in some sessions with customers from a few companies, namely users closer with using ServiceNow, as they would be the benefactors of the end solution.
I learnt about a few key points that would need to be addressed in a possible solution which were:
Sketches of the types of alert use cases that would interact with ServiceNow in bell curve form
Once we had a better grasp on how we might solve this problem, the product manager and I got to work. We drafted up graphs (seen below) showing how alerts currently worked with the settings already present in the platform. This helped us understand how triggers could be used to open and close alerts, complex logic which user’s expressed was something they needed retained and ideally working with their ServiceNow environment.
What became more evident to us both in this process was how we needed to have dynamic alert logic to cater for how a user may want an alert to work and then send/react to a status from ServiceNow.
Once the flow and rules were all mapped out, I ran them past our development and solution engineer teams (who both have intimate knowledge of the plaform's technical limitations) to see if there were any loose ends to tie up before conducting user testing with our clients.
We came to the conclusion that given the deadlines & budget we had for this project, we couldn't rebuild our alerts workflow so we decided to optimse existing settings users were familiar with. One way we did this was allowing Service Providers (who manage multiple customers in their account) to configure ServiceNow once but choose which clients it would feed down. This meant they wouldn't need to sign into multiple sub accounts for the purpose of setting up the ServiceNow Alert Logic.
We ran a total of 3, 1 hour user tests across 3 different customers who were all using ServiceNow. The test itself took users through the process of setting up a new Alert and giving them the ability to try creating:
These were key points put under the microscope with our users as they require this for compliance reasons. An example that was in my mind as a north star was that help desk staff are liable for the support tickets they create and therefore may need to acknowledge a ticket before they can close it as a KPI requirement.
These tests were met with mostly positive feedback from those interviewed, with some key takeaways around further more complex alert automation which would be considered for further enhancements.
Whilst this feature wasn't as complex as users may have wanted, impacted by budgetary and developmental resourcing constraints, we found that users were still impressed with how they could modify their own alert rules and easily integrate with ServiceNow.
Afte the release of the features, users they gave this enhancement a 7 out of 10 in post-release interviews (with 10 being the best result and 1 being the worst). This was awarded for the complexity and delicacy taken catering to their alert creation and support ticket compliance needs.
