Docstoc

To be delivered

Document Sample
To be delivered Powered By Docstoc
					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 support@lokad.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 support@lokad.com
    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.

				
DOCUMENT INFO