Home » Drawing a Roadmap for Better Contact Center Reporting and Analysis

Drawing a Roadmap for Better Contact Center Reporting and Analysis

Submitted by ChrisR on November 24, 2011 - 2:05pm

Abstract: As the contact center landscape changes, so too must the reporting and analysis solutions that drive decision-making and performance management. But the roadmap to better reporting and analysis isn't in every contact center's glove compartment; each will need a different roadmap to their destination. Contact center leaders are often at a loss on how to start down the road to better contact center reporting and analysis. Luckily, this landscape is well-traveled and has two main routes — both of which are better than standing still and waiting to get run over. Which road a company chooses is usually determined by the impetus or motivation for change, as well as the culture of the organization and the needs of its stakeholders.

Contents

 
 

Introduction: All Roads Lead To...?

As the contact center landscape changes, so too must the reporting and analysis solutions that drive decision-making and performance management. But the roadmap to better reporting and analysis isn't in every contact center's glove compartment. Because each contact center is a unique mixture of systems, applications, people and culture serving a specific customer or client segment, each will need a different roadmap to their destination. 
 
There are four common reasons that contact centers are driven to undertake this journey in the first place:
 
Current reports don't meet requirements: Typically, most contact centers begin with the standard reports included in their operational systems — automatic call distribution (ACD), interactive voice response (IVR), workforce management (WFM), and so forth. However, these out-of-the-box reports usually only cover the basics and likely don't reflect a given organization's unique measurement needs based on industries and markets served, customer needs, or geographical/cultural differences. Moreover, each of these operational systems is essentially a silo of data; an ACD's standard reports are designed to show how the contact center is performing only from the ACD's point of view, without reference to, say, how agent scheduling (managed in a WFM system) will affect ACD metrics. To determine the latter, at least two reports must be generated, and data from each laboriously merged manually in a spreadsheet, a time-intensive process that also fraught with opportunities for error.
 
Data quality and integrity suffers: As errors proliferate in these “patch-quilt” spreadsheet reports (often called “spreadmarts”), contact centers begin to lose trust in their stats. Data integrity can also erode as underlying business rules change, or as call flow/call handling protocols are reconfigured, resulting in changes to how calls are pegged in the ACD. A common result is “dueling spreadsheets” – reports ostensibly covering the same metrics, but with different data values suggesting different conclusions. 
 
Changes to operational systems: A replacement, upgrade or reconfiguration of any component of the contact center environment might change the way underlying operational data is logged, with ripple effects on all dependent reports. Adding new technologies (for social media tracking, say) introduce new silos generating new data that must be incorporated into performance reports.
 
Disconnects arise between strategic goals and contact center operations: Changes in management or organizational direction will likely necessitate significant and sometimes immediate changes in the contact center, and thus its reporting requirements. If these changes aren't made quickly, fundamental disconnects can create constant, unproductive internal struggles between the contact center and upper management. These clashes can occur over anything from a perceived lack of progress to claims of conflicting goals and inconsistent direction. 
 
When faced with one or more of these challenges, contact center leaders are often at a loss on how to start down the road to better contact center reporting and analysis. Luckily, this landscape is well-traveled and has two main routes — both of which are better than standing still and waiting to get run over. 
 
Which road a company chooses is usually determined by the impetus or motivation for change, as well as the culture of the organization and the needs of its stakeholders. Whichever route you choose, we'll look at some key guiding principles – sign posts, as it were – to keep you on the right track. And we'll outline some useful processes for how to go about designing a reporting and analysis solution. 
 

Route 1: Taking The Road You Already Know

When it comes to reviewing your contact center's reporting and analysis strategy, you might think making a fresh start is the obvious — and only — route to take. But that's not necessarily the right strategy for every organization. Sometimes key stakeholders are reluctant to begin — even in a modest way — a process that could eventually lead to sweeping changes down the line. 
 
