Computer-Use AI Agents: How I Charge $2,800 to Kill Back-Office Data Entry

Every automation project I sold in 2024 and 2025 had the same ceiling: if a client's system had no API, I walked away. That ceiling is gone. Computer-use agents — models that see a screen, move a cursor, type into fields and read what comes back — now handle the ugly, API-less corners of a business well enough to bill for. This is the exact offer I sell, what it costs me to run, where it fails, and the numbers from the last four projects.

Why computer-use agents changed what I can sell

The old automation pitch was narrow. I could connect apps that published clean APIs, and I priced those builds at $900 to $2,500 because the work was mostly plumbing. The jobs clients actually complained about were different: a bookkeeper re-typing 200 supplier invoices into a desktop accounting app, an ops assistant copying shipment rows from a freight portal that has no export button, a clinic manager transferring insurance claim numbers between two web systems that will never talk to each other.

Those jobs share three properties, and all three are why they stayed manual for years. There is no integration to buy. The work is high volume but low judgment. And the cost of an error is visible — a wrong invoice number gets caught, so nobody trusts a black box.

A computer-use agent solves the first property and forces me to engineer around the third. It operates the same screen a person operates, so the missing API stops mattering. What replaces the API contract is a written procedure, a bounded set of allowed actions, and a log of every step the agent took. That log is the product. Clients are not paying me for the model; they are paying for a process they can audit on Monday morning.

The offer, in one sentence

I sell a bounded back-office run: one repetitive screen-based task, documented, automated with a computer-use agent, monitored, with a human review queue for anything the agent is not certain about.

Pricing has settled into three numbers after some painful early guesses.

The $600 teardown is the piece I would not skip again. My first two projects, I quoted a build straight from a discovery call and lost roughly 14 hours on a portal that logged out every four minutes and blocked the automation with a device check. Now the teardown either produces a build I have already proven on 20 records, or it produces a written no with the money already collected.

What actually gets automated

Four projects since the spring, all in the $2,800 band:

• Freight ops, 3PL broker. Pulling shipment status from a carrier portal with no export, into their Google Sheet tracker. 180–240 rows a day, previously 2.5 hours of a coordinator's morning.
• Bookkeeping, small accounting firm. Reading supplier invoice PDFs and entering header data into a desktop ledger app. 40–70 invoices a day during month-end.
• Insurance intake, physiotherapy clinic. Copying claim numbers and authorisation dates between an insurer web portal and their practice management system. About 60 records a day.
• Marketplace pricing, homeware seller. Checking competitor prices on a marketplace that rate-limits scrapers but tolerates human-speed browsing, writing results to a pricing sheet. 300 SKUs, twice a week.

Notice what is missing. Nothing involves negotiating, deciding, replying to a customer, or moving money. Every one of these tasks has a checkable output: a row either matches the source screen or it does not. That constraint is not modesty, it is what makes the work insurable and the accuracy report meaningful.

The build process, day by day

Day one: record the human doing it

I ask for a screen recording of the task being done at normal speed, plus a second recording of the person narrating what they are checking. The narration recording is where the real requirements live. In the freight project, the coordinator said, almost in passing, "if it says in transit but the date is older than two days I flag it to Dana." That single sentence became a routing rule the client never would have written into a brief.

From the recordings I write a numbered procedure — usually 15 to 30 steps — in plain language, and send it back for corrections. Clients correct it, every time, and those corrections are free compared to discovering them mid-build.

Day two: one step, proven

I automate the smallest useful slice first: log in, navigate to the list, read the first row. Nothing else. Then I run it 20 times and look at the failure pattern. Portals fail in boring, repeatable ways — a session timeout, a cookie banner that appears only on the first visit of the day, a table that lazy-loads after 900ms. Twenty runs surfaces almost all of it.

Day three and four: the full path plus the confidence gate

Now the whole procedure runs. The engineering that matters here is not the agent prompt, it is the confidence gate. Every record the agent produces gets one of three outcomes:

1. Confident and verified — the value the agent typed matches what it reads back from the screen after saving. Auto-approved.
2. Uncertain — a field was ambiguous, blank, or the read-back did not match. Goes to the review queue with a screenshot.
3. Blocked — login failed, page structure changed, or the record hit a rule the procedure does not cover. Stops the run and pings me.

I target 10% or less of records landing in the review queue by week two. Above that, the client is doing enough manual work that the value story collapses.

Day five: handover and the boring documents

The handover session is 45 minutes with the person whose job the task used to be. I show them the review queue, the run log, and the stop button. That last one matters more than anything technical I show them: the whole meeting relaxes once they know they can halt the thing.

They also get a one-page runbook: what the schedule is, what an alert looks like, who to call, and explicitly which credentials the agent uses. Which brings me to the part most people building this skip.

Permissions, credentials and the rules I do not break

A computer-use agent logs in as somebody. Treat that casually and you will eventually have an incident that ends the client relationship.

