How a Global B2B Demand-Generation Company Reduced Database Retrieval from 2–3 Hours to 10 Seconds with an RPA Assistant

October 1, 2026 11 min read

Project snapshot

Area	Details
Client	A global B2B demand-generation company processing large volumes of company and lead data
NDA	All company, project, infrastructure, system, and internal database names are anonymized
Users	10⁠–⁠15 internal users
Main service	Robotic Process Automation (RPA)
Supporting service	Workflow Optimization & Consulting
Process	Database retrieval, bulk data extraction, field selection, normalization, and export
Initial delivery	Two-week sprint
Project timeline	Initial development in January, refactoring in March, performance tuning in May
Technology	UiPath Assistant, UiPath Orchestrator, database, CSV, Excel
Data tables	LinkedIn, ZoomInfo, and Yahoo Finance company-data tables
Key result	About 5,000 domains processed in 10 seconds instead of 2⁠–⁠3 hours
Performance gain	Approximately 800× faster

Short answer

The company depended on technical specialists for routine database requests. Each request had to be reviewed, scheduled into a sprint, translated into a database query, exported, normalized, formatted, and returned to the requester.

We built an RPA DB Assistant that gave authorized users predictable, on-demand access to the most common database retrieval operations. The initial version was delivered within a two-week sprint. After the March refactoring and May performance tuning, the bot processed a 5,000-domain request in about 10 seconds instead of 2⁠–⁠3 hours.

The result was an approximately 800× faster process, up to 2⁠–⁠3 human hours avoided per routine request, and significantly lower dependency on the development team.

The client

The client is a global B2B demand-generation company that processes large volumes of company and lead data.

Several internal teams regularly need structured information from company-data tables. Depending on the request, users may need to retrieve company records by domain or prooflink, select specific attributes, count matching database records, generate a random sample, or export a subset of data for further operational use.

The data is stored across several database tables containing information collected from sources such as LinkedIn, ZoomInfo, and Yahoo Finance.

The problem was not a lack of data. It was that operational access to this data still required direct involvement from technical specialists.

The challenge

Before automation, a routine request followed this process:

1. A business user submitted a database request.
2. The request was reviewed and added to sprint planning.
3. A developer or technical specialist clarified the required filters and fields.
4. The specialist manually prepared the database query.
5. Data was retrieved from one or several tables.
6. Results were exported into separate files.
7. The files were manually formatted and normalized.
8. The final output was sent to the requester.

A typical request required an average of 2⁠–⁠3 hours of specialist work.

The actual query execution was only part of the effort. Time was also spent on request interpretation, filter preparation, field selection, output structuring, data normalization, and final delivery.

This created several delivery issues.

Operational requests competed with product and automation development tasks during sprint planning, and technical specialists repeatedly performed similar retrieval operations instead of focusing on development work.

Also, business users could not receive results immediately, even when the request followed an already known pattern.

The process was especially inefficient for large input files. A request containing thousands of domains could still require hours of preparation and manual output processing.

Discovery and scope definition

We treated this as an operational workflow issue rather than a database issue.

The objective was clear: remove repeatable database retrieval work from the development queue without giving users unrestricted database access.

During the initial analysis, we identified several recurring request types:

• Retrieve records using predefined filters.
• Process an input file containing domains or prooflinks.
• Return only selected fields.
• Count matching database records.
• Generate a random sample.
• Export results into CSV or Excel.
• Create a structured output folder and provide clear execution status.

The first release focused on these repetitive patterns. Custom analytical requests and database changes remained outside the automated scope and continued to require technical review.

This kept the solution controlled while covering the operations that generated most of the repetitive work.

The solution

We built a hotkey-driven RPA DB Assistant in UiPath Assistant.

The bot acts as a managed data-retrieval workbench. Users can trigger predefined operations without writing database queries or working directly with database structures.

The implemented operating model includes:

• F2 – Generic Query Retrieval: retrieves data from the LinkedIn, ZoomInfo, or Yahoo Finance database tables and exports the result to CSV.
• F3 – Retrieval by Input File: accepts domains or prooflinks from an input file and returns matching records in CSV or Excel.
• Alt+F2 – Information Request: performs database record counts and generates random samples.

