Posted on: September 7th 2026
The best support systems do more than answer questions. They recognize when a question has quietly turned into a different kind of problem.
Seven words appear in the support window:
Will my institution cover the publishing charge?
On the author’s side of the screen, this feels like a yes-or-no question. The paper has been accepted. The institution has an open-access agreement. The author wants to know what happens next.
Inside the publisher’s systems, however, the answer may be scattered across a manuscript record, an institutional agreement, an author profile, and a set of eligibility rules. The institution named in the manuscript may not match the author’s current email address. The agreement may apply at acceptance rather than submission. The corresponding author may have changed during revision.
None of this is visible in those seven words.
A conventional helpdesk sees a ticket. A well-designed support model sees a question whose shape is not yet known.
When a simple answer really is simple
Sometimes the evidence lines up. The manuscript is identified, the affiliation is clear, the agreement is current, and the eligibility rule leaves little room for doubt.
The author should not have to wait for a person to retrieve information the publisher already holds. Self-service can confirm the relevant agreement, explain the conditions, and show what the author needs to do next.
There is no virtue in adding a queue where none is needed.
The work changes when the answer requires an action. The system may need to confirm the author’s identity, connect the query to the correct manuscript, check the agreement, and update the case. If the evidence is complete and the action follows a clear rule, automation can finish the job.
From the author’s perspective, very little happens. The question is asked. The answer arrives. The path between them is uneventful.
That is what good routine support should feel like.
When the question changes shape
Now alter one detail.
The author submitted the paper while working at one institution and moved to another before acceptance. One institution participates in the agreement; the other does not. The manuscript contains both affiliations. The email address suggests one answer, while the publishing record suggests another.
The author is still asking the same question. The support system is no longer dealing with the same problem.
This is the moment many automated experiences are handled badly. The system has found some matching evidence, so it continues as though it has found enough. It produces a confident answer at precisely the point when confidence should be falling.
A more responsible system pauses.
Automation still has work to do. It can assemble the manuscript history, identify the affiliation change, retrieve the relevant agreement, and place the important dates side by side. But its role has shifted. It is no longer answering the author. It is preparing the case for someone who can.
A reviewer may be able to resolve it under an established rule. If the agreement requires interpretation, the case moves to an open-access specialist. The specialist receives the evidence and the unresolved question, rather than an email forwarded with the hopeful instruction, “Please advise.”
The author does not know which tier handled the query, and should not need to know. She sees one conversation that remembers what has already been established.
The support system has to do something people often do instinctively and software often does not: change its mind about what kind of problem it is looking at.
The expensive answer is the wrong one
Imagine that the system does not pause. It relies on the author’s email domain, finds a participating institution, and confirms that the publishing charge is covered.
Weeks later, an invoice arrives.
The author returns to support carrying the earlier answer. The service agent cannot see how it was reached. The open-access team is working from a different record. A librarian becomes involved because the institution appears to have been identified as the payer.
A query that might have required one careful review has become a dispute spread across several teams.
The failure began long before the invoice. It began when the support system mistook a plausible answer for a reliable one.
This is why deflection can be a dangerous measure of success. A question that disappears from a queue may have been resolved. It may also have been postponed, displaced, or made harder for someone else.
The more useful test is whether the answer will survive contact with the rest of the publishing process.
That requires visible boundaries. Which record is authoritative? How current is the agreement? Is any evidence missing or contradictory? Can an incorrect action be reversed? Who is allowed to make the final call?
Automation does not become safer by sounding cautious. It becomes safer when it knows where its authority ends.
A handoff without amnesia
From the specialist’s desk, the quality of the support model is immediately apparent.
A poor handoff contains a forwarded message and perhaps a case number. The specialist must reconstruct the manuscript history, locate the agreement, discover the affiliation change, and work out what the author has already been told.
A good handoff begins further ahead. It contains the verified manuscript and author details, relevant affiliations and dates, the agreement consulted, checks already completed, the previous response, and the precise uncertainty that remains.
AI can retrieve records, organize the chronology, compare the available evidence, and surface the relevant clauses. The specialist still owns the interpretation and the answer.
That division of work matters. Specialist time should be spent deciding the difficult point, not performing administrative archaeology.
The key to this handoff lies in combining sophisticated AI orchestration with deep domain knowledge. By automating high-volume technical tasks, such as manuscript formatting, metadata tagging, and compliance checks, publishers empower specialist teams to focus on judgment-intensive work. This approach ensures that the support model is not merely a tool for speed, but an integrated capability that respects the nuance required for scholarly and editorial decisions, keeping the human expert firmly in the loop where it matters most.
It matters to the author as well. Every request to repeat a manuscript number, resend an old reply, or explain the problem again reveals a break between the publisher’s internal systems. The organization may see several teams. The author sees one publisher that has forgotten the conversation.
Authority has to be designed before automation
The hardest part of this model is not selecting a chatbot or connecting another workflow tool. It is deciding, in advance, who is allowed to answer which question.
For every significant query type, the publisher needs an operational position. What is the authoritative source? What action may be taken automatically? Which conditions require review? Who owns an exception? Who can overturn an earlier answer?
Without those decisions, automation simply inherits existing ambiguity and delivers it faster.
This is particularly important in research publishing because service teams often sit beside, but cannot replace, editorial and policy authority. Support may identify an authorship concern, preserve the record, and route it urgently. It should not decide the dispute. It may prepare the evidence for an appeal, but the editorial decision belongs to the authorized editor or publishing team.
What one difficult query can teach
The case should not vanish once the answer is sent.
Perhaps the agreement guidance did not explain how affiliation changes are treated. Perhaps two systems held different institutional information. Perhaps the automated route trusted an email domain more than the manuscript record. Perhaps the author was asked for information already collected during submission.
Each possibility points to a different repair.
A policy owner may need to clarify the guidance. A publishing team may need to capture affiliation changes more clearly. The support workflow may need a new review condition. Similar cases may need to be watched to determine whether the problem is isolated or recurring.
This is how support begins to improve the experience around it. Not by allowing a system to absorb every conversation and invent new rules, but by giving people better evidence about where authors, readers, and institutions are getting stuck.
Moving beyond a singular automation strategy requires a structured maturity model. Publishers benefit from a gradual transformation framework that assesses workflow readiness, ensuring that automation supports rather than dilutes editorial authority. By treating AI as a ‘constant companion’ for human experts, identifying potential discrepancies while leaving final interpretation to the specialist, publishers build resilience against the inherent ambiguities of the publishing lifecycle.
The measures should follow the same logic. A short handling time means little if the author returns with the same problem. Publishers should watch repeat contact, unnecessary transfers, automated answers overturned during review, time taken to reach the correct owner, and how often users must supply information the organization already possesses.
Efficiency matters, but only after the answer is correct and the path to it is defensible.
The author began with seven words.
The answer may have taken seconds, or it may have required a specialist. Either can represent excellent support. What matters is that the system understood the difference before it replied.
SVP, Advanced Digital Solutions