• Its own account, always. Named something like automation-ops, with the narrowest role the target system allows. Never a staff member's login, never a shared admin account.
• Read-only wherever possible. Two of the four projects only read from the source system and write to a sheet the client owns. That halves the risk surface.
• No payment, no messaging, no deletion. Written into the contract as excluded actions, not just avoided in practice.
• Credentials in a vault the client controls. I use their password manager's shared vault with a rotation date, so revoking my access does not break the automation.
• Every run logged with screenshots for 30 days. Two clients have already used those logs to settle an internal dispute about who entered a wrong figure. Neither dispute involved the agent, which is exactly why the logs earned their keep.

I also check the target system's terms before quoting. The marketplace pricing project got a green light because the client's own account and human-speed browsing were within acceptable use; a different prospect's request against a competitor's login-walled portal got a flat no. Saying no in writing, with a reason, has never cost me a deal I wanted.

The economics, honestly

Per single-task build at $2,800, my time is typically 16 to 22 hours across the five days, including the teardown work if it converts. Direct costs are small but not zero:

• Model usage for computer-use runs: $0.06 to $0.22 per record depending on how many screens each record touches. The freight job at 200 records a day runs about $18 daily, billed through to the client at cost plus a flat operations fee.
• A hosted browser environment with persistent sessions: $39/month per client.
• Monitoring and alerting: rolled into tooling I already pay for, about $60/month total across all clients.

The monthly retainer is where this becomes a business rather than a series of projects. Target UIs change — a portal redesign broke the freight job for six hours in June — and the retainer is what makes fixing that a scheduled task instead of an emergency argument about scope. Across four clients the recurring line is currently $3,900/month, against roughly six hours of monthly work when nothing is on fire.

What still goes wrong

I would be selling you something dishonest if I stopped at the numbers.

Long forms drift. Anything past roughly 12 fields on a single screen, the agent's accuracy drops enough that the review queue stops being cheap. I now split long forms into stages with a read-back after each stage, which costs more per record but keeps errors visible.

Popups you never saw in testing. Maintenance banners, satisfaction surveys, forced password rotations. The fix is not smarter prompting, it is a dismissal step that handles unknown overlays and a hard stop if the expected element is missing after two attempts.

Clients want to expand the scope quietly. "While it's in there, could it also…" Every expansion is a new task with its own teardown. Holding that line is the difference between a $700 retainer and unpaid support.

Speed disappoints people. Agents operate at roughly human pace, sometimes slower. The win is that it runs at 6am, unattended, every day, not that it runs fast. I say that on the sales call now, before someone imagines instant.

The stack I actually use

People expect a long list. It is four things, and I have replaced two of them once each.

The agent layer. A computer-use capable model driving a real browser session. I care about three properties only: does it reliably read a table without hallucinating a cell, does it produce a step log I can replay, and does it stop rather than guess when an element is missing. I test candidates on the same 20-record freight sample and compare review-queue rates. The winner changes; the test does not.

A hosted browser with persistent sessions. Running locally works for the demo and fails for production, because production means 6am runs on a machine nobody has closed the lid on. A hosted browser environment with saved cookies and a fixed egress address also keeps portals from treating every run as a suspicious new device.

An orchestrator for schedule, retries and the review queue. I use n8n, mostly because clients can look at the canvas and understand what happens in what order. It handles the schedule, the two-attempt retry, writing the run log, and pushing uncertain records into the queue with their screenshot attached.

The client's own sheet or app as the destination. I deliberately do not build a custom dashboard. Output goes where the team already looks. Every hour I would spend on a UI is better spent lowering the review-queue rate.

How I measure accuracy without guessing

At the end of week one on a live task, I hand-check a random 50 records against their source screens and record three numbers: auto-approved and correct, auto-approved and wrong, and sent to review. The middle number is the only one that can kill the project, so it is the one on the monthly report in bold. Across the four live tasks it currently sits between 0 and 2 records per thousand, and each of those came from a source screen that was itself ambiguous — a supplier invoice with two different dates and no label saying which was the invoice date. I show clients those cases individually rather than averaging them away, and that habit has renewed more retainers than any performance chart.

How to get the first client this month

The demo does the selling, so build one before you pitch. Pick a public, boring system — a government business registry lookup, a shipping tracking page — and record a 90-second run: agent logs in or opens the page, reads 10 records, writes them to a sheet, one record goes to the review queue with a screenshot. That last beat is what makes buyers lean in.

Then go where the complaint already exists. My four clients came from: a bookkeepers' Facebook group where someone was venting about month-end typing, a freight forwarding subreddit thread, one referral, and a cold email to a clinic that had posted a job ad for a part-time data entry assistant. That job ad is the highest-intent signal on the internet for this offer. Someone budgeting $1,600 a month for typing is pre-qualified.

The email that works is four sentences: I saw the ad, here is a 90-second video of an agent doing that exact type of work, here is what the review queue looks like when it is unsure, would a $600 teardown on your real process be useful before you hire. No deck, no discovery call request.

What I would do differently starting over

Charge for the teardown from day one. Refuse tasks with more than a dozen fields per screen until you have a stage-and-verify pattern working. Write the excluded-actions list into the contract before the first build, not after a nervous client asks. And keep the review queue visible in the client's own workspace rather than a dashboard only you log into — the day they can see the agent being honest about uncertainty is the day the retainer stops being questioned.

The opportunity here is not that agents got clever. It is that a huge amount of paid human work is still someone reading one screen and typing into another, and for the first time that work can be done by software without anyone building an integration first.