Some of the most valuable automation is unglamorous. A supply-chain and distribution company in Jamaica imports goods that need veterinary import permits from the Ministry of Agriculture. Its staff prepared and filed those applications on the ministry's online portal, again and again, typing data that already existed in the company's own shipping system. Then they checked the portal for results and filed the granted permits back into their records.
We were asked to automate it. This case study explains how we did it, the safeguards we built, and why we deliberately did not let AI fill in the forms.
The problem
- Repetitive data entry. Each application repeated information already held in the company's purchase-order and permit systems: vendors, goods, quantities, countries.
- History was the best guide. Most new applications closely matched past permits for the same vendor and goods, but staff had to look those up by hand.
- Waiting and checking. After filing, someone had to log in and check each application's status until it was granted.
- Closing the loop. Granted permits had to be downloaded and stored against the right purchase orders.
- Zero tolerance for mistakes. These are official applications. A wrong field is worse than a slow one.
Our approach: four lanes
We designed the system as four lanes, each simple on its own.
1. Push: company data to the cloud
The company's main system runs on SQL Server. A scheduled job copies the purchase orders that need a veterinary permit, plus the history of past permits and how they mapped to purchase orders, into a cloud PostgreSQL database. The connection to SQL Server for this lane is read-only. Batches are incremental, so each run only moves what changed.
2. File: drafts from history, filled with verification
On the dashboard, an operator opens a purchase order and builds a draft. The draft is derived from previous permits for the same vendor or matching goods, and records which permits it came from. Only purchase orders backed by a prior matching permit are eligible; the rest are not filed automatically.
A worker then fills the portal form with deterministic browser automation. After filling, every field is read back from the portal and compared with the draft. Any mismatch stops the job before submission. Submission also requires two separate switches to be on: a global setting and a per-job permission. A pre-submit check looks for recent duplicate applications, and a full-page screenshot is captured right before any real submit. When an application is submitted, the confirmation number is read and stored.
The portal's product catalogue is remembered between filings, and country names are matched to the portal's own spelling. If something unknown appears, the job stops with a clear reason rather than guessing.
3. Status: checking the portal so people do not have to
A scheduler checks the portal every few hours for applications in each status (submitted, payable, on hold, rejected, deliverable, delivered) and searches each open application by number. Changes are recorded as events. When a permit is delivered, its documents are downloaded automatically.
4. Return: permits back into the company's own system
An hourly job on the company side pulls results back. Granted permits, with their numbers and PDFs, are saved and promoted into the company's own permit records, linked to the right purchase orders, so they appear on the screens staff already use.
The company can also queue a filing directly from its own system with a stored procedure, which goes through the same eligibility checks.
Where we used AI, and where we did not
The project is often described as "AI automation", and AI does play a part: it helps read and classify historical documents and match materials to the right categories, work that is tedious for people and tolerant of review.
But we tested AI-driven form filling, and it was not consistent enough for official applications. So the filling is deterministic: the same input always produces the same form. We think this is the most important lesson of the project. Use AI where its mistakes can be caught cheaply, and use plain, predictable code where they cannot.
Visibility and alerts
A dashboard shows every filing with its field values, success or failure, error messages, manual steps a person took and the screenshots captured along the way. The team receives an email digest when new problems appear, such as a failed filing or a blocked login, and a notice if a scheduled job itself fails.
Going live carefully
Moving to production was planned like a migration: a full, verified backup of the production database first, every database change written to be safe to re-run with a matching undo script, and live filing and automatic filing left off until the client says go. Historical data extracted during testing was carried into production so the system starts with full context.
The stack
- Next.js and TypeScript for the dashboard.
- Node.js for the sync, request and result jobs on the company side.
- PostgreSQL in the cloud; SQL Server on the company side.
- Playwright for browser automation.
- Docker on a dedicated, monitored server.
What the client gets
- Drafts built from the company's own permit history instead of retyped by hand.
- Every field verified against the portal before any submission.
- Status checks and document downloads without anyone logging in.
- Granted permits back in the company's own system, linked to purchase orders.
- One dashboard and email alerts for everything that needs attention.
- A design that can extend to other government portals the company deals with.
Lessons for anyone automating forms
- Start from the data you already have. The best automation removes retyping.
- Use history. Past successful applications are the best template for new ones.
- Verify before you submit. Read back what you filled and compare.
- Gate the irreversible step twice. Submissions should need deliberate permission.
- Close the loop. Automation that files but does not bring results back only moves the work.
- Be honest about AI. Use it where errors are cheap to catch.
Is your process a good candidate for automation?
Not every repetitive task is worth automating. These questions help decide:
- Is the data already somewhere? If staff copy information from one system into another, automation can remove the copying.
- Is the process stable? A form that changes every month is expensive to automate.
- Are there clear rules? If an experienced person can explain how they decide each field, software can follow the same rules.
- How often does it happen? A task done weekly by several people adds up; a task done twice a year rarely justifies the work.
- What does a mistake cost? High-stakes tasks can still be automated, but need verification, approval steps and a clear record, as in this project.
- Can results come back? The biggest savings come when the whole loop is automated, not just the first step.
If most answers are yes, a short discovery phase can map the process and estimate the savings before any building starts.
Why we planned the rollout so carefully
Official filings cannot be undone easily. Planning the move to production in small, reversible steps means the client can switch each part on when they are confident it works.
Need something similar?
If your team retypes data into portals, spreadsheets or other systems every week, it may be a good candidate for automation. See our custom web app service, read what custom software costs, or tell us about the forms you fill.
Frequently asked questions
Only with safeguards. Our system reads back every field from the portal and compares it with the draft before submitting, needs two separate switches on before any real submission, checks for recent duplicates and captures a screenshot right before submitting. The client decides when live filing is switched on.
We tested AI-driven form filling and it was not consistent enough for official applications. The filling is deterministic browser automation. AI is used where it is reliable, such as reading historical documents.
The pattern does: sync data, build drafts from history, fill with verification, poll for status and return results. Each portal needs its own mapping and testing.
If you fill in the same forms repeatedly with data you already have, it is often a good candidate. Start with a discovery call to map the forms, data and rules.
