Measuring the value
Searching a scanned drawing set: 171 pages recognised in 338 seconds, and the paging hours that come back
In a drawing set, a scanned page yields nothing to Ctrl+F; looking up a mark means paging. Once every scanned page is recognised into text — text pages and scans counted separately, an interrupted run resuming where it stopped — how many hours a month does an estimator get back, and does the largest set even finish?
How many hours a month does an image-only drawing set cost an estimator?
All it needs is the sets per month, the pages in a set, the share of pages that are scans and an hourly cost. Lookups, the time to page through every scan and today's hours follow from those. Everything is editable.
Derived from the four numbers above
Assumptions — open to see and edit each one
Lookups
Sheet index
To subtract
An estimate, not a promise. The share read correctly is the assumption every line stands on: set it to 0 and A and B go to zero, leaving only the subtraction. An honest model has to be able to do that.
A design set reaches an estimator as a PDF of a few hundred pages, and a good share of those pages are scanned images: signed and stamped sheets photographed again, or old prints scanned for the archive. On those pages Ctrl+F finds nothing. To learn where the footing concrete grade is written, what section column C1 has, or which sheet carries the note on cover, people page through.
This piece asks: if every scanned page were recognised into text and searchable like any other page, how many hours a month would an engineer get back? And a question that comes first: does the recognition finish the whole set at all?
1. What changes
When a drawing set is uploaded, the machine separates the two kinds of page and counts them separately: pages with their own text (read straight from the file) and pages that are scanned images (which have to be recognised). The status line speaks for the whole file, for example "312 pages: 267 with their own text, 45 scanned — 45 recognised in 58 seconds". It used to say only "45 pages recognised", which readers took to mean the machine had stopped at page 45.
Then:
- Every scanned page is recognised, Vietnamese and English, on the server's CPU. Each search hit from a scanned page is marked "OCR" with its confidence, so the user knows to look at the drawing before trusting it.
- Sheet number and title read from a scanned title block go into the drawing index, as for pages with text.
- An interrupted run does not start over. Results are saved every 10 pages, so a rerun reads only the missing pages. Tested: stopped at page 30 of the 171-page set, the rerun read only the remaining 141.
- Big sets upload in 8 MB pieces. The delivery network in front of the server refuses any request over 100 MB and the browser shows nothing: a 117 MB set once crawled at 5 KB/s for 18 minutes. Now a piece that hits a network error is sent again on its own, and sending it again never creates a duplicate file.
2. The question that comes first: does it finish?
Recognising one scanned A3 page takes between 1 and 53 seconds on its own. A 171-page set, measured on a development machine with 6 processes in parallel: 338 seconds, about 2 seconds a page.
On the real server — 4 cores, shared with other systems — the same set at first did not finish: it stopped at a 300-second limit. The measured cause: 6 processes running at once, each opening one thread per core, so 24 threads fighting over 4 cores. Once each process was held to one thread and the parallel count set to cores minus one, the same 171 pages on that same machine finished in 352 seconds.
That matters more than any number below. A set that never finishes recognition is not "slower to search" — nothing in it can be found, and every task that needs to look something up in it stops or goes back to paging by hand. The calculator below counts only the hours on sets that did finish; the work that stops entirely is not in it, so the total is a floor.
3. First stream: lookups on scanned pages
A word on a page with its own text is found with the search box today. On a scanned page it has to be paged to, and on average it turns up halfway. Once scans carry text, the share read correctly moves onto the search step; the share read wrongly still has to be paged to. The chart above is exactly this arithmetic: the shaded area between the two curves is the minutes saved per lookup.
How to measure it. For one week, every time you have to find something in a drawing set, make a mark and time it. Count separately the lookups that ended on a page with text and on a scan. Measure the share read correctly on your own set: take 20 words whose position you know, search each, count how many land on the right page.
How far to trust it: fair. Lookups and seconds per page differ a lot between someone who knows the set and someone opening it for the first time. The share read correctly depends on the scan — skewed, blurred, or with a red stamp across the text, it drops sharply.
4. Second stream: the drawing index
How to measure it. Next time you build a drawing index, time it over 20 scanned sheets. Then count on the tool how many sheets came out with the right number and needed no correction.
How far to trust it: fair. Every design office has its own title block; an unfamiliar one is read correctly less often.
5. To subtract: waiting and checking
Recognising a 171-page set takes about 6 minutes on the server, in the background, with no AI model fees — this part uses text-recognition software on the CPU. The user still spends time: waiting, rechecking pages flagged as failed, pressing run again. Count 10 minutes a set: 4 × 10 ÷ 60 ≈ 0.7 hours a month.
6. Adding it up
| Stream | Hours/month | Money/month (VND 80,000/h) |
|---|---|---|
| Lookups on scanned pages | 8.9 | 0.71 m |
| Drawing index | 2.2 | 0.18 m |
| Waiting and checking | −0.7 | −0.05 m |
| Given back | 10.4 | 0.83 m |
About 10 hours a month, close to VND 10 million a year at the salary in the example, for an engineer reading 4 sets a month. Today lookups and the index on those sets take about 16.5 hours.
Counted once. Those 10 hours are money or capacity to take on more sets, never both. And as section 2 said, the figure leaves out the sets in which nobody can look anything up today.
7. What this ROI stands on
The share of words read correctly. It sits under both streams. Set it to 0 in the calculator: lookups and the index go to zero and only the subtraction is left. On the sample set in the screenshot, clear print came out at 96% confidence; on real scans, handwriting, text under a stamp, or rebar notation such as Ø is often read wrongly. That is why every hit from a scanned page is marked "OCR" with its confidence — a reminder to look at the drawing, not decoration.
Not found does not mean not there. A word the machine misread will not show up in the hits. For things where missing one costs money — a material note, a detail that contradicts the plan — the engineer still has to know the set; the tool shortens the way to the page, it does not replace the reading.
Lookups per set is the number easiest to overstate. Measure a week before you believe 60.
8. Measuring it in your own company
- Take a baseline. Pick a set you are working on. Count scanned pages against all pages; for a week, log lookups and minutes per lookup; time the index over 20 scanned sheets.
- Run the same set on the tool. Note the recognition time, the failed pages, and the share read correctly on 20 words whose position you know.
- Compare like with like. A structural set full of rebar notation differs from an architectural set full of words; compare structural with structural.
9. What to remember
A page you cannot search is a page you read again by eye every time you need it. Recognition does not make anyone read drawings faster — it makes getting to the right page cost nothing. And before counting savings, ask a blunter question: does your largest set actually finish?
A drawing set that cannot be searched is not slower — it stops.
The recognition times (338 seconds for 171 pages on a development machine, 352 seconds on a 4-core server), the stop at the 300-second limit before the fix, the 312-page set with 267 text pages and 45 scans, and the 117 MB set uploading at 5 KB/s were measured on the Xây dựng G20 tool with real design sets, anonymised. The screenshot comes from a sample project. Sets per month, share of scans, lookups, seconds per page, share read correctly and salary are illustrative. Replace them with your own.
Read next
-
Never invoice twice: ask the accounting ledger before creating — 199 of 209 invoices were already there
When invoicing moves from the accounting package into the ERP, there is a stretch when both create invoices. If the ERP asks the accounting ledger before it creates one, how many duplicates does a cutover avoid — and what is each duplicate you never clean up worth?
-
Sharing an estimate by one link: what the mailed-Excel loop costs, and "which version is the latest?"
An estimate passes through 2–4 people as Excel files sent by mail, so someone always asks "which version is the latest?". When the whole set — drawings, quantity table, where every number comes from — sits behind one shared project, with people invited by email or sent a view-only link that needs no account, how many hours a month does the review loop get back?
-
Invoicing at the original PO price: the delivery note says 21,000, the chain's PO says 30,000
A retail chain pays the price on its own PO, not the price on the supplier's delivery note. When a machine reads the PO price, invoices at it when the gap is plausible and corrects the price list for next time, what is that worth a month — and which lines still need a person?