Sometimes this resistance comes from IT personnel or analysts who have spent many days, weeks and months of the organization's time creating and maintaining complex, macro-heavy spreadsheet reports for the contact center. The status quo is the devil they know, and they have a hard time turning their backs on the sunk cost of these reports (the time and wages spent making them). They often argue that the incremental cost of making piece-meal adjustments to these reports will be less than a wholesale replacement; while this may be true in the (very) short run, it ignores the much bigger savings from automating current labor-intensive reporting practices.
 
Sometimes the resistance to change comes from contact center managers and supervisors, who may feel they have enough technology to deal with already. Under constant pressure to meet daily, weekly and monthly performance goals, these managers are understandably reluctant to focus on initiatives that may require them to evaluate and implement new technologies, even if these promise to make their lives easier in the long run.
 
Finally, some resistance may be found in the executive suite itself. Many organizations see contact centers (particularly customer service ones) as a necessary cost of doing business, but a cost nevertheless. Costs must be minimized, and senior managers may fear that adding new technologies will squeeze already tight budgets.
 
Understandable as all these viewpoints may be, the fact remains that as time goes on and the contact center expands, piece-meal manual reporting becomes ever more costly and error-prone. The implicit cost of getting good data will ultimately break budgets, and bad data will confound  efforts at better contact center performance.
 
A Fast Start in a Shorter Race
The good news for all these stakeholders is that a new roadmap to better reporting and analysis can begin with the old roadmap rather than a clean, blank sheet. In this approach, your current spreadsheet-based reports are re-purposed, not tossed away. Whatever their drawbacks, spreadsheet reports have the virtue of being a very accurate reflection of your contact center's current reporting needs. As such, they make excellent blueprints to guide the next evolutionary step in the process — eliminating manual effort through automation of data collection and consolidation.
 
Under this gradual, “start small” approach, the only major decision is choosing the proper enabling technologies to completely eliminate the need for a human to cut and paste data into these reports. In fact, limiting the scope of an initial project to this simple goal alone has two advantages: It's clearly understood by all stakeholders, and the resulting benefit in saved time and money is easily quantifiable. And with the right technology, these “quick wins” can be achieved easily while providing the foundation for even bigger gains from a more comprehensive review.
 
Another benefit of this road-already-taken approach is that it gives analysts and managers breathing space to re-examine and refine metrics and calculations used in existing reports, evaluate whether these need to be adjusted, and to fine-tune report formatting. With new technology eliminating human error from the data consolidation process, managers can even “go back in time” by looking at previous reporting periods with fresh, accurate data to revise any assumptions or conclusions that may have been made based on erroneous information.
 
And even if you're an outside-the-box thinker stuck in a slow-and-steady-wins-the-race organization, rest assured that this seemingly tactical start to the race will likely lead to a strong strategic finish. With the right technologies powering their current reports, analysts and managers will inevitably discover the richness and variety of new information available in the contact center's underlying operational systems. Reluctant stakeholders will realize that all the tools they need for broader and deeper reporting and analysis are already at hand; all that's needed is the determination to take the next step — a formal review.
 

Route 2: Start Out with Your Destination in Mind

Some contact centers don't have the luxury of time to take the slow, scenic route. Typically, some kind of crisis point is reached when a spanner gets thrown into the works: a key operational system is added, replaced or upgraded, or a second agent site is added, or perhaps a corporate merger leads to a shotgun wedding between two completely different call center architectures. Or the fuel for change may come from senior management's decision to increase productivity or cut costs; the more closely a contact center actively manages its performance, the more crucial accurate reporting and analysis becomes. 
 
Whatever the reason, these organizations need a roadmap that will carry their contact centers to a fixed, defined destination. Unlike Route 1, this route implies more up-front planning and a structured, top-down process that begins with key goals that drive every subsequent leg in the journey. 
 
