What makes Consonance the new standard in publishing management?. Find out more

It’s rare that we onboard a brand new start-up: most new clients migrate to us from another system. Here’s why they choose Consonance – and how the migration works.

“Our current system works, but…”

You have a system. It’s where your data is, and it’s what your team uses. But there are problems… Publishers switch to us when the following sorts of problems build up to the point where
they can’t be ignored.

  • Problem: Budgets are tightening while costs are increasing. With a long backlist and pay-per-unit pricing, you’re penalised for wanting longtail sales and keeping useful historical records. With a proliferation of modules, your budget is cheesepared away and system functionality is siloed. Consonance charges by named user, without extra costs for more functionality — £75 gives you full access. Neither do we charge extra for personal support, extracting data into ad hoc reports, project management, consultancy, scripting or custom coding, most of the time.
  • Problem: There’s more to do than ever, and everyone’s working overtime. A good system is not one that provides the bare functionality you need. It’s one that also gives the countless small conveniences that lighten your workload and let your staff work efficiently. Publishers migrating to Consonance talk of the relief of having a system that’s well-designed. Good design is more than colours and fonts – it means people intuitively find what they need, when they need it. Layout matters. Accessibility matters. The usability of the app you spend every day of your working life in matters.
  • Problem: We need to work our own way, not be forced into a mould. Your editorial, production, and sales and marketing workflows are unique to you. If you need to map your real-world processes to the strictures of your system, and if you need staff to document workarounds, that’s a bad smell: your current system is inflexible and hard-coded to their way of working, not yours. Consonance enables you to specify your own edition and format names, and your own task lists, and work types, and seasons, while adhering to the core vocabulary of ONIX.
  • Problem: We’re hobbled by cut-down features and integrations. For any but the very largest of publishers, with in-house technical staff to manage integrations, managing data exchange between different systems for title management, programme management, contracts, royalties, production, etc, is painful. Nothing is perfectly in sync, and you can spend hours troubleshooting issues. For example, with a separate programme management system, it is difficult to synchronise tasks with your works’ earliest print product publication dates when they change because manuscripts needs extra development. A “lite”, introductory or “small and medium publisher” version of a system can mean a large invoice is in your future to unlock the features you’ll need as you grow. Consonance prices by the size of your team, not by module: you can afford to have all of its functionality from day one, and everyone has access to everything. Your account is configured to tailor access from the starting point of “everything’s available” – so you refine what you see through choice, not necessity.
  • Problem: We need enterprise integrations. Large publishers seeking integrations between in-house systems and best-of-breed SaaS solutions need powerful and reliable data exchange. Consonance offers a comprehensive metadata update API through GraphQL, and for the most extreme scaling Consonance can offer bespoke integration with message queueing services, such as AWS SQS, and direct access to a dedicated PostgreSQL database for fast and reliable data extracts.
  • Problem: Complete metadata can still be bad metadata. Does your system’s interface not visibly warn of Thema best practice violations? Does it convert 192 millimetres to 7.559055118110236 inches instead of 7916? When you enter a price in a foreign currency, does it not warn you if it’s the equivalent of a tenth of your home currency price? Does it not allow you to send ONIX only when particular data quality gates are met (e.g. “must have a USD RRP library price”), which are different per recipient? Do you need foreign currency pricing set automatically, and updated on a monthly basis according to custom rules? Poor discoverability and poor product presentation lead to public embarrassment and schedule-threatening rework, and the hidden cost of errors from a system that runs with a lack of publishing intelligence is more than the cost of switching systems.
  • Problem: the industry is changing, and we’re held back. Perhaps audiobooks, or even ebooks, feel like a second class citizen in your metadata. Perhaps you need to be adopting Open Access, but your partners need that in ONIX. Regulations on product safety, accessibility, and deforestation are potentially high maintenance issues with the potential to stop products sales in their tracks. Do you have a system that is committed to staying up to date with emerging requirements, and supporting new metadata workflows in an intelligent way?

Migration myth-buster

When you have low confidence in the likelihood of your current system supporting you into the future, the cost of staying starts to feel greater than the effort of moving. But how great is that effort?
  • Myth: a new system means expensive consultants. Consultants love new system migrations, where they can become a permanent intermediary between you and your system vendor. At Consonance, our motivation is to get you up and running on a system you understand as soon as possible, establishing a direct relationship between your experts and ours. Migrating to Consonance does not require a consultant, and we charge very modestly (about £2500 for a small implementation) to run the whole project.
  • Myth: a system migration means massive distraction for the whole team, for months. We set up a sandbox environment with your real data, and work with select experts from your team to establish data clean-up and enhancement rules. When it’s looking good, we work with you to train your team on your data. No months-long full-team-doing-day-job-plus-system-implementation nightmares.
  • Myth: a system migration means mapping our data from our current system to Consonance. Consonance imports ONIX 3 data from your existing system. We have a test account set up for you within a day, populated with your full ONIX catalogue, for you to assess features and to get a sense of how your real data looks.
  • Myth: My website feed would break. Maybe it would (we can’t say until we know your set-up). But if it is an ONIX feed, or fed by a compatible API, it will be uninterrupted.
  • Myth: Consonance is aimed only at small publishers. Taylor and Francis trust the scalability and sophistication of Consonance to send millions of ONIX product updates. And that sophistication is available to smaller publishers, whose requirements are often no less complex. We pride ourselves on providing elegant solutions to complex problems, at any scale.
  • Myth: we’d have to spend ages cleaning up our data before we could move. You don’t need to have your data completely polished before moving to Consonance (see Cleaning up data: before or after the switch?, below.)

