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.
How would it know it was Marg?
Four tiers, and only the last needs a developer. Whatever the machine emits — a login name, a user number, an email address — is only a token; it still has to resolve against something that already knows who Marg is, which in practice means the directory you already run.
| Tier | What the person sees | What it takes | Identity you get |
|---|---|---|---|
| 0 Watched folder | Nothing changes at the machine | No panel work at all | Identity from the folder path |
| 1 A button per person | Their own name on the scan screen | Configuration only — an address-book entry and a home-screen shortcut each | Implied by which button was pressed |
| 2 Real identity, still no custom code | They badge or PIN in, then press scan | Authentication turned on — internal PIN, card reader, or AD/LDAP — then scan to home folder | An actual account, resolved from the directory |
| 3 Embedded application | Proper buttons, index prompts, destination picker | Sharp OSA — the module on the device and a developer agreement with Sharp | Full user context |
All a proof of concept needs. Proves the architecture without touching Sharp integration.
Genuinely trivial and works on the fleet today. Breaks down socially rather than technically: at forty people the screen is pages of buttons, and every joiner and leaver is an admin task.
The tier people miss. If anyone logs in at the machine today, this is mostly already there.
The only tier with a commercial dependency rather than an engineering one. This is what Test 03 exists to find out about.
Identity and the queue are separate problems. The whole architecture can be proven at tier zero, with no identity work at all. It would be a shame to hold up finding out whether the Sharp lets go over a question that can be answered later and independently.
And where does the file actually go?
All of these are reachable. The question is not which is possible but which one you already use.
Do not change the destination
Write to exactly the folder and naming convention in use today. Change the architecture or the destination, not both — otherwise there is nothing to compare against, and every downstream habit breaks while trying to prove something unrelated to it.
Getting the document back inside
If OCR runs off site, the images leave on the way out and the finished PDF has to come back in — either through a small on-premises agent that writes to the existing share, or by moving the destination somewhere cloud-native. Worth deciding deliberately rather than discovering halfway through.
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 →