The bot also creates the required output directories, opens the result folder, and reports execution status. These functions are documented as the core operating model of the RPA DB Assistant.

Solution structure

Solution block	What we implemented	Operational result
User interaction	Hotkey-driven UiPath Assistant workflow	Users can run managed operations without database knowledge
Generic database retrieval	Defined queries across three company-data tables	Replaced repeated manual query preparation
Bulk file processing	Domain and prooflink retrieval from CSV or Excel input	Enabled large requests to run as one automated operation
Selected-field processing	Logic for returning only the required fields	Faster performance by skipping unnecessary processing
Count and sampling utilities	Automated database count and random-sample functions	Removed technical involvement from routine validation requests
Output standardization	Automatic CSV and Excel generation	Most manual formatting and normalization was eliminated
Folder management	Automatic creation and opening of output folders	Consistent result delivery
Execution reporting	Status reporting through the UiPath environment	Improved visibility into completion and failures

Implementation process

We delivered the solution in three defined stages.

January – initial development

The first working version was delivered within a two-week sprint.

The initial scope covered the main retrieval scenarios and provided the first self-service interface for users. The priority was to remove the routine request flow from manual sprint-based execution as quickly as possible.

March – refactoring

After the first period of use, we refactored the solution.

The main objectives were:

• Simplify the internal workflow structure.
• Improve maintainability.
• Standardize the interaction with different database tables.
• Improve filter and field-processing logic.
• Prepare the bot for larger input volumes.
• Reduce the effort required to add new fields or retrieval scenarios.

We did not treat the refactoring as a separate rebuild. It was based on the behavior of the initial version and the actual operational requests received after launch.

May – performance tuning

The final stage focused on high-volume processing.

The main bottleneck was the selected-field processing logic. Large requests could contain thousands of records, while users normally required only a specific subset of fields.

We introduced a new selected-fields processing class and tuned the algorithm using large database volumes.

Following the tuning:

• The complete 5,000-domain use case ran in 10 seconds.
• The most complex selected-fields component required four seconds.
• The algorithm remained stable on high-volume requests.

This phased approach allowed us to deliver business value quickly, then improve the architecture and performance based on real usage rather than assumptions.

Technology stack

Layer	Technology	Purpose
User interface	UiPath Assistant	Hotkey-driven workflow launch
Automation	UiPath	Retrieval, file processing, normalization, and export
Orchestration	UiPath Orchestrator	Deployment, package management, and execution status
Database	Company database	Storage and retrieval of company information
Data table	LinkedIn database table	Company and profile-related information
Data table	ZoomInfo database table	Company and firmographic information
Data table	Yahoo Finance database table	Public-company and financial information
Input	CSV and Excel	Domain and prooflink lists
Output	CSV and Excel	Structured result delivery

Results

Metric	Before	After	Result
Processing time for the tested 5,000-domain request	2⁠–⁠3 hours	10 seconds	Approximately 800× faster
Human effort per routine request	2⁠–⁠3 specialist hours	Limited to launch and result review	Up to 2⁠–⁠3 hours avoided per request
Processing throughput	Manual request preparation and export	5,000 domains in 10 seconds	About 500 domains per second in the tested scenario
Complex selected-fields processing	Depended on manual query and export structure	4 seconds	Stable high-volume processing
Request intake	Required planning into a sprint	Available on demand	Routine requests removed from the development queue
User coverage	Dependent on technical specialists	10⁠–⁠15 users supported	Controlled self-service access
Output preparation	Separate exports and manual normalization	Standardized CSV or Excel output	Manual output preparation largely removed
Data-source coverage	Separate manual work per source	Three supported database tables	One consistent user workflow

The comparison between 2⁠–⁠3 hours and 10 seconds represents a calculated range of between 720× and 1,080×. We use a rounded figure of approximately 800× faster.

Monthly and annual labor savings were not calculated because the number of requests per month was not available. The confirmed saving is therefore presented per request rather than extrapolated.

Want to see which requests could run this way in your team? Book a free process review.

Technical and delivery challenges

Large-volume field processing