In general, there are five phases — pit-stops, if you will — in a complete review of contact center reporting and analysis. First, the scope of the project itself must be clearly established. Second, requirements must be gathered and defined. Third comes the design process, which will likely have several iterations. Fourth comes the crucial technology selection, followed by the fifth and final phase — implementation and review.
 

Pit-Stop 1: Define the Project Scope

In order to have any chance of crossing the finish line, a formal project needs scope, big or small. A project can be defined as narrowly as “merge average-speed-of answer stats from these three different ACD systems into a line-graph report” and as broadly as “build agent, team, and company-wide scorecards on seven key performance indicators, to be refreshed hourly in an at-a-glance dashboard.” 
 
Project scope also implies a timeline for completion; open-ended projects tend to eventually sputter to a standstill due to lack of fuel. Key stakeholders in the process (agents, supervisors, IT staff, executives and, in some cases, customers or partners) need to be identified at this stage as well. Budget may also be allocated at this point, or this may come later, when enabling technologies are evaluated. 
 
Champions and Navigators
To be successful, such a project should be driven by a data-savvy champion — someone who knows the value of data integrity and believes that technology can be applied successfully to the challenge of automated reporting and analysis in a complex contact center ecology. Often, this champion is a senior executive in operations or IT who can make the business case, secure the funding, and appoint the right people to manage and execute the project. 
 
Note that the role of champion is different from the role of hands-on project manager. If the champion is the driver in a rally-car race — keeping his/her foot on the gas and the car pointed in the right direction (and upright!) — then the project manager is the navigator who reads off the detailed “pace notes” that ultimately keep the car on track and in the race. 
 
Similarly, a project manager tracks tasks and deliverables along a fixed timeline, and keeps all stakeholders focused on the ultimate outcome. Those stakeholders will include people actively involved in the contact center (agents, supervisors, and analysts) and those indirectly involved, such as system administrators, database developers and other IT specialists. All have a mixture of priorities and motivations, and without a project manager keeping an eye on alignment, a review of even modest scope can drift into the ditch.
 
Besides the champion and the project manager, there is another crucial role to be filled in a review of contact center reporting — that of data interpreter. Some key stakeholders (agents and their supervisors particularly) will define key reporting metrics in business terms; others (contact center systems and database admins) will define these metrics from a “data” viewpoint. There is often a gap between these two definitions that goes undetected as each assumes the other shares the same assumptions. This “disconnect” may persist through the design, development and implementation stages and ultimately lead to frustrating and time-consuming review and re-work. 
 
The data interpreter — usually an IT resource who understands the operational systems and their underlying databases — can help the project avoid this axle-snapping pothole by translating the required key performance indicators into data definitions that can in turn be embedded in the ultimate reporting solution.
 

Pit-Stop 2: Gather and Define Requirements from Stakeholders

By definition, a review of contact center reporting and analysis is a reassessment of key stakeholders' requirements. It's also a great opportunity to make sure the contact center is conforming to the goals of the organization as a whole. The most powerful way to accomplish this is to derive the contact center’s top-level requirements from strategic targets and goals set by the organization's leaders. 
 
An hour spent with the vice-president of sales and marketing or the chief financial officer — or the CEO — can go a long way towards defining what needs to be measured. This may sound daunting, but you can count on most broad strategic goals boiling down to specific, measurable actions in the contact center. For instance, if a financial institution’s strategic goal is to move into a new market category (say, home insurance), then measuring and improving cross-selling by customer service agents handling mortgage inquiries will serve that strategic goal. Similarly, if an online retailer of computers wants to win market share from competitors based on better post-sale customer service and technical support, then metrics measuring customer satisfaction will directly impact that strategic goal.
 
