AI vs human task completion speed: measuring real-world workflow times

Last month I needed to process 500 inbound leads from a web form and enrich each with LinkedIn data before sending a cold‑email sequence. Doing it manually would have taken my assistant two full days, and even then the data would be stale by the time we hit send. I decided to test how fast an AI‑driven automation could finish the same job compared to a human.

Human baseline: measuring manual speed

I asked my assistant to open each lead, copy the name and company, search LinkedIn, pull the current title and location, and paste that into a Google Sheet. We tracked the start and end time with a simple Toggl timer. The assistant worked in bursts of 20 minutes, taking short breaks to avoid fatigue.

After processing 120 leads, the timer showed 3 hours and 12 minutes. Extrapolating to 500 leads gave an estimated 13 hours and 40 minutes of pure work time. That’s roughly 1.6 minutes per lead when you include the inevitable context‑switching overhead.

One thing that slowed us down was the need to re‑authenticate to LinkedIn every 45 minutes because of session limits. That added about 8 minutes per cycle, which the assistant found frustrating.

AI baseline: measuring automated speed

For the AI test I built a simple workflow in Make (formerly Integromat) that watches a Google Sheet for new rows, calls the OpenAI API with a prompt to fetch LinkedIn data via a public scraping API, and writes the results back to the sheet. I used GPT‑4‑turbo as the language model because it handles the short reasoning step well.

The workflow ran unattended. I started the timer when the first lead appeared in the sheet and stopped it when the last row was updated. The total elapsed time was 22 minutes and 45 seconds for 500 leads.

That works out to about 2.7 seconds per lead, a speed‑up of roughly 35× over the manual baseline. The AI never needed a break, never hit a session limit, and the data stayed fresh because the scrape happened instantly.

What most guides get wrong about timing

Many tutorials compare AI and human speed by looking only at the raw processing time of the model. They ignore the overhead of moving data in and out of the system, the latency of API calls, and the time spent handling errors. In our test, the actual GPT‑4 call took about 400 milliseconds per lead, but the surrounding Make.com modules added another 1.8 seconds each.

If you only quote the model’s inference speed you’ll end up with an unrealistically optimistic number. Real‑world speed includes the glue that holds the pieces together, and that glue can be the bottleneck.

Why does AI stall on edge cases?

When the LinkedIn scraping API returned a captcha or a rate‑limit error, the workflow halted because I hadn’t built any retry logic. The AI itself was fine; it was the external service that caused the stall. In a human workflow, the assistant would simply try a different search phrase or wait a minute and try again.

This highlights a common misconception: AI is fast only when the surrounding services are reliable. If you depend on a flaky third‑party API, the overall task completion speed can drop to human levels or worse.

Concrete example: using Make.com + GPT-4 for lead enrichment

Here’s the exact prompt I fed to GPT‑4‑turbo:

Given the name “{{Name}}” and company “{{Company}}”, return the current LinkedIn headline and location in JSON format: {“headline”: “…”, “location”: “…”}. If you cannot find a reliable answer, return {“headline”: “unknown”, “location”: “”}.

I stored this prompt in a Make.com text module and mapped the incoming sheet columns to the placeholders. The module returned JSON, which I then parsed with a Make.com JSON parser to split the headline and location into separate columns.

The cost for this run was negligible: OpenAI charged $0.006 per 1K tokens, and each call used about 300 tokens, so the total API cost was under $1. Make.com’s core plan runs at $29 per month, which I find fair for the automation depth you get.

What I actually love about Make.com is its ability to chain multiple AI calls without hitting a timeout, which saved me hours when I later added a second step to generate personalized email lines.

The biggest annoyance I hit was Zapier automations’s 5‑minute polling delay on the free tier, which made real‑time enrichment impossible when I first tried a similar workflow there. Switching to Make.com eliminated that lag because its instant trigger fires as soon as a sheet row changes.

How to debug when this breaks

When the workflow stops updating the sheet, follow these steps:

1. Check the Make.com scenario log for the module that failed. Look for error messages like “HTTP 429” or “Timeout”.
2. If you see a 429, open the OpenAI usage dashboard and verify you haven’t exceeded your rate limit; consider adding a delay module between calls.
3. If the error is from the scraping API, add a retry module with exponential backoff and a max of three attempts.
4. After fixing the error, run a manual test with a single row to confirm the data flows correctly.
5. Finally, enable email notifications for scenario failures so you catch issues before they affect a batch.

These steps cut my mean time to recovery from about 20 minutes to under 3 minutes.

Price‑to‑value take

For a solo operator handling a few hundred leads per week, the $29/mo Make.com plan plus a modest OpenAI bill delivers a 30× speed‑up for less than the cost of one hour of assistant time. If you only need occasional enrichment, the free tier of Make.com (with its 1‑minute polling interval) might be enough, but you’ll lose the real‑time edge.

I think GPT‑4‑turbo is overpriced for simple data extraction tasks like this; a smaller model such as GPT‑3.5‑turbo would cut the API cost by 70% with virtually no loss in accuracy for this use case.

Adjacent reading: deeper coverage of AI agent platforms.

If you’d rather skip the build and deploy a working version in an afternoon, we’ve packaged this workflow as a blueprint at deepusecase.com/vault.