The most significant technical challenge was processing large result sets while returning only the fields requested by the user.

The first implementation worked for standard volumes but required optimization for larger files and more complex field combinations.

We addressed this through the March refactoring and the new selected-fields processing class introduced during the May tuning stage. The most complex part of the algorithm was reduced to four seconds.

Different database structures

The LinkedIn, ZoomInfo, and Yahoo Finance tables contain different structures and field sets.

A direct implementation for each source would have created three separate solutions and increased maintenance effort. Instead, we separated source-specific retrieval logic from shared processing, export, directory-management, and status-reporting components.

Controlled access

The automation needed to reduce developer dependency without exposing unrestricted database access.

The hotkey-driven model solved this by giving users access only to supported retrieval operations. Query logic, connection handling, and database-specific processing remained within the automation.

Operational impact

The main result was not only faster query execution.

The project changed the ownership model of the process.

Before the implementation, standardized data retrieval was treated as development work. After implementation, it became an operational capability.

This produced three direct benefits:

• Developers stopped spending several hours on retrieval and export requests.
• Users received results without waiting for sprint planning.
• The company gained a reusable structure for adding new tables, fields, and consistent retrieval scenarios.

The solution also improved delivery predictability. Routine requests no longer depended on the current sprint workload or the availability of a specific technical specialist.

What this means for similar businesses

This approach is relevant for companies that already have centralized data but still depend on developers for routine access.

Typical indicators are:

• Standardized exports are submitted as development tickets.
• Engineers repeatedly prepare similar database queries.
• Users send domain, company, ID, or prooflink lists for enrichment.
• Results require manual CSV or Excel preparation.
• Query execution is fast, but the complete request takes hours.
• Operational work regularly interrupts planned development.

Rather than automating every possible database request, the correct starting point is to identify recurring request patterns, define input and output formats, and automate only the operations that can be executed consistently.

In this project, the first usable version was delivered in two weeks. Refactoring and performance tuning were then completed based on real production use and large-volume testing.

How 2BBooster supports similar projects

For similar data-access and internal automation projects, the delivery approach includes:

1. Mapping the existing request and approval process.
2. Measuring the real manual effort per request.
3. Separating repeatable operations from custom analytical work.
4. Defining managed access scenarios.
5. Building the first operational version around the highest-volume use cases.
6. Testing the solution using real production-size files.
7. Refactoring based on actual usage.
8. Adding monitoring, structured output, and support ownership.

Relevant services:

• Robotic Process Automation (RPA)
• Workflow Optimization & Consulting

FAQ

How long did the project take?

The initial working version was delivered within a two-week sprint.

Did users need direct database access?

No. Users worked through predefined UiPath Assistant functions. Database access and query logic remained inside the defined automation.

What operations were automated?

The bot supported generic query retrieval, processing by domain or prooflink input file, selected-field extraction, database record counting, random sampling, and CSV or Excel export.

How many users worked with the bot?

10⁠–⁠15 internal users had access to the supported retrieval functions.

How did the bot perform on large requests?

In the confirmed test scenario, about 5,000 domains were processed in 10 seconds. The most complex selected-fields processing component required four seconds.

Did the solution remove the need for technical specialists?

It removed technical involvement from standardized retrieval requests. Custom analysis, new database structures, and unsupported request types still required technical review.

Conclusion

The DB Assistant converted a sprint-dependent technical request into a controlled self-service process.

The first version was delivered in two weeks. Refactoring and performance tuning then prepared the solution for large-volume production use.

For the confirmed 5,000-domain scenario, processing time dropped from 2⁠–⁠3 hours to 10 seconds. This represents an approximate 800× improvement and up to 2⁠–⁠3 hours of specialist effort avoided per routine request.

The final result was faster data access, lower development dependency, consistent outputs, and a maintainable structure that could be extended as new operational scenarios appeared.

No need to route standard database requests through development

If your team still sends routine database exports, data lookups, enrichment requests, or reporting tasks through sprint planning, there is usually a clear automation opportunity.

We can map the current request flow, identify which operations are repeatable, and define what a consistent self-service layer could look like around your existing databases and tools.

Book a free process review to identify which database requests can be removed from your development queue first.