What does Open Access mean for marketing?

Subscription data normally sits at the heart of a publisher’s view of the customer, because it’s crucial to know who has paid for what. But, the same rules don’t apply to Open Access (OA) journals, whereby content is made available for free and a publisher’s revenue stream comes instead from an ‘author pays’ model. Let’s take a look at the various ways an OA model might change your marketing activities:

1. The Author is King. In a model where authors pay you for your peer review, content production and distribution services, accurate author data displaces subscription information as the most critical information source. You might already be analysing data from your manuscript tracking system, but does it include details relating to each author’s submission history and publishing outcomes, author interests, and also editor activity? You’ll want to ensure that every drop of author information is available to your staff for searching, segmentation and analysis.

2. Follow the Money. Who is paying you to publish OA content? It might be the authors themselves, or more likely their research funders. These could be academic institutions or other organisations already known to you as paying subscribers, but it’s possible there could be gaps in your knowledge here and further research to capture the details of all potential funders might be necessary. Of course, wherever possible, you will also need to know the connections too, ie. which authors are related to which funders?

3. Who’s Who? With author and funder records taking centre stage, the need for standard names and common identifiers becomes critical. An author’s name is a poor basis for identification because there are so many different authors who share the same name. The ORCID initiative which is aiming to solve the author/contributor name ambiguity problem in scholarly communications, is very relevant here, and it’s likely that this ID will soon become a must-have field in every author or manuscript database.

4. Article Usage. Usage is another data source that you may already be including in your single view, but your statistics are probably only at the journal level and integrated from an institutional perspective. Clearly, high institutional usage remains important to satisfying existing authors, attracting new authors and enhancing your brand overall, but you will now need to provide authors with statistics on the performance of their individual articles. The PLoS article-level metrics are interesting food for thought here. Your single view should therefore be capable of segmenting on usage at the article level too. In this context, the PIRUS projects and a new COUNTER standard for journal article usage are also very relevant.

5. Data Mining. You will want to include and explore any data source that might lead you to new authors, as ‘prospecting for new authors’ replaces ‘prospecting for new subscribers’ as a key sales and marketing priority. This might draw on data sources already at hand (eg. alert recipients, society member records) but it could also be sources not yet on your radar, such as conference proceedings or third party resources listing authors and their past papers or interests.

In summary: it’s clear that OA publishing can turn a lot of current journal marketing practice on its head. Any publisher involved in OA publishing should therefore give careful consideration to all of the issues highlighted here, and consider taking steps to ensure that all the relevant data is being captured and made available for author-based analysis.

Seasonal thoughts about… turnaways

I know the subject of ‘turnaways’ doesn’t sound very festive, but there is a tenuous link: Mary and Joseph became very early turnaway statistics themselves when they were told there was “no room at the inn”.

The definition of a “turnaway” is as simple as that: wanting to gain access, but being turned away at the door. In terms of online content, whenever a user tries to access an article but hits the paywall and fails to get there – that’s a turnaway.

Now – to continue the seasonal theme a little longer – many sales people could probably think of no better gift than a list of hot sales prospects, each backed up with hard evidence of demand for the content they are selling… and that’s exactly what turnaway analysis can provide.

While you might consider failed access stats an uninteresting by-product of your access platform, they can provide hugely valuable insight into customer demand.

To take an example: let’s imagine that 50 researchers at the University of Life tried and failed to access articles from your new title ‘The Journal of Hamster Dentistry’ last month. Even though those users probably weren’t identified individually, somewhere in the logs their IP addresses will have been captured.

It’s then possible to trace that IP information back to the relevant university: either using your own subscriber IP data (if the University of Life already buys other titles from you), or else through third-party IP range data (eg. via Ringgold).

With the detective work done, the gift of a hot lead is ready to wrap up and deliver to your sales team: clear evidence that there’s significant, current demand for that journal, making a compelling case for taking out a subscription.

With budgets squeezed on all sides, this kind of evidence-based selling is increasingly important, to ensure that sales efforts are targeted in the right places. It’s also pretty easy to set up (via MasterVision naturally). So, if you’re not yet using turnaways analysis as a key part of the sales mix, then consider making it a resolution for 2012!

The secret lives of lists

Lists appear everywhere on the web: most commonly as bulleted or numbered text and within dropdown form fields. This comes as no surprise, because lists are a great way of helping users make sense of complex information. However, as with many things that seem simple at first glance, they can pose their own set of tricky challenges once you look beneath the surface.