What’s better?

Q: Switching publishing management systems is a disruption, even when the migration is smooth — so what is it about Consonance that makes publishers do it?

A: Publishers know when they have a problem. They identify that Consonance has the capabilities to get them out of trouble, today – and to future-proof them, tomorrow.

  • Feature-rich, beautiful and harmonious web app, spanning the whole of the publishing process, with features developed over years of on-the-ground publishing experience and working with clients from across publishing.
  • Client list to be proud of: you’ll be in good company.
  • Top quality, always-valid, accepted-everywhere ONIX
  • Inline help, extensive online training, responsive and engaged support staff who write same-day code and scripts to help you, rather than reading the documentation at you and acting as a firewall to the development team. Support is the development team.
  • Low cost, high value
  • Publishing intelligence. We also run two publishing companies, and this real world knowledge keeps us very pragmatic.
  • Focus on maintainable, excellent code. All our code is tested, libraries kept up to date, and we use industry-standard practices (Git, CI), and tooling (AWS, Heroku, Skylight, Basecamp, Rails, PostgreSQL etc.)
  • Small, excellent team, with expertise in both publishing and programming. Our staff are previously of Amazon, OUP, Bloomsbury, Pharma Press, University of Bath, large county councils, Oracle shops, KPMG, Deloitte, and beyond.
  • Take a look around this website to dive into the detail.

Cleaning up data: before or after the switch?

It’s never a bad time to do some housekeeping, even if you aren’t thinking of a new system.
Here are some initial considerations.

  • Is the cleaning possible? If your current system does not support, for instance, prizes, meaning all your prize award information is currently in marketing texts, then putting that data into the right fields will need to be done in your new system. Make sure the vendor is commited to supporting that.
  • Is the cleaning necessary? Some systems need metadata specified that smarter systems can infer. Migrating is the fix.
  • How will the cleaning be done? Does your current system support powerful searches that let you identify repetitions of a problem elsewhere? Does your old system support bulk changes through its interface, or do bulk changes need to be done by their support team? If you’re changing to a new system then the new system’s support team is probably more motivated to help.
  • How are problems going to be identified? When you start cleaning data, you usually start off by noticing an occurrence of a problem, then wondering how frequent that is. We support you in that discovery process, drawing on our past experience of oft-seen problems.
  • What are your timelines? If you have a contract that ties you into an existing system for another 9 months, or some development on our end was an absolutely necessary prerequisite to migrating, then perhaps data problems might as well be solved before migrating.
  • It can be difficult to make these assessments until you know what you’re going to clean. The first step can be to build a preliminary list of identified metadata problems, and categorise them into how they would be fixed in your existing system, and how/whether they would be fixed in Consonance. We host that project work on our project management tool, which allows us to provide input as relevant.

Questions to ask

Ask potential systems vendors questions like these. The answers will illuminate whether they will future-proof your business.

  • “Can I see your settings pages?” If they’re not as polished as the system’s marketing pages, that indicates a focus on selling, not serving.
  • “What happens if we need custom code?” If they won’t write custom code for your business requirements, or charge outlandish sums for it, or give long timescales, it might indicate a brittle architecture.
  • “What’s the cost of data storage for my large audio book files?” If the answer is more than zero in the age of cheap storage, that indicates a bad technical architecture or a money grab.
  • “Do you support audio / EUDR / Open Access / [other emerging publishing requirement]”. Can you talk directly to knowledgable staff members who can discuss these issues with you, and who have the authority to promise solutions? Or are you getting glib answers from a salesperson?
  • “How much will it cost when I want to upgrade from "lite” / add a royalties module / set up a feed?“ Watch out for hidden costs that penalise you for growth.

Next steps

Switching systems can be a long journey, but it starts with understanding your options.

Consonance doesn’t have sales people, or a separate professional services department, with quotas to fill by the end of the quarter. Feel free to get in touch, and we can talk.

We might not be right for you, and you may not be right for us, and the only guarantee we can make before talking is that if your problems are not ones that we can help you with, we will not tell you that we’ll solve them.

Either fill in our contact form, whose questions tell you the sorts of things we’ll ask first, or email our CEO on emma@consonance.app, directly.