Of course, many of these strategic goals lie partly or completely outside the contact center's control, so stakeholders in other functional areas of the organization — marketing, product development, finance, human resources and other back-office departments — should be consulted on what feedback they need from the contact center to refine their own plans and programs.
 
 
Finally, there are the contact center's own, internal operational goals. Some contact centers want their agents to be more productive, so reporting will have to gather and consolidate accurate data on call handle time, talk time, or after-call work time. Some want to be more effective in the interactions agents have with customers, so first-call resolution or customer satisfaction ratings will be key metrics. Most will want to gauge how all the moving parts of the contact center — agents, management, and technology — are working together, so service level, average in queue and/or on hold times, average speed-of-answer, and abandons will be critical.
 
Validation: Say it out loud
When gathering requirements from stakeholders, it's important not to shackle their choices to lists of known, “standard” metrics or reports. Rather, ask each stakeholder group to compile a prioritized list of information, expressed in business terms, which they would like to see from the contact center. Not all of these “wish-list” items will be achievable, but the lists themselves will help clarify each stakeholder's needs, and suggest new metrics or measurements that may be possible with new reporting technologies. Such user-driven consultation also helps with stakeholder buy-in.
 
Asking for requirements to be expressed out loud in business terms — or just plain old English — is useful in another way. Compare these two questions:
 
  1. "Can I get a daily report that shows Not Ready Time, Talk Time, Idle Time, and Break Time?" 
  2. "How are my agents splitting their time among the various activities that they do within their shifts – whether it’s assigned work or not?" 
 
The first question is all-too-easily “answered” with a canned report showing each of these metrics in hours, minutes and seconds, which then have to be compared (usually manually) to shift times (usually from another report) if they are to be of any use. 
 
Conversely, the second question, expressed in plain English, could easily be answered by a single, more meaningful report with trended data shown as proportions (say, 60% inbound, 20% breaks, 10% training, 10% unaccounted for) which a supervisor or coach could understand at a glance, no assembly required.
 
Put Current Reports in the Hot Seat
A comprehensive review also provides the opportunity to test existing reports' relevance to the contact center and its stakeholders. Some reports may have outlived their usefulness. Ask each current report some skill-testing questions:
  • To whom does this report matter? Do those stakeholders agree it matters? Do they understand it?
  • What actions do we take based on this report? How does it help meet our goals? What would happen if we didn’t get it?
  • Do we need to manually match this report with another report to answer the questions we're asking?
  • Is the information in the report formatted in a way that promotes understanding and action, or is it just showing some numbers? Would graphs or charts help?
  • Are we getting this report often enough? Too often?
  • Are we seeing cumulative data (quarterly, calendar/fiscal YTD) expressed in terms that are useful to our particular needs?
  • Do I have to run this same report multiple times for different contact center sites?
  • How are we getting this report (e-mail, web, a photocopy left on office chairs every night)? Is there a better distribution method?
  • What other ways can this report be improved?
These questions can be asked not only of existing reports, but also the measurements they contain:  metrics, formulas, custom calculations, and even system calculations should be validated in this way to make sure all stakeholders agree. Though the verbal definition of service level — x percent of calls answered in y seconds — will be familiar to all concerned, its underlying formula has a half-dozen or more known variations. While it's not necessary that every stakeholder understand how it's calculated, it is important that a single formula be applied universally. 
 
Eliminate, Don't Duplicate
Look for ways for many reports to be consolidated into fewer – or just one. If users must flip through multiple reports summarizing the same data (by skill set, queue or application, or by time or geography), make the elimination of this needless duplication a key requirement of the review. The right reporting solution will provide ways to interact with a report to show (or hide) this data as needed, and to navigate through standard hierarchies of data (year/month/week/day) within the same report. It will also allow your contact center's unique hierarchies (site/team/agent, or custom geographies) to be represented as well.
 
The requirements list should also include any custom or unique calculations users or analysts may be performing by hand or in spreadsheets. Every contact center serves a unique customer segment, market, industry and/or geography, and “standard” lists of metrics can never capture everything a given organization needs to measure. A new reporting solution should automate these custom formulas, and apply any constants (call cost data, loaded labor rates, occupancy or service level targets, or other performance objectives) needed in their calculation or presentation.
 
