We don’t want “sales”.
We want a good fit.
Choosing Consonance means choosing the most supportive, most pragmatic, most expert and interested publishing management partner, with the highest quality ONIX and the most intuitive, modern interface. That sounds great, but it’s not right for everyone. If we both discover, too late, that it’s not right for you, that’s a lot of wasted time and effort on both sides, and a difficult relationship. And no amount of money is worth misery at work.
So we don’t do “sales” – we do “fit checks”. We want to ensure that what we are best at is what you actually need. This is a guide to who we are, what we’re great at, and what we’re not. We hope it helps you get a feel for whether Consonance is right for you, or whether another system would be a better fit.
Creating the publishing future we want to see .
If you want to avoid the standardisations that exist in the book trade (e.g. ONIX), or if your plans involve disrupting publishing entirely (e.g. through replacing the creative people that underpin our industry with AI; by selecting manuscripts according to an ‘algorithm’; or through pursuing zero-hours contracts), we’re not the right partner for you. But if you need a partner to help you deliver your progressive business model, read on.
Most of our clients have a progressive agenda, and we ship features in Consonance to help them. Burleigh Dodds Science Publishing, for example, required a new work derivations feature for their remixed-content model. UCL Press pioneered Open Access, which we enable in ONIX. Canelo reimagined the entire ebook publishing process. Consonance supports Boldwood Books to run royalties on a schedule that fully centres their contributors, and to publish each work in eleven product formats including physical and downloadable audio, epub, large print and hardback. Bookdash deliver their literacy-improving mission using our API to build dashboards which help funders appreciate the reach of their investments. The clients we feel we support best are progressive, and growing, with a large amount of data to handle.
Our business.
If your experience tells you that large software providers, with the highest market share, deliver great value and service, go with them. But if you think “highly experienced”, “rapid development time”, “small, responsive team”, and “ONIX expertise” are benefits, read on.
We started in 2011, with a system built to meet the needs of a single publisher. (The directors still own and run that publisher, which helps keep us directly aware of the realities of publishing.) We grew initially by working mostly with trade publishers. As we have grown we have gained a strong customer base of academic and professional publishers, who tend to need management of much more complex data.
We are wholly owned by our three directors, and have no other shareholders or debt, meaning our decisions are untainted by aggressive stakeholders chasing a fast ROI. We are profitable and maintain enough cash in the bank to ride out the next pandemic-level crisis.
We are seasoned experts in the book trade supply chain, and in the programming tools we use. (Our Jobs page has details of our tech stack.)
Our pricing is by user. Some competitors charge by work or product count, which isn’t appropriate for us, because the clients we serve best choose Consonance to fuel their growth: pricing by product penalises clients who grow their output. Similarly, we don’t charge by module: our license gives access to all functionality, otherwise we would be financially penalising clients for aspiring to “one version of the truth” across all their teams.
Best of breed vs enterprise? Your experience will inform what’s best for you. Consonance is the right choice if you want enterprise features and support at SaaS prices.
Our approach to service.
Our support tickets are received directly by our programming team, not by a non-technical support team. If your experience shows that non-technical support staff provide meaningful help, great. If not, and if it’s appealing to know that you correspond directly with the people who create the code when you need something doing, read on.
Usually, support tickets are to do something: change some data for a rare, edge-case reason, or accommodate another system’s changed requirements. But some tickets have been sent by clients which suggest really good ideas. We tag these, then we’ll try to action it – when we’re working on a relevant part of the system, or earlier, if it’s both a good idea and urgent.
We often write and deploy code to solve support tickets, then and there.
We prefer that every user of the system is encouraged to contact support for help. Funnelling all requests through one contact adds a layer of obfuscation and removes user agency. Similarly, we don’t allocate clients an “account manager”: support requests can draw, as relevant, on the expertise of any of our senior staff.
We maintain a user community forum to share and solicit advice and manage feature developments. We also run webinars from time to time and have a library of videos to play on catch up.
Our technology.
We have one very large codebase, which can be deployed as a private cloud for clients who want to directly query their own database, and to our public cloud. Whilst other vendors’ public clouds are one-size-fits-all, which both slows down rollouts of new functionality, and means everyone has to get every new feature, the Consonance public cloud has the best of both worlds: being able to accommodate client-specific code means tailored features when you want them, and lots of continuity when you don’t. We use Heroku and AWS for our hosting and storage to access world-class security and reliability: if you feel on-premise or vendor-managed data centres provide a better experience, choose another partner.
Consonance is a web app, deployable to a private cloud or to our public cloud which is accessed over the internet at https://web.consonance.app.
We have a GraphQL API to allow clients to develop their own integrations. We’ve been so delighted with the imaginative, brilliant things some of our clients are building with their own data and like the idea of Consonance being “The Most Open Publishing Software”.
We write modern, version-controlled code with extensive automated tests. We feel at home, and sometimes speak, at tech events like Brighton Ruby and Railsgirls.
We don’t charge for developments that make our system better for all clients, and we don’t take years to do it. We only charge for code that you need us to develop that is entirely bespoke to you and we release new code every day, although it’s rarely apparent: we balance stability with under-the-hood maintenance and improvements.
Our codebase includes many features which suit enterprise clients with a large amount of data, such as custom abilities; bulk price, metadata, ONIX and contract data importers; file uploaders; and ebook analysis tools. It is strongly centred around the ONIX standard, with a hefty layer of pragmatism to map ONIX to the real world, in areas such as in-house subject codes, and format and edition descriptions.
Our team.
We’ve been a team of six or seven for the past few years, with alumnae from Pharma Press, OUP, Bath University, and local government. The director-founders have publishing, retail, Oracle, and management consultancy backgrounds. All staff write code.
Two of the three founders work full-time as programmers and business managers and we aim for a collaborative approach.
We do not have separate marketing or sales teams, preferring to invest our time in the product, not in persuading people to buy it: build it and they will come has worked well for us, as our good reputation spreads through client recommendations.
All staff are full time employees, and we work as a distributed team across the UK. We dropped office life at the beginning of the pandemic, and it’s worked well for us, so we no longer have an office at all.
We don’t think many shiny new tech bandwagons solve the real problems of data quality and process management in publishing: we are AI-, blockchain-, NFT-skeptics. We encourage technical literacy in publishing so that any new technologies can be assessed by teams from a position of knowledge and insight: for example, our Day of Code is the only publishing-specific coding course and Emma, our CEO, writes, speaks at conferences and guests on podcasts about how technical literacy futureproofs the industry.
We have a can-do, no-bullshit-please, inclusive, learning-oriented culture. Some of our other websites are Just Simply (say “no” to saying things are simple, when they’re not!), Nope (a tongue-in-cheek way to help people to say “no”, via a web page that took 30 mins to write), and our GraphQL Docs (showing our clients ways to do more with their own data, with code.) Our blog contains our thoughts on matters of publishing, process and technology.