Lokad Call Center Calculator Project specifications Summary: This project consists in implementing “Lokad Call Center Staffing” (L3C) is a simple reporting application in C#/WinForms/.NET 2.0 under Visual Studio 2005. The application is focusing on call center managers who need to optimize staffing levels in their call centers (too much staff and operators stay idle, too few staff and waiting time drive customers crazy). In a nutshell, L3C displays a single report (a table) where each column represents a day and each line is associated to a time period of the day (ex: 96 lines for 15min periods over 24h). The cell content is typically the number of incoming calls during the period (either past data, or forecasted data). This application leverages the online Lokad forecasting services to provide staffing suggestions. The following elements must be considered This project does not require any domain knowledge about call center management or forecasting. Those elements are “encapsulated” into classes that will be implemented by the Lokad team. The project will be implemented as open source and released under the BSD license. A skeleton for the application has already been designed. The code is available in the SVN repository of the Lokad project on SourceForge.Net (http://sourceforge.net/projects/lokad). The architecture chosen for L3C follows a model-view-controller pattern (with a data presenter for the view). The model has been designed (that’s the existing skeleton). Most of the work will happen on the view and controller. L3C is an extension of “Lokad Desktop Workload Forecasting” already released as open source (see http://www.lokad.com/DesktopSalesForecasting.ashx ). The codebases of the two applications have been separated, but the “old” application code is available. To be delivered The following elements are to be delivered (details provided in the following) NUnit tests covering all the delivered code (whenever reasonably feasible). A complete implementation of the model-view-controller pattern that has already been drafted (the pattern also includes a data presenter). A complete implementation the WinForm application named as L3C that wraps the model- view-controller pattern. An call logs adapter for Vicidial in MySQL under .NET (a MySQL dump will be provided), plus a mock adapter for testing only (Vicidial is an open-source application). All the delivered code is expected to be documented and compliant with the coding guidelines that apply to every .NET applications. IMPORTANT: We are looking for a recurrent relationship because this specification is just the V1. We are already planning more features for the future. Also, the only supported application for the V1 is Vicidial, but we are planning to support many other applications as well. A big picture of L3C L3C is (somehow) an extension of “Lokad Desktop Workload Forecasting” (see the screenshot below). The application displays a drop-down to select the “Queue” (each queue being associated to its own pool of operators). Then, the historical call volumes (i.e. number of inbound calls) are displayed over a yellow background, and the forecasted call volumes are displayed over an orange background. Only a single queue gets displayed at a time. L3C will follow the same principle. L3C will keep the same structure than “Lokad Desktop Workload Forecasting”, i.e. days as column and daily periods as rows, but it will be provide a richer view with the ability to display selectively Call volumes Agent counts L3C has a modular architecture where “adapters” can be designed to import most of the data from 3rd party applications (typically call center applications). Thus L3C relies on two remote services The 3rd party application from where the call data (among other) is retrieved. The Lokad Web Service that provides the forecasts. From the user point of view, the typical data cycle is 1. Call data is retrieved from the 3rd party application. 2. The past call data get uploaded to Lokad. 3. The forecasted call volumes are downloaded from Lokad, and user gets a complete staffing report. 4. The report includes default suggestions for the number of agents (based on the forecasts). The user can edit the planned agent counts. 5. The user can (optionally) export planned agent counts. Getting started with the source L3C is an open source application. The drafted skeleton is already available on the Lokad project on Sourceforge.NET at http://sourceforge.net/projects/lokad . The Subversion URL: https://lokad.svn.sourceforge.net/svnroot/lokad/callcenterstaffing Build Server: http://build.lokad.com At this point reading the specification, we suggest to checkout the Subversion directory in order to get a more detailed view of the draft. SUBVERSION PRACTICES: you will be granted a developer access to the Lokad project on SourceForge. We are expecting daily commits, or so, on the Subversion repository while the work is in progress. LOKAD NOTES: This project Lokad Desktop Workload Forecasting Lokad Call Center Staffing is highly similar to a project Lokad Desktop Sales Forecasting Lokad Safety Stock Calculator that is already under way within the Sourceforge project. Historically, Lokad Desktop Sales Forecasting and Lokad Desktop Workload Forecasting were having nearly identical architectures. The developer of L3C will be expected to produce a consistent architecture with Lokad Safety Stock Calculator. You will be able to discuss with the developers in charge of Lokad Safety Stock Calculator. Foreword on the model-view-controller pattern In the context of L3C, the purpose of the model-view-controller (MVC) pattern is first to provide a more readable and comprehensive architecture. Yet, the 2nd concern is to enable the possibility of reusing most of L3C libraries into another .NET application (for example: a .NET call center software that would like to include a staffing report). In order to do that, the MVC must as independent as possible from the stand-alone WinForm application that wraps it. The model The data model is a class named CallCenterModel (this class is already drafted). The class contains the list of call queues and their associated data. L3C handles a single CallCenterModel at a time. This instance represents the call logs and the allocated agents within the call center company. The data contained in the CallCenterModel is primarily populated (and then updated) through a class that inherits ICallLogsAdapter. Every supported 3rd party application gets its own call logs adapter. This adapter keeps data such as the connection string (required to access the remote database) but also the definition of the SQL queries required to retrieve the data. The CallCenterModel contains a list of IQueue instances. An IQueue represents a call queue within the call center, i.e. a set of operators that are allocated to answer a certain type of incoming calls. Each IQueue contains (as main elements): Queue identifier: retrieved through the adapter. Queue name: retrieved through the adapter. Past call counts: retrieved through the adapter. Forecasted call counts: retrieved from Lokad using the historical data. Past agent counts: either retrieved through the adapter or manually entered. Planned agent counts: calculated based on the forecasted call counts (formula being coded by Lokad). The user has the possibility to manually modify the initial suggestion purely based on the forecasted call counts. Expected service level (single value): manually entered by the user. Average speed of answer (single value): idem. Average call duration (single value): idem. Average wrap-up time (single value): idem. Note: wrap-up time, the time needed by the operator for the work that happens after each call (like completing its notes). The model is (essentially) already complete in the draft implementation. The call logs adapters Call logs adapters inherit a class named ICallLogsAdapter. This interface is already drafted and acts as an abstraction layer between L3C and the actual SQL queries that are performed against a particular 3rd party application. Two call logs adapter implementations are expected A mock adapter for testing only. Instead of actually performing SQL queries, mock data gets directly generated. “Lokad Desktop Workload Forecasting” already implements a mock call logs adapter (must be adapted for L3C). A Vicidial adapter. Vicidial is a popular open source GUI for call center management. No particular knowledge is required about this application. The adapter will simply consists in a few SQL queries. “Lokad Desktop Workload Forecasting” already implements a call log adapter (must be adapted for L3C). All 3rd party applications are not born equal: some call center package may only record incoming call while some other might also record available agents, call durations, wrap-up durations (i.e. worktime needed by the agent after the call), … The call logs adapter reflects this situation with properties such as IsQueueAgentLogAvailable indicating whether the agent logs could be retrieved directly from the adapter or not. Lokad communications: Lokad.Web.Services The .NET interfaces to communicate with Lokad (SOAP) have been already setup in a DLL project named Lokad.Web.Services. “Lokad Workload Sales Forecasting” already implements call counts upload and call counts download (must be adapted for L3C). The controller The controller has 4 main tasks (to be implemented) Retrieving the data from the call logs adapter and populating the call center model. Uploading the call data toward Lokad. Downloading the call forecasts from Lokad. Exporting the agent counts data. A special attention should be paid to DATA PAGING. The Lokad Web Services have documented restrictions (see http://ws.lokad.com/TimeSeries.asmx ) on how much data could be uploaded at once (ex: no more than 25000 time-values at once). The implementation must comply with those restrictions. The call logs adapter must also comply with paging constraints for the call data retrieval (because the amount of sales data can be too large to be queried entirely at once). Also, the implementation of call logs data retrieval and sales data upload is expected to be INCREMENTAL: retrieve or upload only the data needed since the last operation. Depending on the implementation (the details being left to the care of developer), the controller will have also to handle the user interactions with the report (ex: when the user changes the “service level” value). Notes: Those operations should be expected to be quite long. Thus, they need asynchronous executions (think progress bar during the execution). The symmetric application “Lokad Safety Stock Calculator” already implements several patterns to handle those asynchronous operations. The view The interface of the report itself will includes threa main areas A toolbar on the top for report-wide operations (i.e. retrieve data, upload data, download forecasts). A sidebar on left for display settings. Those settings only apply to the “queue” being displayed. Notes: this sidebar did not exist in Lokad Desktop Workload Forecasting. A DataGridView on that contains the bulk of the report. The sidebar The sidebar contains all the queue-specific settings. All the controls get listed vertically, eventually if the control list is too long the sidebar will be vertically scrollable. List of settings of the sidebar Service level: a number comprised between 0.00 and 100.00 (Note: internally the value stored for service level is between 0 and 1, but for readability it should be expressed as a percentage). Expected speed of answer: duration expressed in minutes (Note: internally, the value will be a TimeSpan). Average call duration: duration expressed in minutes (TimeSpan, idem). Average wrap-up duration: duration expressed in minutes (TimeSpan, idem). Day start & Day end: two time values that defines the range of hours that should be displayed in the report. A list of 7 checkboxes for each day of the week. Only the checked days are displayed in the report. Past weeks: number of weeks to be displayed as “past” in the report. Forecasted weeks: number of weeks to be displayed as “future” in the report (one or two weeks). When changes are made to the sidebar, the changes will be expected to be immediately reflected on the report. State management: the states of those controls are expected to be reflected in the “model” (i.e. CallCenterModel), and thus to be persistent if the model is saved. The toolbar The toolbar contains buttons triggering an asynchronous operation (with a progress bar) Retrieve: retrieve data from the call logs adapter Upload: upload data toward Lokad Download: download forecasts from Lokad. Export: export the future call counts and agents counts (was not included in Lokad Desktop Workload Forecasting). We suggest to use BackgroundWorker threads to perform those operation in order not to freeze the application. Also, those 3 three operations are exclusive: the interface logic must ensure that they are not performed concurrently (only one operation at a time). The toolbar also contains the following buttons that have an immediate effect over the report “Volumes” and “Agents” radio box: this radio box is used to select whether call counts or agents counts gets displayed in the report. Note: in Lokad Desktop Workload Forecasting, only call counts were displayed. Control shortcuts are expected for all the toolbar controls. State management: the states of those controls are NOT expected to be reflected in the model. Those settings are not persistent. The grid report The grid layout should be quite similar to the grid of Lokad Desktop Workload Forecasting (see screenshot at the beginning of this document). The call counts are NOT editable (neither past nor future). The past call counts get retrieved through the call logs adapter, and the future call counts get computed through Lokad. The planned (future) agent counts are editable. Indeed, the call center manager may be aware a “special” events that may affect the call center in the future. The past agent counts get retrieved through the call logs adapter (if supported), and the default values of the future agents counts get computed by L3C using the forecasts. If the past agents counts are not retrievable (not supported by the call logs adapter), then the “old” planned values get moved to “past” values when the user performs a “Retrieve” operation. Note: The Lokad team will implement the formula that computes the required number of agents based on the forecasted call counts plus miscellaneous data (service level, average call duration, expected time to answer …). The edited agent count value is likely to be different from the forecasted one, an edited cell must appear as “123 (456)” where the user value comes first and the default forecasted value is displayed between parenthesis. Color guidelines: by convention, past data appear over a yellow background and the future data over an orange background. The background colors for the columns are expected to be isolated in a clean manner in order to be easily customizable (by the Lokad developer, not by the end user). Day of the week: In addition to the dates (columns headers), the day of the week should be displayed in second-line column headers. Basically, the information “day of the week” is critical for the call center manager to visualize the report. L3C as a WinForm application The skeleton source code already contains a Windows application named Lokad.CallCenter.Windows. This application must wrap the view in same spirit than the “Lokad Desktop Sales Forecasting” application (see the screenshot at the beginning of this document). The application must have the following (classical) menus File o New (configuration wizard) o Open o Save o Save As o Exit Tools o Report settings o Error Logs Help o User guide o About Us The File menu The user should be able to open/save an CallCenterModel into a file (using the standard Windows dialogs). The XML Serializer should be used for persistence. No file open: if no file is open, then all non-accessible controls (menus and buttons) must be disabled. “File not saved” warning: if user tries to exit L3C although there are unsaved changes, a dialog must appear proposing to save the file. The “Configuration Wizard” will be described in its own section here below. The Tools menu The menu includes a dialog box that corresponds to the settings of the report. “Lokad Desktop Workload Forecasting” already implements a near identical settings panel. L3C must reproduce this part of those settings panel in its own settings dialog box (again, the source code of “Lokad Desktop Sales Forecasting” is available as a guide). Note that only the “Lokad Account” and “Business Applications” settings have to be considered, since the settings equivalent to the “Forecasting Task” have been migrated to the sidebar (see here above). The errors log is trapping the error that may happen with the retrieve / upload / download operations of L3C. L3C must implement an error log similar to the one of “Lokad Desktop Workload Forecasting”. See below for the screenshot. The purpose of the error log is just to provide a convenient way for the customers to cut and paste to the Lokad support team the error messages (when errors are encountered). Version checking: reproduce in L3C the version checking system of “Lokad Desktop Workload Forecasting” (very plain HTTP request to get the latest version number, again source code is available). Clear account: deletes all the time-series that start with the specified prefix in the Lokad account. Help menu “User guide” simply redirect the user to a web page (the URL being part of the app.config). “About Us” displays the typical AboutUs dialog (see “Lokad Desktop Workload Forecasting”). Configuration Wizard L3C is somewhat confusing for the end user because it plugs both into Lokad and into a 3rd party application. Thus, when first launched, L3C must display a configuration wizard that will help the user to initially setup the application (instead of directly having to deal with “report settings” panel). The wizard follows the following steps 1. Lokad connection settings: only the email/password are asked (and validated). If the user has no Lokad account, he can click a link to be redirect to http://app.lokad.com/CreateAccount.aspx to open an account. 2. Selecting the 3rd party application: the user gets the lists of 3rd party applications. The user must be suggested to send an email to email@example.com with the name of his application if he can’t find it in the list. 3. Business application settings: the user enters the connection strings. Again, if the user is in trouble, it must be very clear that he can contact firstname.lastname@example.org 4. The display settings with period type and number of periods (both for past and future). Note: add a check box “Do not show this wizard at start-up” at the bottom of the wizard.