Don't Let the Silos Rule the Farm
Don't be blinkered by the old limits on reporting imposed by operational data silos. If supervisors or coaches need an agent scorecard combining data from ACD, screen capture, quality management, and workforce optimization systems, then add a mock-up report to the requirements. It's the reporting solution's job to tap into the relevant data silos as needed and present that scorecard as though it came from a single, all-knowing system. Similarly, if analysts have struggled in the past to build cradle-to-grave call audits from raw ACD and/or IVR data, then this should be a determining requirement for a new reporting technology. 
 

Pit-Stop 3: Design

With complete requirements and stakeholder buy-in, it's time to begin designing actual reports. Again, spreadsheets are a useful tool to create mock-up reports; most stakeholders have Excel on their desktop and can view and make at least cosmetic changes to mock-ups. These should circulate to a design team with at least one representative from each stakeholder group, and a report should only move to the implementation phase when all affected stakeholder reps have signed off on it.
 
Each contact center's report mock-ups will be different, but here are some key guidelines that should pertain to all templates passed to the design phase:
 
Document sources:  Beyond layout and formatting, these mock-up reports should include notes about which operational data systems each metric should be drawn from — ACD, IVR, WFM, CRM, etc — and which custom formulas or calculations need apply in their presentation in the report itself. Cumulative metrics should also be highlighted along with any special rules governing them (fiscal YTD, etc.).
 
Note calculations from source systems: Remember, many of the metrics pulled from operational systems like the ACD are actually calculations, with formulas underlying them. If a new metric is created from the combination of two or more calculated statistics, the operational source of each constituent metric should be noted along with their respective formulas or calculations. This is particularly important in mixed-vendor environments, where a “standard” metric like service level may be calculated differently by different systems.
 
Check your frequency: Note stakeholders' required frequency of each report refresh (intraday, daily, weekly, monthly, quarterly), and whether previous editions of each report should be maintained separately (not overwritten when updated) and kept accessible for future reference. Your reporting solution should give you the option of filtering report data based on date, making a historical archive of past reports redundant.
 
Determine distribution and scheduling: Each report mock-up should note who will be receiving or accessing the report, and through which distribution channel. Some users may simply need an e-mail with a .PDF or spreadsheet attachment; others may need to log onto the web for more interaction with report data. Avoid sending reports to stakeholders who don't need them.
 
Keep it simple: Don't try to include too many measures in a single, all-encompassing report. Reports should support a single management action or decision, or a group of related decisions. For instance, scorecards used to coach individual agents should include metrics that are under the agent's control (not-ready time, average talk time, attendance, etc.) and relevant independent variables like calls per hour, but not top-line measures like calls offered, agent utilization, or abandon rates.
 
Avoid dueling metrics: Some contact center measures clash with others, pulling managers in two or more different directions. If managers decide that first-call resolution is a customer service priority, then setting low targets for average talk times will actually hinder agent and team performance. Arbitrary call-time targets will also hamper sales-oriented centers that reward higher revenue-per-call or conversion rate (the percentage of inbound or outbound calls converted to a sale). Avoid this conflict by keeping reports relevant to one actionable decision or group of related decisions.
 

Pit-Stop 4: Select Your Reporting & Analysis Architecture

The first three phases of a comprehensive review of contact center reporting and analysis can — and perhaps should — be completed before meeting with vendors to select enabling technologies. If a vendor is introduced into the review process too early, their technical limitations may become “baked” into report requirements and design, and the whole project may ultimately fall short of its promise.
 
There are three solution categories that have evolved to meet the challenge of better reporting and analysis in the contact center:
 
