Process automation · client work
Bulk Transaction Automation — From Manual Back-Office Work to a Controlled Operation
Desktop automation that turns repetitive, one-by-one work in a web-based business system into a controlled bulk run: an Excel operation list, an authorized session, result checks, and an execution log.
- Developed by
- TankDev
- Project type
- Client work · process automation
- Field
- Back-office operations · bulk transactions
- Input
- Excel operation list
- Environment
- Existing web-based business system
- Core capabilities
- Browser automation · execution · result tracking · logging
- Platform
- Desktop application
- Technologies
- Python · browser automation · Excel
- Status
- Operational automation project
Verifiable scope
These items describe scope, not speed or success rate. No verified duration or success percentage has been published.
Problem and operational context
Some web-based business systems have no bulk action. Certain operations have to be completed one record at a time in the user interface. A short single action does not make hundreds or thousands of repetitions short. For each record someone opens the screen, fills the fields, submits, checks the result, and moves to the next row. At volume, that repetition is the back-office day.
Project constraints
Replacing the existing system was not a precondition. Where the product has no bulk action and no matching API, the work stays on the screens an authorized user already uses. The operation list can arrive as Excel. Not every row succeeds. An unexpected screen or validation can stop that row. Failed rows have to be separated from the rest, and the operator has to see which rows were processed. If the run stops, the operation must not disappear without a trace. Retry, rollback, and a distributed queue are not described here, because they are not part of this project.
What TankDev built
TankDev built a desktop application that runs the repeated back-office operation. The user loads the rows in Excel. The application reads that list and takes the rows in the given order. It works through the authorized user’s existing session in the target web system and does not grant access the user did not already have. Steps run automatically within that application’s response time and screen flow. Each result is tracked, successful and failed rows are separated, and the outcomes are written to a log. The operator sees the bulk-run summary in the desktop application. Authentication mechanics are not published.
Bulk operation flow
- Excel operation list
- Desktop control application
- Ordered operation list
- Authorized user session
- Browser automation
- Web business system
- Result check
Outputs
- Successful
- Failed / skipped
Both outcomes are written to the execution log, which the user reads as the result report. The ordered list is the application’s processing sequence, not a separate message queue.
Before and after
Before · one record at a time
- 01Open the operation list
- 02Find the record
- 03Open the screen
- 04Complete the action by hand
- 05Check the result
- 06Move to the next record
- 07Repeat for hundreds or thousands of rows
After · one controlled run
- 01Load the Excel operation list
- 02Start the authorized session
- 03Run the automation
- 04Execute the rows in order
- 05Check the results
- 06Separate successful and failed rows
- 07Execution log and result report
Result tracking
The operator can see which row was processed. Success and failure are recorded. Rows that error are separated from the rest. The run is written to a log, and the summary stays in the desktop application. Automatic retry, checkpoint recovery, and a transaction guarantee are outside this scope.
Why this is not a simple bot
The point is not an automatic click. The system takes an operation list, keeps the rows in order, runs the action in the existing application, tracks the result, separates failures, logs the work, and shows the summary. The problem is not browser automation by itself. It is running a high-volume repetition as a controlled operation. Financial data processing is a different job: that case extracts and transforms files. This one executes actions in the system the user already has.
Measurable effect
No duration or success rate has been published. There is no speed multiple, no hours saved, and no perfect-success claim. The scope that can be stated is this: high-volume repetition runs as a batch, manual screen work is reduced, successful and failed rows are separated, history is logged, and the same operation can be repeated as one flow.
Security and limits
The system is designed to work inside the access an authorized user already has. Automation does not create a permission that user was not given. The target system’s access policy, terms, and operational limits stay in place. Authentication and user data are not described in this case study.
Related capabilities
Running a similar manual operation?
Record entry and other back-office actions repeated hundreds of times in a web system can be standardized with controlled process automation.
Tell us about the projectProcess Automation