Here I was tasked with creating a conceptual data model for the Performance Management department of NYC311, the call centre for New York City's non-emergency number. This involved doing a lot of research to determine what entities should be included in the model and how they should relate to each other.

Introduction

New York City’s 311 call centre (NYC311) is a one-stop-shop for residents when they have any queries or concerns related to city agencies. When it comes to serving a city with the nickname “the city that never sleeps” and a population greater than that of New Zealand, it is vital that NYC311 operates as efficiently as possible (Accenture, 2013). The responsibility of increasing this efficiency is spread across NYC311’s departments, however most of it arguably falls upon the Performance Management department (Wiseman, 2014). The Performance Management department aims to meet this responsibility “by facilitating data-driven performance management, providing insight into performance through standard reports, a comprehensive business intelligence tool that delivers a full range of analytics, and reporting capabilities" (Wiseman, 2014, p. 4).

In this report, I will first look at the core business goals of NYC311 and where the Performance Management department fits into these. Secondly, I will investigate the Performance Management department’s data requirements. Lastly, I will provide a conceptual data model for the Performance Management department along with some explanation of my thought process when constructing the model.

Core business goals

NYC311 was conceived by former New York City mayor Michael Bloomberg with the main aim of making it easier for residents to get the service they needed from city agencies (Wiseman, 2014). By condensing 4,000 phone book entries into one simple phone number, as NYC311 Deputy Commissioner Joe Morrisroe put it, “the burden [is now] on the city to solve the problem, not the citizen” (Wiseman, 2014, p. 7).

This centralisation of services was not only an improvement for citizens, but also for the many agencies involved, as it enabled them to focus on their core missions instead of providing customer service (Accenture, 2013). Similarly, the creation of NYC311 was successful in diverting non-urgent calls away from the 911 emergency number (Accenture, 2013).

With the responsibility now on NYC311 to solve all of the city’s problems, as Morrisroe said, “we can’t be right some of the time, we have to be right 100 percent of the time” (Wiseman, 2014, p. 9). This is where the Performance Management department comes in, helping NYC311 to deliver the best results possible through performance analysis and holding the organisation accountable through reporting.

Data requirements

As mentioned in the introduction, the Performance Management department is tasked with generating reports and analytics of NYC311’s performance (Wiseman, 2014). The main destination for these outputs is cited as being the Citywide Performance Report, which cumulates data not just from NYC311 but from all city agencies (Wiseman, 2014; Accenture, 2013). However, things may have changed since these sources were published, as I could not find performance data for NYC311 in the Citywide Performance Report; instead I found it in the Mayor’s Management Report (MMR), which is published twice a year and similarly includes statistics from all city agencies (Mayor’s Office of Operations, n.d.). Either way, the publication of this performance data is necessary not only to provide insight to the agencies and local government, but also to promote accountability and transparency by making the data publicly available (Accenture, 2013).

Table 1: NYC311 MMR indicators. Adapted from Mayor’s management report: Preliminary fiscal 2023 indicator definitions, by E. L. Adams, C. J. Varlack and D. Steinberg, 2023a. Copyright 2023 by City of New York.

^a According to Adams et al., “Tier 1 is the general 311 call queue, which excludes callers that select one of the menu options”; and the Peak hours are 11am-3pm Monday to Friday, with all remaining time being Off-peak hours (2023a, p. 103).

The indicators included in NYC311’s chapter of the MMR offer a clear representation of the Performance Management department’s data requirements. Table 1 gives a summary of these indicators. Of the twelve indicators included, only one is sourced from outside of NYC311: the customer satisfaction index. The data on customer satisfaction is collected by CFI Group Inc., who survey NYC311 customers on their ideal, desired and actual customer experiences and then use these to calculate an overall customer satisfaction index (Adams et al., 2023a). Although this data comes from outside of NYC311 I will still be including entities for it in my model, as I assume that CFI Group provides NYC311 with the raw data (such as individual survey results) for analysis purposes.

When looking through the other chapters of the MMR, it is apparent that many other agencies use relevant NYC311 data as indicators, such as the percentage of service requests they are tasked with which have met their service level agreements (Adams et al., 2023b). I have chosen not to focus on this aspect in my model, as it does not pertain to the performance of NYC311 but rather to the performance of those other agencies.

Conceptual data model

Figure 1: Performance Management conceptual data model

Figure 1 shows my conceptual data model for the Performance Management department of NYC311, created using Vertabelo. The model includes text annotations where I explain my assumptions regarding entities, attributes and business rules. To avoid further crowding the model with annotations, I will talk about the relationships between entities here.

CUSTOMER - INTERACTION

The INTERACTION entity represents interactions or contacts between customers and NYC311. The relationship between CUSTOMER and INTERACTION is mandatory, as I assume that a customer cannot register without interacting. An interaction can only belong to one customer, but a customer can participate in many interactions.

INTERACTION - SERVICE_REQUEST

By making INTERACTION and SERVICE_REQUEST separate, I am assuming that not every contact leads to a service request. These entities have a many-to-many relationship as many people could contact NYC311 about the same problem for which a service request has already been made, and there would be no need to make another. Meanwhile, one interaction could require multiple service requests to be made.

CUSTOMER - CUSTOMER_SURVEY

This entity is associative. Customers do not have to participate in the survey, but they may also be surveyed more than once (for different interactions across different periods).

PERFORMANCE_DATA

This entity draws together all the data needed for the MMR report. This data could be derived at the point of making the reports instead of being stored as an entity in the database, but I imagine that it would be useful to store it for further analysis and comparison across time.

Performance data will include many interactions, but each interaction can only belong to one set of performance data, and some may not be related at all if they are not a relevant channel. Performance data will include many service requests, and all requests can only belong to one set of performance data; it is the same case with articles. Performance data will only be related to one satisfaction index – the one with the matching period – and that satisfaction index can only belong to one set of performance data.

References