Drop-in-ish, not drop-in
Operationally this can be made to feel almost identical to what is there now. Walk up, press a button, scan, walk away, and a searchable PDF arrives where it is expected. Nobody using it needs to know what is underneath. But "almost" is doing real work in that sentence, and the places where it is doing that work are worth naming out loud.
The user-facing promise
Press the button. Walk away. The PDF is where you expect it.
That is the bar, and it was set by the software already installed. Anything that asks the person at the machine to learn something new, log in differently, or wait for a confirmation screen has broken the promise — no matter how much better the engineering behind it is. The entire value of the change lives on the other side of that button, invisible.
Line by line
Two of those differences are better and three are simply different. The three that are simply different — where the images travel, what happens when the internet is down, and how it is licensed — are not engineering problems. They are conversations with people who are entitled to an answer, and they are much easier to have early than late.
The panel experience is a second project
Proper embedded buttons on the Sharp panel, the person's identity picked up from their badge, a destination chosen at the glass — all of that is what a commercial product eventually needs, and none of it is what a proof of concept needs.
For the question we are actually asking, a scan-to-folder workflow or a light agent is enough. It answers "does the device let go, and does adding capacity help" without spending weeks on integration work that would have to be redone anyway.
The risk in that shortcut is real and worth stating: a proof of concept that works beautifully through a watched folder tells you nothing about whether the embedded version is achievable. That is why finding out how close we can get to the embedded experience is a test in its own right rather than something to discover afterwards.
Scan to a folder. Measure the device. Measure the queue. A few weeks, cheap, and it answers the only question that currently matters.
Embedded buttons, identity, destination selection, administration, support, licensing. Substantially more work, and only worth starting once the first question has a yes.
And then, later, the part people get excited about
Once documents are flowing through something that can think about them, a set of things become available that were awkward before. We are putting these last deliberately, because they are the easiest thing to talk about and the wrong thing to build first.
It names the file properly
Not "SCAN_20260827_0014.pdf". The client, the date, the document type, in whatever convention you already use. This is the change most people notice first, because it is the one that saves them from renaming things.
It knows what the document is
Invoice, contract, ID, correspondence, signed authority. Classification is a solved problem now in a way it was not five years ago, and it is the difference between a folder of PDFs and a filing system.
It files itself to the right place
Straight to the matter, the job, the client folder — without a person choosing from a dropdown at the panel. This is the one with the largest prize and the largest chance of getting it subtly wrong, which is why it comes last.
Why these come second. A platform sold on classification has to be right about the classification, and being wrong is visible and embarrassing. A platform sold on "the scanner is free again" has to be right about one measurable thing. Win the boring argument first, then the interesting one is a much easier conversation to have.
The three tests →