White Paper

Sales Force Effectiveness

Pharma Companies’ Sales Reporting Efforts Often Fall Short. A look at why this occurs and how to avoid it in the future.

Published On

Introduction

Since the time of blockbuster drugs and mirrored sales teams a decade ago, pharmaceutical reps’ access to physicians continues to decline each year. Studies indicate that between 36.5% – 44% of physicians are now being designated as “no access.” Despite this declining access trend, the industry continues to allocate most of its total sales and marketing budgets to its sales forces, reaching estimates of $12 billion in 2016.

With so much at stake, the industry can ill afford to arm its sales force with inadequate sales reports. Yet, the reporting function continues to fall short of its objective to provide sales representatives and their managers with the tools needed to optimize script writing within designated geographies. Why is this the case?

In this white paper, we take a look at four compelling reasons why many sales reports are doomed to fail from the start, and what can be done to avoid these mistakes in the future.

1. Disparate Mindsets

2. Knowledge Gap

3. Slow and Inflexible Platforms

4. Overlooked End-user

1. Disparate Mindsets

All too often a company’s Sales Operations group turns to a development team, either internal or external, to build out its reporting needs. When the two parties come together, Sales Operations enters the equation as a business entity with a solid understanding of the nature of the sale, how to address customers, and knowing what’s needed in its tool box on a daily, weekly, monthly basis in order to produce desired results. The development team brings an approach of building applications based on specifications, Once requirements are finalized and
development has begun, it can be difficult to enact changes to the original specifications.

In most cases, the interaction between Sales Operations and
the development team might be limited. This is common practice when it comes to communication between business and technology. The Sales Operations team usually meets with the
development team to discuss requirements and report design,
but that may be the only interaction between the two groups
until an initial report is developed. This lack of contact occurs
because the development team begins its approach only when
requirements and the design of the reports have been finalized
by both parties and then it generally follows the waterfall approach to software development, going dark during development while working against the project timeline and agreed upon deliverables.

Due to these circumstances, the Sales Operations team loses the opportunity to review progress at designated checkpoints. Without seeing progress along the way, precious time can be lost in developing reports that do not deliver the information required and in the manner needed. (See below: The Waterfall Approach to Software Development.) Six to eight months can go by before anyone sees a report – which in many cases is too late to address any inadequacies and/or keep up with the change in business. If the report does not deliver what is needed, rework is required. This starts the process all over again, thus losing time, and even more importantly, losing productivity in the field. (See Case Study: The Lost Year)

The Waterfall Approach to Software Development

The waterfall approach is a standard management approach used during software development. The basic model consists of:

1. Defining and understanding the requirements

2. Designing a system that addresses these requirements

3. Integrating, testing, and delivering the system to the end-users

Although this approach does provide a logical way to build complex reporting solutions, and provides time up-front for requirements discovery, analysis and design, it often suffers due to its inability to accurately predict when the final product will be delivered. Late delivery is very common using this approach, as well as delivering solutions that do not fundamentally address the customer’s needs. (See Case Study: The Lost Year)

Understanding where this approach often fails is helpful in developing a strategy to avoid such failures in the future when working with software developers. Essentially:

Don’t assume you will have a well-defined set of requirements that are understood by developers – software is sometimes intangible to specifiers. You envision a solution you feel might work based on requirements. It’s very hard to see the final product.

Remember that it is difficult, if not next to impossible, to handle big changes during the development phase. Big changes will set back the timelines.

Trying to plan for issues encountered during system integration generally miss the mark.

Planning for the unknown by trying to estimate and allocate time for unknown issues during the development process also opens a black hole that can waylay the project unnecessarily.3

Rather than blindly follow a waterfall development approach, it is far better to move to an agile development approach incorporating regular communication between the developers and the customer. Here the development team would move to rapid delivery of the highest priority requirements, roll out a basic solution, followed by rapid feedback and rapid evolution – working until the result is just right. In such a development process, the development team is better able to deliver a solution that truly meets Sales Operations’ end goals.

2. Knowledge Gap

