Manuscript and Peer Review Software: Why Editorial Workflow Breaks at Scale

Why manuscript workflow becomes the publisher's real product

A scholarly publisher does not sell papers. It sells the credibility of a process. Everything a reader trusts about a published article rests on whether the right editor handled it, whether the reviewers were independent, whether the integrity checks ran, and whether the record of all of that survives for the next twenty years. The manuscript system is not administrative software. It is the evidence trail for the thing you actually sell.

The daily reality in most editorial offices looks less dignified. A submission arrives. Someone checks the scope by eye. Someone else runs a similarity check and pastes the score into a spreadsheet. An editor is assigned from a rota in a shared document. Invitations go out and the chase begins: seven invitations to secure two acceptances, reminders sent by hand, one reviewer who accepted six weeks ago and has gone silent. Meanwhile the author's institution may or may not be covered by a transformative agreement, and that answer lives in a different spreadsheet owned by a different team.

The cost of the gaps is not abstract. Time to first decision is the number authors judge you on, and it decides whether good work comes to you again. Integrity failures are worse: a paper mill submission that gets through becomes a retraction, and retractions are expensive in ways that never appear in a budget line. Both are failures of orchestration, not of any single tool.

Problem 1: every journal has a different review model, and configuration is a queue

A society journal in clinical medicine runs double anonymised review with a statistical reviewer required for any trial. A physics title runs single anonymised with a fast track for preprints already posted. A humanities journal wants open review with published reports. One title has an associate editor layer, another sends straight from editor in chief to reviewers. A new open access title wants a cascade from a rejected sibling journal with the reviews carried across.

ScholarOne and Editorial Manager both handle an enormous range of configurations and both run very large portfolios reliably. The constraint is not capability, it is control. Configuration typically goes through the vendor's professional services team, so a new review model or a new submission gate becomes a change request in a queue rather than something your team ships in a sprint. When editorial strategy changes faster than that queue moves, workarounds accumulate in spreadsheets. eJournalPress is more configurable and societies like it for that reason. Open Journal Systems is free and open, which makes the flexibility real and the responsibility for the stack yours.

A custom build makes the workflow itself data. A journal is a configuration: its stages, its roles, its blinding rules, its required declarations, its decision letter templates, its deadlines. Adding a new title is an afternoon, not a project. Adding a new review model to one title does not risk the other 300. That is the single strongest reason a large publisher builds, and it is a product velocity argument rather than a features argument.

Problem 2: the reviewer chase is the bottleneck, and invitations are sent blind

Finding reviewers is the slowest step in the pipeline and the one editors hate most. The editor searches their memory, the reference list of the manuscript, and possibly a keyword search of the system's own reviewer database, which is stale because it only knows people who have reviewed for that journal before. Invitations go out in batches, declines come back, and the manuscript sits.

Systems have reviewer databases and reminder schedules. What they do not do is model the reviewer as a person with real capacity and a real conflict profile. Someone with three manuscripts open across your sibling journals should not get a fourth invitation this week. Someone who co authored with the submitting author recently should not be invited at all, and checking that means looking at publication records rather than asking the editor to remember.

This is where a build earns its place, and the one place we would put a language model to work with confidence. Reviewer matching from the abstract against publication embeddings finds people the editor would not have thought of, including early career researchers who are willing and under used. Conflict detection runs against co authorship and affiliation history and returns a reason, not just a flag. Invitation batching respects capacity across the whole portfolio rather than per journal. The model suggests and the editor decides. Nothing about acceptance, rejection or reviewer selection should be automated, and any developer proposing it has misunderstood what you sell.

Problem 3: research integrity screening is a dozen signals with no single view

Screening is no longer one similarity check. It is similarity, image duplication, tortured phrasing that indicates machine paraphrasing, references to retracted papers, submission pattern anomalies across the portfolio, and increasingly checks shared through the STM Integrity Hub. Each signal comes from a different tool with a different output format.

Submission systems integrate with some of these and not others, and where they do the result is usually a score dropped into a field. What nobody gives you is a case view: this manuscript, these eleven signals, this reviewer's comment about the methods section, this pattern of three similar submissions to three of your titles in the same fortnight. Portfolio level pattern detection is impossible when each journal is an island, and paper mills specifically exploit that.

A custom build treats integrity as case management. Signals from every screening tool land against the manuscript, weighted by your own policy, and open a case when a threshold is crossed. The case carries evidence, correspondence and the decision with a named person attached, because when a story runs about a paper you published, the question is what you knew and when. Cross portfolio queries run in one place: show every submission in the last year sharing an author, an institution and a suspicious pattern. That query is the difference between catching a mill and reading about it.

