Case study/Automation
Doubling data-entry throughput with a custom recognition tool
unicrew automated a manual data-entry bottleneck with a C# and AWS recognition tool, doubling the data sets the team got through each month.
A software company had to fill huge product databases, and the only way to do it was datasheets typed in by hand by internal operators. unicrew built a data-recognition tool that reads the documents, sorts the data, and hands it to an operator to release or correct: twice the data sets per month, from a manual baseline of about 5,000. The engagement ran under our former Artelogic brand.
- Focus
- Automation
- Market
Germany- Engagement
- Custom automation tool build
- Stack
C#
AWS
Outcome at a glance
What this project delivered, in numbers.
- 2xData sets processed per monthfrom about 5,000 a month, two operators typing by hand
The challenge
The client, a software company in Munich, Germany, had to add huge product databases to its products, and those databases could only be filled by datasheets its internal operators typed in by hand. They wanted to automate that so more data could go in at once. The work called for a different programming language from the one their own products use, so it sat outside their product team.
Our approach
The client brought the idea. unicrew did the research and built the tool from scratch as their automation partner, finding ways to improve the document-recognition rate along the way. The backend is C# on AWS microservices, picked for this kind of processing, and unicrew brought the AWS side from its cloud services practice. Two weeks passed between the first call and the start of the project in September 2020.
unicrew also did some UI. The tool presents its first results, and the operator releases them or corrects them before they land in the database. Those corrections update the algorithm, so the recognition rate keeps improving as the tool is used. The interface began as a rough version put together by a developer, enough to prove the component worked, and a UI/UX designer reworked it once it had. Work ran on Jira and Confluence.
Results
The client’s goal was to semi-automate an internal process and reach twice the speed of the manual one. That is what the tool did.
- Data-set throughput doubled: about 5,000 a month with two operators typing by hand, twice that with the tool.
- The client could then put those people on different product types and have more accurate data at the same time.
- A scientific internal project with an uncertain goal became a working internal tool, extended over four or five iterations.
C# automation turns up in other shapes here: our report automation for a culture-analytics company automates Word and PowerPoint report generation. What clients say about working with us is collected on our client reviews page.
“We can raise any technical issue with them and find someone within their team to work with that specific technology.”
CEO, Software Development Company (Germany)
What the client says
Two people typing data into the database went about 5,000 new data sets per month. With this component, we’re reaching twice the amount of data sets per month. Their knowledge of different technologies is astounding. We can raise any technical issue with them and find someone within their team to work with that specific technology.
04/Technologies
Technologies on this project
Backend
- C#
Cloud
- AWS
05/Quick answers
The questions behind the project
What did unicrew build to replace the manual data entry?
A data-recognition tool, built from scratch. It reads documents, sorts the data into the database table, and presents the first results to an operator, who releases them or corrects them before they go in. unicrew did some UI as well as the backend. The corrections are not thrown away: they update the algorithm, so the recognition rate keeps improving as the tool is used.
How much did the automation actually improve throughput?
It doubled it. Two operators typing by hand got through about 5,000 new data sets a month; with the tool, the client reached twice that. Volume was not the only gain. With those people off manual entry, the client could put them on different product types and have more accurate data at the same time.
Why was this built in C# on AWS?
The backend is C# on AWS microservices, picked for this kind of document processing. It also matched the shape of the work: the automation needed a different programming language from the one the client's own products use, so it sat outside their product team and went to a partner already working in that stack. unicrew brought the AWS side from its cloud services practice.
How did unicrew run the project day to day?
The client brought the idea, unicrew did the research, and the build started two weeks after the first call. A proof of concept came first, since nobody knew at the outset whether the goal was reachable, and the rough developer-built interface was handed to a UI/UX designer once the component had proved itself. Work ran on Jira and Confluence, and the tool went through four or five iterations, extended each time to make it more usable.