Let’s start with ordering: that’s easy, right? Well, not always. Alphabetical sorting works well in most cases as that makes the values easily scannable by eye. However, this is surprisingly tricky to get right – we’ve all seen lists with accented words all sorted to the bottom, or quoted and ‘junk’ values with odd characters dominating the top. There’s also the issue of mixed letters and numbers to think about: a standard alphabetical sort will place ‘Package 11′ before ‘Package 2′, which would require some custom rules to make the order more ‘natural’.

Even with these issues addressed, alphabetical sorting is not always best of course. A list of months of the year beginning ‘April’, ‘August’, ‘December’ is not easy to work with, and in other cases it might be more helpful to order values in terms of importance or popularity. A lengthy list might also benefit from being broken up into sections with headings, although that raises the question of how to order the sections themselves as well as the items within them. And so there are more and more decisions to make just to make a list “feel right” to your end users.

In other contexts, users can themselves influence ordering, as when clicking on column headings within data tables. And arguably, of course, tables can be seen as a ‘special’ type of list which present some unique challenges of their own. Here, long values within cells can be a problem, requiring truncation, horizontal scrolling of the table, or both. In particularly tricky cases, a list can itself occur within a cell, making the containing row “too tall” unless more rules are added to address this. In addition, the number of table rows can get very large (think search results), so requiring the ability to ‘page through’ results.

But there are also extra opportunities here: as well as enabling a simple way to re-sort items via a clickable header, tables can also offer the ability for users to choose which items are displayed at any given time. For example, it may be desirable to only show rows relating to a specific product or year, both of which can be achieved via column filters similar to those seen in Excel. With the issues above addressed, and users having full control over both ordering and filtering, a table can therefore represent an extremely flexible way of handling complex lists.

Top tips for bad customer service

Many of the companies we deal with personally provide astoundingly bad customer service (phone, mobile and utility companies: we’re looking at you). Well, they say if a job’s worth doing badly, it’s worth doing really badly – so here are 5 top tips for companies who truly wish to excel at bad customer service.

1. Don’t provide the product/service you’re being paid for. This is really the basic foundation of all customer dissatisfaction. Any aspiring bad service market leader must go out of their way to ensure that deliveries don’t arrive and services are provided intermittently. Note that intermittent provision of a service (eg. broadband) is actually preferable to not providing it at all: it gives much more scope for nurturing customer irritation.

2. Make it really difficult for your customers to talk to you. For maximum impact here, you should first spend millions on branding and advertising to tell the world what a friendly and helpful company you are. Then, ensure that your paying customers are unable to speak to you in the event of a problem. There are two tried-and-tested techniques for this: the automated phone menu gambit, and the you-can-only-contact-us-by-email-which-we’ll-ignore stratagem. Both are proven to provide excellent motivation for customers to tell all their friends how very bad your service is.

3. Blame the customer. If you do have the misfortune to find yourself actually speaking to a customer, do all you can to insist that nothing is wrong. In doing so, it’s good practice to imply that the customer is lying, for example by stating that the delivery “definitely arrived last Friday”, or that mobile coverage is “excellent in your area”. If the query relates to a computer, always imply that the customer is at fault and then say: “have you tried re-installing Windows?”

4. Stitch up your support staff. Everyone knows that a company’s success comes down to its staff, so do ensure that support staff are fully untrained and have none of the information and tools they need to do their job. Your basic disempowering checklist should include ensuring that support staff cannot see customer account details, do not understand how your company’s processes work, and have no authority to change anything.

5. Spend all your money on billing systems. While much of the bad service rulebook is about striving for imperfection, there is one very important exception: your billing systems must be built and managed with all the IT resources of the Large Hadron Collider. Money must be removed from bank accounts with ruthless efficiency, and billing errors in the customer’s favour must never, ever occur. While lightning-quick transactions are crucial in this area, don’t forget to include the feature whereby refunds always take “up to 30 days” to be processed.

And so there you have it, aspiring providers of customer service awfulness: do your worst.

Can I talk to you or not?

An integrated, single customer view has many benefits but it can often pose a tricky question too if your various data sources harbour different opt-in/opt-out contact permissions for the same individuals: can I talk to you or not? It’s important to address this problem, to ensure you are communicating with as many relevant people as possible, while also respecting the wishes of those who prefer not to receive marketing messages. Here’s how we have worked with some of our clients to address this challenge:

1. Let the marketing team decide. If John Smith opted out when he created his registration profile on your content site, but he opted in when he signed up as an author, you might want to keep those different choices visible. Then, when the marketing team creates a contact list for a campaign, it can consider all of those competing opt-in/opt-out filters (drawn together on one screen for easy reference perhaps) and set them appropriately for the campaign in question.

2. One out, all out. The difficulty with the approach above is that if John Smith has conflicting permissions from different source systems, then which value takes precedence? One alternative strategy is to generate a master ‘OK to Contact?’ field and then set that to ‘No’ if any one of the source datasets contains an explicit opt-out. This way you’re only ever using one field to identify who is eligible for marketing, regardless of what the message is. It’s simple and it’s user-friendly (but a “one out, all out” policy will also produce a smaller set of contactable customers).

3. Establish a hierarchy. As an organisation you may see some data sources as more important than others (e.g. member data for a society publisher). In this scenario, you might set your ‘OK to Contact?’ field based on your member data permissions first, then another source second for users with no member data, and so on. In effect that allows you to set business rules to say that an opt-in from your member data overrules an opt-out from elsewhere. While this approach is more complicated to define, the detail does not need to be exposed to the marketing users: they still see the one ‘OK to Contact?’ field and simply set it accordingly.

4. The holy grail? Rather than just finding strategies to handle conflicting permission settings for the same individual, the longer-term goal might be a single system to manage all yes/no permissions data, with an interface for customers to manage all their choices on one page. If your marketing effort is being driven by an integrated, single customer view, it makes sense to try to move away from source-specific opt-in/opt-out options for customers, as it’s this repetition that creates the issues described above. However, it can obviously be a technical challenge to do this if different parts of your front-line, customer-facing business are managed by different suppliers.

Top tips for IT startups in academic publishing

This month sees DataSalon’s 5th birthday and the anniversary of our first client (Oxford University Press) signing up for our customer insight solution MasterVision. Like any startup we’ve definitely had our ups and downs, but 5 years down the line we’re still here, and so it seems like a good time to share some insights into what works well for us:

Specialize. It took us a couple of years to fully work this one out, but it’s a smart move to specialize in one industry. From a product point of view, it means we can fully embrace all of the industry’s quirks and special problems (of which publishing has plenty, such as institutional sales and ‘big deals’). And from a sales perspective, it has helped us enormously when prospective clients feel we really understand their business, and, to coin a phrase, know our articles from our eTOCs.

Focus. We’ve worked incredibly hard over the last 5 years almost exclusively on one single product (ie. MasterVision). To give an idea of just how hard we’ve worked on the software (a hosted service which we can upgrade any time): to date we’ve averaged over 450 minor versions per year. Diversity can be a great strategy for bigger players, but as a startup with limited resources, what works is putting all of your team’s energy into doing one thing very well.

Listen. Perhaps contrary to startup folk wisdom, we haven’t tried to ‘get big quick’, and we’ve spent a lot more time talking to existing clients than we have ‘doing sales’ to potential new ones. With a subscription product like ours, it’s fairly common for IT suppliers to ignore existing customers (they’re paying you anyway, right?). We’ve tried hard to avoid that by staying in regular contact, not least because all of our best product ideas tend to come from listening to what the end users have to say.

Lead. Listening only gets you so far, because being exclusively client-led tends to produce lots of small, incremental changes. We’ve also tried to show some leadership in the overall direction of our product, by looking out for bigger problems in need of a solution. This is what led us to create various ‘hierarchy’ features, to help publishers get to grips with the issues of selling at one level (eg. a university) and how that relates at lower levels (eg. departments within that university). That’s also why we recently published the Customer Insight Framework as a way to lead a wider industry discussion on that topic.

Deliver. For a client, there’s nothing quite so annoying as a supplier saying ‘yes’ to everything when pitching, then, having won the project, explaining how everything is in fact immensely complicated. Our top startup tip: don’t do that! Tell the truth about what you can do and how long it will take, and then meet your deadlines, even if it means working weekends, evenings and nights to do so. It’s simple stuff, but it’s so often done badly within the world of IT, that getting it right really helps you to stand out.

Why we created the ‘Customer Insight Framework’

This month sees the release of our free ‘Customer Insight Framework’ document, which we think is essential reading for all sales and marketing staff working in scholarly publishing. The framework, endorsed by 5 major publishers, presents a concise set of 12 guiding principles for a complete and fully-integrated customer view. So what were our reasons for creating it?