Report extension (sometimes called point-to-point) tools are offered by many of the same vendors who manufacture the contact center's operational hardware and software. These systems almost always feature built-in “canned” (standard) reports for a given system like the ACD, and report authoring tools that analysts can use to create their own reports. In skilled hands, these tools can import data from other, unrelated systems. Similarly, vendors of real-time dashboard, workforce optimization and quality management software offer reporting tools that may be used to access other operational sources.
 
Performance management suites usually offer reporting services as part of a much wider array of applications, including workflow management, coaching, contact type profiling, agent recognition and compensation. 
 
Business Intelligence (BI) is a software architecture designed specifically for reporting and analysis of information from operational data systems of any kind — point-of-sale, manufacturing, banking and finance, sales and marketing, or any other computerized system with an underlying database logging transactional data. 
 
All three of these are viable approaches to better reporting and analysis in the contact center. However, BI has some distinct advantages that make it the best architecture not only for a contact center’s present reporting and analysis needs, but future requirements yet to be discerned.
 
The first advantage is BI's depth and breadth. Treating reporting and analysis as a mere “add-on” feature for operational systems greatly undervalues its central role in contact center management. The canned reports and limited analysis services included in point-to-point systems are often the focus of managers’ and analysts’ frustrations that lead to a review in the first place. Because it concerns itself exclusively with the task of reporting and analysis, the BI architecture can offer a much deeper and broader functionality set – ad hoc queries, multidimensional data analysis, and statistical analysis. 
 
The second advantage is BI's system neutrality. Unlike point-to-point reporting extensions of existing systems, the BI architecture isn’t tied to a particular contact center technology such as the ACD. It can “roll” with wholesale changes in infrastructure brought on by, say, new signaling technologies like the Session Initiation Protocol (SIP). Whatever operational systems will dominate the contact center a decade from now, a BI solution will be able to connect to them and optimize their data for analysis.
 
The third and most important advantage is BI's customizability. The one-size-fits-all performance management suites have one major disadvantage compared to BI — they are monolithic and inflexible. Contact center managers are expected to adapt to a particular suite’s approach to optimal performance lock, stock and barrel; the “standard” reports, scorecards and dashboards are thus considered all that is needed to support the paradigm. However, no single approach to performance management can encapsulate every particular challenge or opportunity faced by every contact center in every industry and market. 
 
Conversely, the BI architecture is designed to be customized to measure exactly what an individual contact center needs measured based on its unique requirements. A BI solution can offer libraries of common reports and key metrics, while also offering the ability to adapt these to specific requirements, and change them over time.
 
Business Intelligence Architecture
 
Harmony from Disharmony: How BI Works
The main strength of the BI architecture is its separation of operational and analytical tasks. Operational systems are left to their job of logging transactions, and a separate BI architecture focuses exclusively on reporting and analysis. Typically, a BI architecture is made up of four layers:
 
Operational: These include the databases contained within the transactional systems to be analyzed. In the contact center, these include the ACD, IVR, CRM, WFM and other systems and applications that underlie all operations.
 
Access & Staging: This layer includes services that extract, transform and load data from the operational systems and applications to prepare it for storage. It’s in this layer that apples-and-oranges issues between metrics are resolved to create a “single version of the truth” for reporting and analysis.
 
Data warehouse/data mart: This is a separate, permanent database structured specifically for the task of reporting and analysis. Whereas the operational systems log relatively simple sets of data (like time stamps, DNIS, etc), the data warehouse contains more complex, calculated dimensions and metrics such as service level, speed of answer, time in queue, and average work time.  In other words, where the operational systems hold raw data, the data warehouse holds contact center management information. The data warehouse can also store months, even years of data for long-term historical trend analysis, while operational systems typically keep only a few weeks’ worth of data.
 
