How we would prove it, or fail to
Three tests. Each has a stated way to pass and a stated way to fail, written down now so that nobody gets to move the goalposts later — including us.
The Sharp lets go immediately
Does a 200-page searchable-PDF job return the device to an idle, ready state in essentially the same time as the same 200 pages scanned with no OCR at all?
The gap between the two is small enough that nobody standing at the machine could tell them apart.
The device is still held while the OCR runs. If this fails, nothing else on this page matters and we should say so plainly.
Why it is on the list — This is the specific complaint. Everything else is secondary to it.
Adding capacity actually helps
Throw four 200-page jobs in at once. With one worker, the backlog behaves the way it does today. Does adding workers materially cut the time until the last document lands?
Four workers clear the same burst in a fraction of the wall-clock time, and the curve is roughly the shape you would expect.
A shared bottleneck somewhere — storage, licensing, a single-threaded step — means more workers do not help. Better to find that now than after a proposal.
Why it is on the list — Elastic capacity is the only real advantage on offer. If it does not materialise, the honest answer is a bigger server.
The Sharp integration is not the wall
How close can we actually get to the embedded experience — and how much of the gap is effort versus a hard limit of what the device will let us do?
We can describe, with confidence, exactly what a production integration involves and roughly what it costs.
The panel experience cannot be reached without a partnership or an SDK we do not have. That is a commercial problem, not a technical one, and it changes the plan.
Why it is on the list — A technically perfect back end behind a worse front end is a product nobody adopts.
Four measurements that cost nothing
None of these need a proof of concept, a developer, or a purchase order. They need one afternoon and a willingness to write things down. If they come back saying the device already releases immediately, we have saved everybody a great deal of time and the conversation moves somewhere more useful.
A stopwatch and a person. Do it three times with OCR on and three times with OCR off, same document.
File creation timestamp, minus the start time written down.
Four people, four devices, one countdown. Slightly silly, entirely conclusive.
CPU on the capture server. If it sits at one core while everything queues, that is the whole story in one screenshot.
What would make us say stop
A discovery exercise that cannot conclude "do nothing" is not a discovery exercise, it is a sales process with extra steps. Any one of these would be a good enough reason to close the file, and we would rather find them now.
- The device turns out to already release immediately today — in which case the complaint is about time-to-document, not availability, and the fix is different.
- Large jobs are rare enough that the peak never actually bites.
- The images cannot leave the building, and the economics of running the same architecture on-premises are no better than a bigger capture server.
- The embedded Sharp experience turns out to be unreachable for us, and the scan-to-folder compromise is not good enough for real users.