Although Sales Operations initiates and drives the need for
the reporting function, it rarely has the time to oversee the
work being done by the development team. This creates a
disconnection between “what is needed” and “what is being
built.” Development teams typically lack an in-depth
understanding of the business and the end-user, thus putting
them at a distinct disadvantage when it comes to incorporating
the needs of those using the reports. Th is division, both in
mindset and practice, needs to change in order to determine
what solution will best satisfy that business need. Reports should
be built based on how they will be used – a seemingly obvious
requirement that is much more difficult than it sounds. Th is
requires looking through the lens of the sales rep, something
often forgotten in the development cycle. Setting up interdisciplinary team meetings at the outset, incorporating input from the field, can go a long way in resolving this disconnect.

On the business side, there are also limitations as far as understanding the technology used to build out the reporting solution. When there’s a lack of this high-level knowledge, it creates a gap between the Sales Operations group and the development team. This can cause unnecessary conflict and tension, especially when the business side doesn’t fully understand why the development is taking too long or if certain needs can’t be met with the current solution. Assigning an IT business liaison role during the implementation of the project is a sure way to help bridge the gap and strengthen the connection between business and technology.

CASE STUDY

The Lost Year

A pharmaceutical company invested $1.5 million and a full year of working with an external vendor to develop and deliver a sales reporting solution based on agreed upon requirements. The development team chose to work with an industry-leading enterprise software as its platform. As a result, Sales Operations found that changes were always a struggle, timelines were too far out, and the development team was unable to keep up with the rapid change of business and user needs. To further complicate the situation, the platform was extremely slow. The sales report usage was significantly down as a result based on the speed issue and the reps’ ability to prepare properly for their sales calls was significantly decreased. Several times when they tried to access data the whole system would crash, negating their ability to detail. Representing a managed care situation, they needed to address how many managed care preferred scripts they could switch away from the competition. Not having quick access to this information, they were unable to capitalize on opportunities within their territory and sales were needlessly lost.

3. Slow and Inflexible Platforms

Report developers tend to gravitate toward cutting-edge, gadgetry-rich solutions that abound in today’s offerings of software solutions. Unfortunately, this penchant leads to less than adequate results. Until notebooks and iPads took the market by storm due to their ability to more quickly and meaningfully engage the physician with informational apps during a detail, sales representatives and their managers were content using Excel spreadsheets to view and manipulate their data. Replacing that versatility and flexibility with a reporting platform that delivers timely data in a meaningful way is a major challenge with today’s technology as most apps don’t give reps the ability to work with the data in the same way Excel did and browser-based solutions are not always accessible.

The key here is to understand the end-user. Rather than figuring
out what platform might work best for the sales department –
how individuals will consume and use the reports – many
development teams start by licensing an existing enterprise
solution and leveraging it to deliver the reporting platform. Such
an approach generally results in nearly insurmountable learning
curves and unduly long development cycles. These systems
typically lack overall performance speed when it comes to
querying large amounts of data. Rather than pressure testing
optimal click response before selecting a platform, developers
work with systems that might take one to two minutes per click,
or in some instances, actually crash the system. When these
findings are discovered late in the development cycle, it’s
virtually impossible to change direction.

 

Not surprisingly, change management is extremely difficult when leveraging enterprise systems. Keeping up with the changes occurring in a dynamic selling environment and/or including additional data sources only serve to further delay development cycles. Since the overall report design is typically not set up to handle changes in an efficient, time-sensitive manner, the end result is an increase in ad-hoc reports to meet demand rather than producing only the standard reports that should be created. For example, it’s not atypical for a sales rep to have 21 ad-hoc reports to synthesize in a 20-day work month. Such inefficiencies and overall lack of integration only make the sales rep’s job that much harder and lead to less than optimal production.

Sales reports can require a high degree of customization, which enterprise “off-the-shelf” solutions cannot easily accommodate. (See below: How Pharmaceutical Reps Use Their Sales Reports.) They simply are not designed to tailor to specific conditions. Ultimately, each company looks at its goals and reports in a manner unique to the organization, and their reports should reflect this perspective. Development teams will face these situations when trying to implement several reporting platforms across different sales organizations. Based on their specific market, data sources, and sales objectives, each one of the reporting solutions could look very different. There isn’t
a “one size fits all” approach when it comes to a successful reporting system.

How Pharmaceutical Sales Teams Use Their Sales Reports

Without good sales reporting to do pre-call planning, sales teams are “walking in blindly” to meet their targeted customers (physician).