1. Explain why scholarly publishing is different. It’s not stressed often enough quite how different scholarly publishing is from other industries such as direct-to-consumer retail. Most books, articles, and blogs about customer marketing assume the direct-to-consumer model, whereas scholarly publishing is very different: “customers” are a complex mix of individuals, libraries, companies, universities, hospitals, and large buying consortia. This difference should be given due recognition, because it brings with it a whole bunch of complications.

2. Highlight the problems. Noting that “customer” is a difficult concept, further problems arise from this. Firstly, identity becomes a major challenge: do we consider the Chemistry Library to be the same customer as the Main University? Is it also known as the Boyle Library? Is Company X a subsidiary of Company Y, or a separate entity? And with these identity problems come real business challenges: have I already sold to Library A via a big deal? Is University B correctly restricting access only to agreed faculties? Is Company C paying an appropriate rate for its number of staff? We believe these problems are sometimes poorly understood, and often misdiagnosed as “we need CRM” (we’ve blogged in the past about the many meanings of CRM).

3. Define a shared roadmap for like-minded publishers. So, enough with the problems: how can we solve them? A core aim in creating the framework was to try to build some consensus on what the main ‘customer insight’ objectives for a major publisher should be. To that end, we consulted many of our publisher clients when drafting the document, and sought their views on the 12 key points it contains. The checklist now gives our own conversations with publishers a common focus, and highlights ‘gaps’ where pieces of their big picture are still missing. (Interestingly, it has already prompted some interesting idea-sharing discussions directly between the publishers we work with too.)

4. Sell solutions, not technology. The framework stands alone and makes no reference to our own MasterVision product, but it was of course also created with an eye to raising awareness of DataSalon’s services. As a piece of marketing, we hope it will help communicate that we are fundamentally selling ‘customer insight’ (ie. a specific solution to a real problem) not just ‘tools and technology’. We hope it contributes some thought-provoking ideas to a wider industry discussion, and helps to explain why ‘customer insight’ is such a big challenge for all scholarly publishers.

Download the ‘Customer Insight Framework’ (PDF)

What does ‘Back’ really mean?

Website owners spend a lot of time and effort debating and designing navigation menus for their sites, but for users, the most frequently used navigation aid is likely to be their browser’s ‘Back’ button. Consistently placed, and almost always available, it can be trusted to return them to their previous page whenever they suspect they are heading the wrong way.

At least, that was how things used to be. In modern web apps, there is often no concept of a ‘previous page’, but instead a series of previous ‘states’ in which individual widgets have been updated without ever reloading the entire view. The technology behind this is commonly referred to as ‘AJAX’, and has transformed users’ experience of the web in recent years, adding finer grained interactivity to the old request/response/reload model.

But it has also introduced a new challenge for developers, since by default ‘Back’ will no longer magically just ‘work’ as it used to. Instead, its default action of taking users to the last full page they loaded is likely to return them to Google, just before they clicked through to your shiny new AJAX-y site. For developers, the main issue with ‘Back’ has therefore now changed from ‘how can we disable it?’ (as is commonly seen in online banking and e-Commerce checkouts), to ‘how do we make it work as wanted?’.

And this can be tricky, as how users expect ‘Back’ to behave is not always clear cut. As a starting point we could say, ‘Back’ should return users to their previous ‘state’, rather than the last full page they loaded. OK – but what if they just added an item to their shopping basket. Should going back ‘undo’ that action, and return them to the ‘state’ of having an empty basket? Very likely not. Or if that one’s debatable, how about going back after clicking ‘Logout’? Should that restore the ‘state’ of being logged in? Definitely not! (think Internet cafe).

In addition, there’s also the question of what constitutes an application ‘state’, since it’s not always desirable to retrace your steps over every individual change to a page. For example, hiding and showing text on an article page or expanding sections of a dynamic menu is probably not ‘Back’ significant. Similarly, on dragging and dropping a series of items, the user might expect the page to return to its original ‘reset’ state on clicking ‘Back’, rather than replacing them one by one in reverse order. Or in some cases, maybe the opposite…

Over time, more conventions defining best practice for all this will probably emerge, but it’s likely there will always be an element of what ‘feels right’ within a specific context, which will inevitably leave grey areas. So, next time the ‘Back’ button behaves unexpectedly, remember that going ‘Back’ can mean different things to different people, and it’s not always as simple as it seems!

In search of the elusive ‘end user’

When selling or marketing subscription journals, you need at the very least to have a firm grasp of who is and isn’t already getting access to your content. Your approach will clearly be different for existing customers than it is for new prospects. However, the complexities of scholarly publishing mean this is often a lot more complicated than it sounds:

