Let's get the obvious bit out of the way. We sell subscription software, so I'm not a neutral party. But I've also spent years on the other side of the table, running circulation for publishers on other people's systems, and I've seen what goes wrong when the choice is made on the strength of a good demo.
So here's the checklist I'd use if I were buying. Ask these questions of us, and of anyone else.
Start with your problems, not their features
Every demo looks good. The supplier has rehearsed it, the data is tidy and the awkward cases don't come up. That's why you need your own list before you see anyone.
Write down:
- What's going wrong today. Renewals going out late, month-end taking a week, audit preparation by spreadsheet, nobody trusting the subscriber count.
- Your awkward cases. The corporate licence with forty named seats and an IP range. The bundle split across three titles. The overseas customer paying in euros. The controlled circulation reader who also buys a paid supplement.
- Who will use it. Customer service, circulation, marketing, finance, editorial, ad sales. Each will judge it differently.
- What it has to connect to. Your paywall, payment gateway, email platform, mailing house, accounts package.
Then ask every supplier to show you your awkward cases, not theirs.
Is it built for publishing?
Generic subscription billing tools are very good at monthly software plans. Publishing has needs they often don't cover:
- print and digital, sometimes in the same order;
- issue schedules, with subscriptions measured in issues as well as dates;
- controlled circulation, with request source, method, date and qualification answers;
- gone-aways and missed copies;
- mailing files for each issue;
- audit-ready circulation counts by category.
If a supplier has to describe how they'd "configure around" most of that list, it's probably not built for you. Our guide to controlled circulation covers what that side needs in more detail.
Will finance be happy?
This is where cheaper systems often come unstuck. Ask to see:
- a sales ledger with payment matching, credits, refunds and write-offs;
- deferred revenue by publication, released per issue or over time according to your policy;
- VAT handled by rules rather than by hand, especially for overseas and mixed print and digital sales;
- multi-currency, if you sell abroad;
- a month-end that runs without a spreadsheet in the middle.
If your finance director isn't in the demo, they should be. There's more on this in deferred revenue for subscription publishers.
Can it survive an audit?
If you're ABC or BPA audited, ask how the system will help you produce your return and back it up. Can it count circulation by category as at a past date? Can it show you the age of your requests? Does it keep a record of what was mailed for each issue? Our guide to preparing for an ABC audit has the list of evidence auditors look for. Ask the supplier to show you each item.
What about your data?
Some of the most important questions are about data, not features.
Getting in. How will your existing data be migrated? Who does the work? How will you check it's right afterwards? Will your history (orders, payments, preferences, notes) come across, or just the live subscribers?
Keeping it clean. What does the system do about duplicates, bad postcodes and invalid emails? Can it prove marketing consent, with dates?
Getting out. If you leave in five years, how do you get your data back, and in what form? A supplier who's comfortable with this question is usually a good sign.
Security. Two-factor login, permissions by role, an audit log of who changed what. These should be standard, not extras.
Who will you be dealing with?
Software is only half of it. Ask:
- Who answers the phone when something goes wrong, and do they understand publishing?
- If you need a change, who makes it and how long does it typically take?
- Is development done in-house, or passed to a third party?
- Can they run any of the processing for you if you're short-staffed?
These matter more over five years than any single feature. For what it's worth, our development team is in-house, which is why we can usually ship changes in days rather than months. There's more in how we build.
Size it honestly
Bigger isn't better. A system built for a large multi-title group will be overkill for a two-title publisher, and the reverse is just as painful. Be honest about your volumes, your complexity and where you'll be in three years.
That's why we have two products. Avio is for larger publishers with heavier volumes and more complex requirements: multi-currency, corporate licences, finance-grade accounting. Adeptis is for SME publishers and goes wider rather than deeper, adding a news CMS, advertising, a media pack generator, email insight and prospecting to CRM and circulation. If you're not sure which you'd need, Avio or Adeptis sets it out.
Warning signs in a demo
- They won't use your examples, only theirs.
- Every awkward question gets "that's on the roadmap".
- Finance features are "handled by an export to your accounts package".
- Nobody can explain how data migration works.
- The person demonstrating has never worked in publishing.
None of these is a deal-breaker on its own. Three or four together should make you think.
Take references, and take up the references
Ask to speak to a publisher of a similar size who has been using the system for a while. Ask them what went wrong during the move, not just whether they're happy now. Everyone has a story. How the supplier handled it tells you most of what you need to know.
A short checklist
- Write your problems and awkward cases down first.
- Make suppliers show your cases.
- Get finance into the demo.
- Ask about audit evidence item by item.
- Ask how data gets in, stays clean and gets out.
- Find out who you'll actually be dealing with.
- Size the system to your business, not your ambitions.
- Talk to a reference about the hard bits.
If you'd like to put us through it, we'd welcome that. Book a demo, bring your awkward cases and we'll show you how Avio or Adeptis handles them.