A freelance IT technician we worked with was spending around an hour of every working day doing something that earned nothing: scrolling Field Nation for jobs worth taking. Field Nation is one of the largest marketplaces for IT and field-service work in the US, with over a million work orders completed a year by its own count. That volume is the opportunity, and it is also the problem. Most listings are too far away, pay too little, or are fixed-price jobs that do not suit. Finding the few that fit meant opening listing after listing, every few hours.
So we built a job search automation bot. It opens Field Nation, reads every work order on the page, keeps only hourly jobs within 5 miles paying at least $20 an hour, and opens those in their own browser tabs. The technician reads a shortlist instead of a marketplace. The build took one to two weeks.
It is a deliberately simple first version, and this case study is honest about its limits. But the pattern underneath it, read listings, apply your rules, surface only the matches, is the same pattern behind job-finding for almost any role on almost any job board, for one person or a whole team. That is the part worth reading for.
| Metric | Result |
|---|---|
| Rules applied to every listing | Within 5 miles, hourly pay of $20 or more, hourly jobs only |
| What the technician sees | Only qualifying work orders, each opened in its own tab |
| Build time | One to two weeks |
| Searching time saved, estimated | About 208 hours a year for one technician on one platform |
| Value of that time, estimated | About $6,000 a year at a typical IT support wage |
| Who decides which jobs to take | The technician, always. The bot never accepts work |
Why Finding Work Is the Hidden Cost of Freelance Field Service
For a freelance technician, time spent searching is time not spent billing. And on a busy marketplace, searching is not a one-off task. It is a habit that repeats all day.
Field Nation's own help documents explain why. When a company publishes a work order, technicians request it and the company chooses who to assign. When a company routes a work order to several technicians, the first one to accept is assigned. So checking often matters, and that turns into checking constantly: open the list, scan the distances, open the promising ones, check the pay, close most of them, repeat in two hours.
None of that needs a technician's skills. It needs rules applied consistently, which is exactly what software is good at.
What We Built: A Rules-Based Job Filter
The bot is a short Python script using Selenium, an open-source tool that drives a real Chrome browser the way a person would.
- 01Open Field Nation
Launches Chrome with the technician's own logged-in profile and loads the work orders page.
- 02Read every listing
Pulls the distance and the pay from each work order on the page.
- 03Apply the rules
Keeps hourly jobs within 5 miles paying at least $20 an hour. Skips fixed-price jobs.
- 04Open the matches
Opens each qualifying job in its own tab, ready for the technician to read.
- 05The technician decides
Reads the shortlist and requests the jobs worth taking. The bot never accepts work.
The bot opens the Field Nation work orders page and reads each listing's distance and pay. Fixed-price jobs are skipped. Hourly jobs more than 5 miles away or paying under 20 dollars an hour are skipped. Jobs that pass both rules are opened in a new tab for the technician, who decides which to request. The bot never accepts work.
Three design choices are worth explaining.
It uses the technician's own logged-in browser. The bot opens Chrome with the technician's existing profile, so it sees exactly what they would see. No separate login, no stored password in the script.
The rules are just settings. Maximum distance and minimum pay sit at the top of the script as two numbers. Change 5 miles to 15, or $20 to $35, and the bot follows the new rules. Adding more rules (job type, required certification, client rating) follows the same shape.
It stops before the decision. The bot surfaces jobs. It never requests, accepts or messages anyone. Taking work is a commitment to a client, and that stays with a person.
Here is how the rules play out on a typical page:
| Example work order | Distance | Pay | Result |
|---|---|---|---|
| Network troubleshooting | 2 miles | $25 an hour | Opened |
| Printer installation | 4 miles | $20 an hour | Opened |
| Server maintenance | 7 miles | $45 an hour | Skipped: too far |
| Cable installation | 3 miles | $18 an hour | Skipped: pay too low |
| Router replacement | 1 mile | $150 fixed | Skipped: not hourly |
These are illustrative listings, not real work orders.
Human Hours vs Automation: What Searching Costs Each Way
The fair comparison is not "automation versus nothing." It is automation against the technician doing it by hand, which is what happens every day without it. Here is that comparison, with every assumption stated so you can swap in your own.
The assumptions.
- Searching by hand: checking the marketplace about 6 times a working day at around 10 minutes a time, so 60 minutes a day. We show 30 and 90 minutes as the light and heavy cases.
- With the bot: the search itself takes seconds. The technician still reads the shortlist, which we put at 10 minutes a day.
- Working year: 250 days.
- Value of an hour: $29.01, the US median wage for computer user support specialists from the Bureau of Labor Statistics (May 2024, $60,340 a year divided by 2,080 hours). For a freelancer this is the value of an hour that could have been billed or rested, not a salary anyone pays.
For one technician on one platform:
| Case | Searching by hand, per year | Value of that time | With the bot, per year | Value of that time |
|---|---|---|---|---|
| Light (30 min a day) | 125 hours | ~$3,600 | ~42 hours | ~$1,200 |
| Typical (60 min a day) | 250 hours | ~$7,250 | ~42 hours | ~$1,200 |
| Heavy (90 min a day) | 375 hours | ~$10,900 | ~42 hours | ~$1,200 |
In the typical case that is about 208 hours a year handed back, worth roughly $6,000. That is more than five full working weeks.
Why scale changes everything. Manual searching grows in a straight line: every extra platform and every extra person adds the same hour a day again. The bot does not. Adding a platform adds a little review time, because there are more matches to read, not another hour of scrolling. Adding a person adds a rule set, not a searcher.
| Scale | Searching by hand, per year | Value of that time | Bot plus human review, per year | Value of that time |
|---|---|---|---|---|
| 1 technician, 1 platform | 250 hours | ~$7,250 | ~42 hours | ~$1,200 |
| 1 technician, 3 platforms | 750 hours | ~$21,750 | ~63 hours (15 min a day) | ~$1,800 |
| 10 technicians, 1 platform | 2,500 hours | ~$72,500 | ~417 hours | ~$12,100 |
| 10 technicians, 3 platforms | 7,500 hours | ~$217,600 | ~625 hours | ~$18,100 |
What the bot costs on the other side. The build is a one-off, and a focused version like this fits our fixed-scope pilot, from $5,000. It also needs occasional maintenance when the job board changes its pages, which belongs in the budget: hours a year, not weeks. At one technician on one platform, the time saved pays for the build within the first year. For a dispatch team of ten, it pays back within weeks.
What the numbers leave out. Speed. On routed work orders the first technician to accept is assigned, so a match surfaced in minutes instead of hours can be the difference between getting a job and missing it. We have not put a number on that, because it depends on the market. But it is often the bigger win.
These are estimates, not measurements. Run your own figures through our hire versus automate calculator, and see how much automation can save a business for the wider method.
Built to Adapt: The Same Pattern for Any Role
Strip away Field Nation and the bot has three parts. Only two of them change from one job to another.
- Where the listings come from: a marketplace, a job board, a shift app, a load board.
- The rules: distance, pay, skills, hours, client rating, whatever decides "worth my time" for that role.
- What happens with a match: open it, send an alert, add it to a shortlist, route it to the right person.
The engine in the middle, read every listing and apply the rules consistently, stays the same.
| Role | Typical listing source | Rules that matter | Best action on a match |
|---|---|---|---|
| Field and IT technicians | Field service marketplaces | Distance, hourly rate, certifications | Open the listing, alert by phone |
| Freelance specialists | Freelance project marketplaces | Budget, skills, client history | Add to a daily shortlist |
| Per-diem healthcare staff | Shift-booking apps | Facility, shift time, rate | Instant alert, because shifts go fast |
| Owner-operator drivers | Freight load boards | Lane, rate per mile, pickup location | Instant alert |
| Recruiters and sourcers | Job boards and company career pages | Role, seniority, location | Digest for the recruiter |
| Dispatch teams | Several platforms at once | A rule set per person | Route each match to the right person |
These are illustrations of how the pattern adapts, not builds we are claiming for each role. Each platform has its own terms and its own technical quirks, which is exactly why the first question on any new source is the one below.
Door or Window: The Question That Decides Every Version
Before automating any job board, check whether it offers a proper door: an official API, a saved-search alert, or a notification feature. Field Nation, for example, publishes an Integration and API Agreement for programmatic access, though it is aimed at the companies posting work rather than the technicians finding it. If a platform offers a door that fits your side of the marketplace, use it. It is stable, supported and survives redesigns.
Our version one used the window: a browser that reads the page like a person does. That works, and sometimes it is the only option, but it is more fragile by nature. If the platform moves a column or renames a field, the bot can find nothing until someone updates it. We cover this trade-off in our 90-second systems access test, and it is the same choice we faced getting documents out of a secure email portal in our Egress automation case study.
Two more rules apply whatever the route. Read the platform's terms before automating anything on it, and keep the automation to the reading and filtering a person could do themselves. And never let a bot accept work, message clients or submit requests at scale. Speed is the benefit. Automated commitments are the risk.
What Version One Taught Us
A case study that only lists wins is an advert. This is a simple script, and here is where it shows.
It reads the page as it looks today. If Field Nation changes its layout, it can find nothing until someone updates it.
But the script closes the browser a few seconds later. Version two should keep the shortlist, not just show it.
Text like 'less than 1 mile' or '$20.00 / hour' can trip a simple parser. Real listings are messier than test ones.
Fixed pauses are a guess. The script waits five seconds for the page to load. On a slow connection that is not enough, and on a fast one it is wasted. Version two should wait for the listings to actually appear.
Real text is messier than test text. A parser expecting "3 miles" or "$25/hr" can stumble on "less than 1 mile," "$20.00 / hour" or a listing with no pay shown. Each of those should be handled, not skipped silently.
Showing is not keeping. The bot opens matches in tabs, then closes the browser a few seconds later. A shortlist that disappears is half a feature. The next version should save matches to a list or send them as an alert.
Setup was tied to one computer. The paths to Chrome and the browser profile were written for the technician's own machine. That is fine for one person and a blocker for a team. Scaling means moving those settings out of the code.
None of these are surprises. They are the normal gap between a version that proves the idea and one that runs unattended, and they are why the roadmap below exists.
How It Scales: From One Laptop to a Team
- 01Version 1: the script
One person, one platform, run by hand, matches opened in tabs.
- 02Version 2: make it sturdy
Proper waits instead of fixed pauses, tolerant parsing, a saved shortlist, an alert if the page changes.
- 03Version 3: run on its own
Checks on a schedule and sends a phone or email alert the moment a match appears.
- 04Version 4: more platforms
One rule set applied across several job boards, using official alerts or APIs wherever they exist.
- 05Version 5: a team
Rules per person, matches routed to whoever fits, with a log of what was found and taken.
Listings come from one or more platforms, through official APIs or alerts where they exist and browser automation where they do not. One matching engine applies a separate rule set for each person. Matches are saved to a shortlist and sent as alerts to the right person, who decides whether to take the job.
The important thing about this path is what does not change. The rules stay as plain settings. The decision stays with a person. What grows is coverage (more platforms), reach (more people) and reliability (monitoring, so a broken page is noticed in minutes, not days).
That is also the difference between this and a no-code recipe. A quick drag-and-drop automation can check one feed for one person. Once you need several sources, a rule set per person, a saved history and an alert when a source breaks, you need the engine built properly, which is where our custom AI automation development work starts.
Is This Kind of Automation Right for You?
It is a good fit if:
- You or your team check the same job sources several times a day.
- Your idea of a "good job" can be written as rules: distance, rate, skills, timing.
- Speed matters, because the best listings go to whoever responds first.
- You work across more than one platform, or manage more than one person's search.
It is not worth building if you check one source once a day, or the platform's own saved searches and alerts already do the job. In that case, use them. Our guide to AI agents for business automation covers when rules are enough and when a task needs AI judgement, and RPA vs AI agents explains where browser automation like this fits.
The Competitor Pulse Check
| Factor | How we approached it | A typical approach |
|---|---|---|
| Who decides | The bot shortlists, the person chooses | Bots that auto-accept work and risk the account |
| Rules | Plain settings anyone can change | Logic buried in code or a vendor's black box |
| Data route | Official API or alert first, browser automation only where needed | Scraping by default |
| Honesty about limits | Fragility and parsing gaps stated upfront | A demo on a good day |
| Growth path | Same engine, more sources and more people | Start again for each new platform |
| The business case | Human hours against automation, assumptions shown | "Saves time," with no numbers |
Frequently Asked Questions
Can you automate finding jobs on Field Nation?
Yes. In this project a script read Field Nation's work orders, kept hourly jobs within 5 miles paying at least $20 an hour, and opened only those for the technician to review. Check Field Nation's terms first, prefer its official notifications or API where they fit, and keep the decision to request or accept work with a person.
How much time does job search automation save?
In our estimate, a technician checking a marketplace for about an hour a day spends around 250 hours a year searching. With a bot doing the filtering and the technician spending about 10 minutes a day on the shortlist, that falls to around 42 hours, saving roughly 208 hours, worth about $6,000 a year at a typical IT support wage.
Can the same bot work for other jobs and job boards?
Yes. The engine reads listings and applies rules, and only the source and the rules change between roles. The same pattern can filter freelance projects by budget and skills, healthcare shifts by facility and rate, or freight loads by lane and rate per mile, subject to each platform's terms and technical setup.
Is it safe to use a bot on a job marketplace?
It is safest when the bot only reads and filters what you could see yourself, runs through your own logged-in account at a normal pace, and never accepts work, messages clients or submits requests automatically. Read the platform's terms before you start, and use its official API or alerts where they exist.
What does a job-finder automation cost?
A focused version like this one fits our fixed-scope pilot, from $5,000, and needs occasional maintenance when the job board changes its pages. For one technician the time saved typically covers the build within the first year. For a team checking several platforms, the payback is far faster.
Why not just use the platform's own alerts?
If the platform's saved searches and alerts already apply your rules, use them. A custom bot earns its place when you need rules the platform does not offer, several platforms combined into one shortlist, or different rules for different people on a team.
Want This for Your Team?
If you or your team spend part of every day hunting through the same job boards, we can tell you in one call whether it is worth automating, which route fits each platform, and what it would save. Book a free strategy call and bring the rules you already search by. Or see how we build AI automation solutions around one measurable workflow at a time.