Problem 4: open access entitlement is checked by a human against a spreadsheet

Whether an accepted author pays an article processing charge depends on their institution, their funder, the agreement your organisation has with their consortium, whether that agreement still has capacity for the year, and whether the article type is in scope. Transformative agreements and read and publish deals have made this the norm rather than the exception, and Plan S obligations add funder specific licence and deposit requirements on top.

Editorial systems were not built for this, so the check happens later, by a person, in a spreadsheet, at acceptance. That timing is wrong. The author needed to know at submission, because the answer changes where they submit. Getting it wrong at acceptance produces an invoice to an author whose institution should have covered it, which produces a complaint and a support ticket.

A custom build resolves entitlement at submission from the author's institutional and funder identifiers, checks the agreement and its remaining capacity, and shows the answer on the submission screen. It also carries the licence and deposit obligations forward, so production already knows the required licence and the target repository. That is compliance evidence for the agreements your library sales team signed.

Problem 5: production handoff and deposits are the invisible tail

Acceptance is not the end. The article needs a DOI registered with Crossref including funder and licence metadata, JATS XML from the typesetter, repository deposits, ORCID records updated, and the version of record linked to any preprint. Later it may need a correction or a retraction, each with its own notice, DOI relationship and trail back to the original decision.

Most publishers run this as scripts maintained by one developer who understands them. The retraction path in particular tends to be entirely manual, which is unfortunate given that it is where accuracy matters most and where the public is watching. A build models the article record as a versioned object with its relationships, and makes correction and retraction a first class workflow rather than an exception handled by email.

What this costs and how long it takes

Across the 2,000 plus projects Digital Heroes has delivered, here is the honest shape for scholarly publishing workflow. A focused first release covering submission with configurable checks, editor assignment, reviewer invitation and workflow, and decision handling with letter generation runs $80,000 to $180,000 and ships in 14 to 20 weeks. A full platform adding integrity case management, entitlement resolution, production handoff, Crossref and repository deposits, and reporting for funders and society boards runs $250,000 to $600,000 phased over 9 to 18 months.

What drives the price up in this sector specifically: the number of distinct review models you need on day one, because each is real configuration work even in a flexible system. Migration of legacy manuscripts, almost always the single largest line item, because twenty years of submissions with attachments and review history do not export cleanly from anywhere. Integrations with screening vendors, each its own contract and API. Deposits, because Crossref, PubMed Central and funder repositories each want different metadata. And the number of editorial offices you have to train.

Build versus buy, and when Editorial Manager is the right answer

Buy if you publish under about ten journals with conventional review models and no unusual integrity or entitlement requirements. Editorial Manager and ScholarOne are mature, heavily used and reliable, and reinventing them for a small portfolio is a poor use of money. Open Journal Systems is a legitimate answer for a society or university press with technical capacity and a modest portfolio, and the price is right. eJournalPress deserves a look for societies whose editorial models are unusual, because its configurability is real.

Build when two or more of these are true. You publish enough titles that vendor configuration queues are slowing your product roadmap. Your integrity screening involves more than three tools and there is no case view. You are operating transformative agreements at scale and entitlement is resolved by a human after acceptance. You need portfolio level pattern detection across journals because paper mills are targeting you. Or your parent organisation has a data residency or archival requirement that no hosted vendor will meet.

Our position, stated plainly: the argument for building here is rarely about features and almost always about who controls the release schedule. A publisher whose editorial strategy is a competitive differentiator cannot have its strategy gated by another company's professional services backlog. A publisher whose strategy is stable does not have that problem and should not spend the money.

How to choose a developer for editorial and peer review software

Ask them to model blinding on a whiteboard. Double anonymised review is not a display rule, it is a data access rule that has to hold across the interface, the emails, the attachments, the file metadata inside submitted documents, and the audit log. A developer who treats it as hiding a name in the UI will leak an identity through a Word file's author property within the first month.

Ask how they would handle a retraction. The answer should involve versioned records, DOI relationships and a preserved trail back to the original decision and its participants. If the answer involves editing a status field, they have not worked in this domain.

Ask what they have actually integrated. Crossref deposit, ORCID authentication, iThenticate, PubMed Central and a typesetter's JATS pipeline are five different problems with five different failure modes. Ask for the specific service and the specific document type, not a general claim about APIs.

Ask who owns the code and get it in writing before kickoff, along with an explicit data export commitment. You are custodian of a scholarly record that has to outlive your vendor relationships. At Digital Heroes the client owns the code from the first commit, and for this sector we would also insist on a documented, tested export path before go live.