Presentation & management: Here is where end users — managers, supervisors, analysts and agents — access, interact with and share information in a variety of forms, from scorecards for each individual agent to graphical dashboards showing how the contact center is doing as a whole. This layer also handles security, storage, scheduling and distribution of content through e-mail, the web, and mobile technologies. Because this presentation layer is separate from the logical layer of the data mart, it can easily change over time (changing reports, adding new scorecards, tweaking dashboards, adding new distribution channels like smart phones) without affecting the integrity of underlying analytical data.
 
Although the BI architecture is ultimately capable of encompassing all reporting and analysis from very complex, multi-source environments, it's important to remember that it's equally possible to start small — even with a single report from a single data source like the ACD. A BI architecture is the right choice even if you forgo a comprehensive review and simply head down Route 1 to replace existing spreadsheet reports. 
 

Pit-Stop 5: Implementation & Review

The checkered flag does not wave when you've selected a reporting architecture and a vendor. Even if your vendor takes full responsibility for installing and configuring all the required software as well as developing all content based on your mocked-up reports, there is still a testing and review process necessary to drive the project the last crucial mile.
 
Testing and review is typically an iterative process; early “alpha” versions of each report will be generated with sample data and distributed to internal analysts for data validation, then recirculated back to report designers for corrections in calculations or formulas. After a few more iterations to get the numbers right, designers move on to report formatting tasks like adding charts and graphs, improving the look of tables, and generally improving the user experience. 
 
Once reports have achieved a certain polish, it's time to expand the testing and review process to include end-users. Involving these stakeholders too soon in testing can be a mistake; non-technical users don't add much value to early data validation, and it can be difficult for them to shake a bad first impression made by a report containing ratty or nonsensical data. Solicit user feedback when what remains to be tested is the day-to-day utility of reports — how they look, how their interactive features work, how they print out, and most importantly how useful they are.
 
If your software vendor is tasked with report design, don't let their enthusiasm for fancy new technology run away with your project. Just because they can show sixteen different metrics represented as speedometers in a dashboard with a 15-minute refresh, doesn't mean they should — unless your requirements process identified that need. The same rule applies to internal “power” users with advanced skill sets who may be understandably excited about what their new tools can do. There will be time enough for groundbreaking innovation once the first wave of reports meet documented requirements.
 
Usually, it takes a few testing and review iterations with the whole stakeholder audience before reports are ready for implementation and day-to-day use. As with report mock-ups in the design phase, representatives of each stakeholder group should (literally) sign off on each report before it is put into production. And once reports “go live” in the wider contact center, all concerned should expect one or two hiccups as final configuration issues are worked out. User reps from each stakeholder group should document any errors or unpredictable behavior they experience in using the new reports.
 

Journey's End (and Why There Really Isn't one)

Whether your contact center heads down Route 1 (the known road) or Route 2 (the longer but ultimately higher road), you'll know when you've crossed the finish line: it will be when you're getting the reports you need, filled with accurate data that's useful to you, in a timely fashion without you having to get out and push the car. At the very least, your roadmap to better reporting and analysis should have led to a new destination where you are free to spend more of your time and effort on improving your contact center's performance, rather that chasing bits of data down dead ends.
 
But you'll also notice that the road stretches past this first finish line, and that your roadmap features the faint pencil-traces of finish lines yet to come. That's because the contact center itself has an ever-expanding horizon; with emerging channels like social media, new switching technologies like SIP, and new innovations in performance management techniques, there's no telling what the contact center landscape will look like in five years. 
 
So the roadmap you've drawn will have to change as this landscape changes. Ultimately, it's the skills learned by drawing that roadmap that matter — defining project scope, identifying stakeholders, gathering requirements and creating mock-up reports that express them, choosing a reporting architecture that can meet reporting needs now and in the future, reviewing, testing, and finally implementing a solution. 
 
If you do it right, then all stakeholders will not only trust the reporting data they use, but will also trust the process that allowed them to get it, like a comfortable vehicle that reliably carries you from where you are to where you want to go. So when the time inevitably comes when the roadmap must be extended into new, uncharted territory, everyone can gather round and draw their bit.