Quarterly Business Planning

• Preferred vs. Non-Preferred Plans – HCPs with high preferred volume


• List of Decliners


• Managed Care Top Plans


• Medical Groups


• High Market Volume & Low Client Share


• Create and Track Initiatives Over Time

Monthly

• Review Managed Care Situation (Pull through analysis)

Weekly

• Geographic Trends

• HCP Lists Created to Track Progress

• New Writers / Decliners / Growers

Daily

• Pre-call Planning – based on HCP profile and weekly performance

4. Overlooked End-user

Despite the aforementioned development issues, sales reporting platforms do see the light of day. However, mostof them have inherent issues delivering pain points across the sales organization. (See Case Study: A Platform Solution Gone Awry.)

After going live, reporting platforms typically fall short in addressing the following needs of a customer:

Data Integrity

Business rules need to be kept consistent to eliminate any questions on overall data integrity.

Timely updates

Data updates need to be delivered in a timely manner.

Simple interface

Too often developers overcomplicate the design and functionality of the tool. The tool needs to be kept simple and be tailored to meet the needs of the sales team.

Customization

Reps and their management need a sense of ownership and empowerment relative to the reports and should be able to customize views and save as preferences 

Compatibility

Platforms developed today are app-based, browser-based, or both.

Consistency

Sales reporting needs one uniform approach that encompasses all levels within the organization: Rep,
District Manager, Regional Manager, and Sales VP.

Planning

Sales reports should be replete with data that allows for insights that identify opportunities and threats, i.e. built to assist with business planning, monthly analysis, and weekly/daily use.

Collaboration

Today’s sales teams share ideas across teams to improve their overall effectiveness. To support this, platforms should be flexible and allow collaboration across colleagues.

Extended device platforms

Sales Reps now use tablets or iPads in the field. This was an expensive technology adoption aimed at improving visual presentations to the physician. However, these devices limit the rep’s ability to manipulate data. Historically, sales reporting was done in Excel, which provided more flexibility for sales reps to do
what they wanted with the data – extract, manipulate, summarize, etc. The device restriction limits that ability
unless the Excel app is made available, allowing data to be manipulated and stored in the cloud, or if the reporting app structure allows such functionality. 

In order to be successful, development teams must keep the primary focus around the end-user and their needs. Once the reporting platform goes live, users are typically quick to judge the solution, and that’s the perfect time to capture user feedback. It’s extremely important to conduct several rounds of feedback sessions after the live date, as this provides a very good barometer to test whether the end-users’ needs were successfully met.

CASE STUDY

A Platform Solution Gone Awry

A Sales Rep for a major Pharmaceutical company reported on the new sales reporting solution based on a major Business Information Enterprise platform. Without hesitation, he expressed how much he hated the platform. His reasoning was based on its lack of consideration for how he used the reports. He found the platform cumbersome in that there were too many steps needed to navigate to a single data point (e.g., to see the call activity for targets). Data wasn’t tailored to his area, and he needed to filter a complete list of
geographies to find his territory, which would then slow down the tool. The prior platform used for sales reports was working well, but now the rep had to deal with a slow, cumbersome tool that was adversely impacting his productivity throughout the day. The decision by the company to move to a different reporting platform without consulting the end-user resulted in him being demotivated and ill prepared
for sales calls – certainly not the intent of the switch.

In conclusion

Today’s leaner pharmaceutical sales force is faced with many obstacles. With physician access continuing to decrease, reps simply cannot afford to be unprepared for their sales calls, nor can their employers risk the loss in potential script revenue. Having the proper sales reporting tools to effectively plan and use for physician data is paramount to success in the field. Sales organizations need to rethink their approach and seek report development partners who are able to sharply see through the lens of the end-user in order to then build a platform that offers the most flexibility required and delivers data within the performance parameters needed to be successful in the field.

Want to learn more?

KMK Consulting has the expertise and custom tools to work with you to develop reports within platforms that drive success

Contact our expert SFE team today to break down the barrier between data and insights.

Get The Latest Updates

Subscribe To Our Monthly Newsletter

No spam, only the content you’ll want to read.

Details about how we process your Information is available in our 

Privacy Policy

Watch our latest webinar

Strategic Planning for Medical Affairs

Featured Speakers