1. Subscribers. At the simplest level, a publisher’s subscription system will provide a clear record of all individuals who are current subscribers. In many other industries where all sales are direct-to-consumer, that’s all you need. However, for a scholarly publisher, that will usually only reveal a small fraction of all the individuals getting access to your latest issue.

2. Institutional access. Because journal subscriptions are usually sold to university libraries, companies or larger buying consortia, the majority of individuals accessing your content are probably anonymous from the publisher’s point of view. When you take a step back and think about it, that’s quite a marketing challenge: the majority of the end-consumers of your product are unknown and quite possibly un-contactable in any direct way!

3. Free access. To complicate matters further, other individuals may have access to your content via various forms of free access. For example: many publishers offer free access to certain society members, to some authors and researchers, and to selected developing world countries. These various types of free access are often recorded outside of the main subscriptions database, making it difficult to keep track of which individuals have free access, and for what reason.

4. Lapsed customers. People who have subscribed in the past fall into a grey area somewhere between ‘customer’ and ‘prospect’, and it’s sensible to target them separately with relevant re-activation offers. However, the task of identifying an appropriate group of lapsed customers is often fraught with doubt: what if they no longer subscribe because they now get free access via one of the routes above? And if so, what kind of an impression will it make to send them an irrelevant re-activation promotion?

5. Single article sales. Thankfully, it’s not all confusion and doubt when it comes to individual marketing. Those who have made single article purchases in recent months should be considered ‘hot prospects’ for two reasons: firstly, you can be sure they don’t already have free access by any of the routes above (they just paid for an article…), and secondly, they are clearly interested enough in your content to reach for their credit card and pay for it.

So in conclusion: publishers should recognize quite how elusive the individual ‘customer’ can be in terms of targeted marketing; and those who aren’t doing so already should consider starting out with a strong promotion sent systematically to all recent single article buyers.

Taking the stress out of testing

Effective testing is key to the success of any IT project, but can be difficult to get right. When not done well, it is a source of frustration for project managers, business users, and developers alike. This month’s feature suggests five tips for removing unwanted stress from the testing process.

1. Testing environment. It can be difficult to test in a poorly configured test site that has incomplete data, broken images, and other points of difference from the final live environment. This wastes time by prompting ‘non-bug’ reports, and acts as a distraction which can cause genuine problems to be missed. Testers should not need to ask ‘will it be faster and more stable when it’s on the live server…?’ but as far as possible be testing exactly what they will see when the new functionality is released.

2. Test plans. The testing process can be made easier for all concerned by creating a written test plan in a spreadsheet, listing step-by-step actions and expected outcomes. This ensures that all key functionality is covered, and makes it easier to conduct multiple rounds of testing by different or untrained testers. In addition, having the ability to run through the entire plan from the top will catch the common case where a fix for one problem has broken something else. As useful as test plans are, it is also beneficial to encourage users to do some ‘off piste’ testing of their own, as this will often turn up more unpredictable issues.

3. Beyond functionality. Most projects focus on testing functionality, but ideally this should be seen as just one part of a wider testing strategy. It may be beneficial to consider browser, usability, security, accessibility, and load testing too. It might sound obvious, but a website that functions perfectly for your internal testing team is of limited value to an outside user who can’t view it in their chosen browser, or finds the site is too slow to respond. With all bases covered, you can be more confident there won’t be any nasty surprises after launch.

4. Automated testing. In cases where testing is repetitive and time consuming for users, it can be beneficial to enlist the services of a ‘robot helper’ to run the tests programmatically. It is possible to automate any web based task that can be completed by a human, including logging into a site and moving through a step-by-step process, such as adding items to a shopping basket and then checking out. A smart developer might also enable their ‘robot’ to read and write spreadsheets, allowing it work through an input list (eg. of 100 products) and log the results for review, saving a huge amount of human time and effort.

5. Shared responsibility. Testing can be completed more smoothly if everyone does their bit, rather than seeing it as someone else’s responsibility. Above all, developers should test their code from a user’s point of view before releasing it for wider testing, such that they themselves are confident that no bugs will be found. That doesn’t guarantee a bug free development of course – but it’s a good starting point! On the tester’s side, they should see it as their role to track down and report any bugs that do exist, such that a problem that is missed is equally their own responsibility. And for the project manager, it’s essential to give testing the time it deserves, and not view it as something that can be ‘squeezed’ if schedules slip elsewhere in the project.

Follow

Get every new post delivered to your Inbox.