Stop Reading CVs First: Build a Paid-Test Queue

By Lazar Milicevic · Published August 2, 2026 · 9 min read

Applications pile up in your inbox. CVs, rate expectations, availability, portfolio links—some in the email body, some in attachments you forget to open. A strong candidate gets a reply four days late. By the time you circle back, you're comparing inconsistent notes scribbled across three spreadsheet tabs. Here's exactly how I built a workflow that turns that mess into a structured paid-test queue, with every hiring decision staying human.

The One Constraint That Makes This Safe

AI can summarize an application, but it cannot validate whether a person can do the specific work your business needs. That constraint is what makes this workflow useful instead of risky. You are not building an AI recruiter. You are removing the repetitive admin work between an applicant hitting send and a human deciding whether that person deserves a paid test.

For a founder or small agency, the process usually breaks in the same place every time. Applications sit in Gmail. Someone copies details into a spreadsheet when they remember. Rates and availability are buried in attachments. The final decision gets made from inconsistent notes instead of comparable facts. The fix is not a new applicant tracking system—it is a narrow extraction step with a human gate at the end.

I built this exact pattern into a lead-gen agency tool (bizflowai.io-Catalyst) and a Gmail-Telegram bot ecosystem (UNA_Intel). The same architecture applies whether you are processing 10 applications a week or 200.

One Inbox, One Label, One Queue

Do not start with a giant ATS if your process is currently Gmail, a spreadsheet, and calendar reminders. The first thing I build is one intake path.

Create a dedicated hiring address (e.g., roles@yourcompany.com), or apply a Gmail filter that labels inbound applications as Hiring/Inbound. Every application must enter through one predictable route.

• Form applications → route the form notification to that same label
• Email referrals → forward them there
• Direct applications → use the dedicated address

One queue means the automation has one job. No branching logic based on source channel, no special-case handling. If it touches the Hiring/Inbound label, it goes through the same pipeline.

Here is the Gmail filter setup I use:

Matches: (to:roles@yourcompany.com OR subject:application OR subject:applying)
Do this: Apply label "Hiring/Inbound", Skip Inbox, Mark as unread

That filter catches direct applications and most form notifications. For referrals from team members, I ask them to forward to the dedicated address rather than CC it—forwarding preserves the original message structure, which matters for attachment parsing downstream.

Define the Six Fields You Actually Compare

Before connecting AI, write down the facts you need for a first review. For a typical contractor or developer role, I use six:

1. Role — what position they are applying for
2. Relevant experience — years, stack, or domain, stated in their words
3. Proposed rate — hourly or project, with currency
4. Availability — hours per week or start date
5. Portfolio link — GitHub, Figma, Behance, personal site
6. Role-specific answer — one screening question baked into the application instructions

Your list will differ. A designer might need a Figma link and timezone. A customer-support contractor might need language coverage and shift availability. Do not ask the model to produce a vague candidate score. Ask it to collect facts you can compare side by side.

The candidate record stores those six fields plus metadata:

candidate_record = {
    "sender_email": "jane@example.com",
    "received_date": "2026-08-02T09:14:00Z",
    "gmail_thread_id": "18f3a9c2b1d4e5f6",
    "application_status": "new",  # new | waiting_for_details | rejected | invited_to_test
    "audit_log": [
        {"timestamp": "2026-08-02T09:14:00Z", "action": "created", "actor": "system"},
    ],
    "extracted": {
        "role": "...",
        "experience": "...",
        "rate": "...",
        "availability": "...",
        "portfolio_url": "...",
        "role_question_answer": "..."
    }
}

That record can live in a database, a spreadsheet for an early version, or your existing CRM. The tool is not the point. The fields and the state changes are what make this reliable.

The Extraction Step: Narrow Instructions, Not Recommendations

The workflow reads the email body and any supported attachment text (.txt, .pdf, .docx), then sends it to an AI extraction step. The instruction is deliberately narrow.

Here is the extraction prompt I use, in plain English:

Extract the applicant's role, relevant experience, rate, availability,
portfolio URL, and response to the role question. Return valid JSON.

For every field, include the exact source sentence from the application.
If the evidence is absent, return "missing".

Do not rank, reject, or recommend this candidate.

That last line matters. The model is acting as an operations assistant, not the hiring manager. Most quick AI workflows fail here—they ask for a recommendation, get a polished answer, and mistake polished language for reliable output.

The JSON schema I enforce:

{
  "role": {
    "value": "Backend Developer",
    "source_sentence": "I am applying for the backend developer position listed on your site."
  },
  "experience": {
    "value": "6 years, Python and Django",
    "source_sentence": "I have 6 years of experience building APIs in Python and Django."
  },
  "rate": {
    "value": "$45/hr",
    "source_sentence": "My rate is $45 per hour."
  },
  "availability": {
    "value": "missing",
    "source_sentence": null
  },
  "portfolio_url": {
    "value": "https://github.com/janedoe",
    "source_sentence": "Portfolio: https://github.com/janedoe"
  },
  "role_question_answer": {
    "value": "missing",
    "source_sentence": null
  }
}

Every field includes the source sentence. If the evidence is absent, the value is "missing". No inference, no paraphrasing. The source sentence is the audit trail—if you need to verify what the model extracted, you can read the exact words the candidate wrote.

I use a temperature of 0 for this step. You want deterministic extraction, not creative interpretation. On Claude (Sonnet tier), extraction costs roughly $0.004 per application including attachment parsing. On GPT-4o-mini, it is under $0.001. Both handle structured extraction reliably at these prompt sizes.

Validation: Catch Missing Fields Before They Reach a Human

Before anything reaches a human reviewer, the workflow checks for missing fields. If the role, portfolio, rate, or availability comes back as "missing", the automation does not silently reject the applicant. It creates a draft reply in the original Gmail thread asking for the missing information.

Hi Jane,

Thanks for your application. I have your role (Backend Developer) and 
portfolio (github.com/janedoe), but I did not see your rate and 
availability in the email. Could you confirm:

- Your hourly or project rate
- Your weekly availability and earliest start date

Once I have those, I will get you into the review queue.

— Lazar

The draft is pre-written and partially filled from extracted fields. It does not send automatically. Someone can check the draft for tone and accuracy in under five seconds, then hit send. This protects you from extraction errors and prevents the system from negotiating with candidates on your behalf.

The validation logic is simple:

required_fields = ["role", "experience", "rate", "availability", "portfolio_url"]
missing = [f for f in required_fields if extracted[f]["value"] == "missing"]

if missing:
    draft = build_clarification_email(
        thread_id=candidate["gmail_thread_id"],
        found_fields=extracted,
        missing_fields=missing
    )
    candidate["application_status"] = "waiting_for_details"
    # Draft saved in Gmail, not sent
else:
    send_to_telegram_queue(candidate)

This is where you catch the candidate who wrote a great cover letter but forgot to mention their rate. Without this gate, they sit in your inbox until you manually follow up—or until they take another contract.

The Telegram Approval Gate: Three Buttons, One Decision

For complete applications, the automation sends a compact summary to a private Telegram approval queue. The message contains only what the decision-maker needs.

📋 New Application

Name: Jane Doe
Role: Backend Developer
Experience: 6 years, Python/Django
Rate: $45/hr
Availability: 20 hrs/week, starts Aug 15
Portfolio: github.com/janedoe
Role Answer: "I would build the API with Django REST Framework and add rate limiting via Redis..."

🔗 Open in Gmail

Under the summary, three inline buttons: Request clarification, Reject, and Invite to paid test. This is the single human gate.

• Request clarification → updates status to waiting_for_details, opens the prewritten Gmail draft
• Reject → logs who made the decision and when (audit trail), optionally prepares a polite rejection draft (I recommend keeping rejection sends manual until you have reviewed enough real cases)
• Invite to paid test → sends the paid-test invite email template, updates status, logs the decision

A founder can review ten normalized summaries much faster than opening ten emails, downloading ten PDFs, and trying to remember who said what. But the founder still sees the original application before choosing an outcome. AI organizes evidence; a human makes the decision.

Telegram Setup Details

• Create a private Telegram group with only the people who make hiring decisions
• Use a bot token with inline keyboard support
• Set a retention policy that matches your local privacy requirements (delete messages after 30 days, or export to your compliance system)
• Keep the full CV in Gmail or your controlled storage—the Telegram summary is deliberately compact

The bot callback handler is straightforward:

@app.route("/telegram/webhook", methods=["POST"])
def telegram_webhook():
    callback = request.json["callback_query"]
    action = callback["data"]  # "clarify" | "reject" | "invite"
    thread_id = callback["data"]["thread_id"]
    decision_maker = callback["from"]["username"]
    
    log_decision(thread_id, action, decision_maker, timestamp=now())
    update_candidate_status(thread_id, action)
    
    if action == "invite":
        send_paid_test_email(thread_id)
    elif action == "clarify":
        open_clarification_draft(thread_id)
    elif action == "reject":
        prepare_rejection_draft(thread_id)  # Manual send

Every decision is logged with the decision-maker's identity and timestamp. You build an audit trail for free.

What This System Does Not Do

This workflow does not rank candidates. It does not assign scores. It does not auto-reject based on keywords. It does not send emails without a human reviewing the draft (except the paid-test invite, which you can automate once you trust the template).

The system normalizes data so a human can compare apples to apples. That is the entire value proposition. If you let the model start making recommendations, you have built an AI recruiter—and AI recruiters make confident-sounding mistakes that are hard to catch because they sound confident.

Cost Breakdown: Real Numbers

For a typical small team processing 50 applications per month:

If you are already running a home server (I run a PC-PC setup with WSL Ubuntu for multiple agent projects), the n8n hosting cost drops to zero—you already have the hardware.

The cost is negligible. The time saved is not. Reviewing 50 raw applications manually at 8–12 minutes each is 6–10 hours. Reviewing 50 normalized Telegram summaries at 30–60 seconds each is 25–50 minutes. That is the difference between dread and done.

Where bizflowai.io helps with this

At bizflowai.io, I build exactly this kind of Gmail-to-AI-to-Telegram workflow for small teams that cannot afford to hire a developer but need their inbox to do more than collect messages. The hiring queue is one template among several—lead capture, invoice triage, client onboarding—all following the same architecture: one intake path, narrow AI extraction, human approval gate, full audit trail. If your hiring process lives in Gmail and you want it structured without ripping out your existing tools, this is the pattern I deploy.

Want more like this?

I publish practical AI automation, GenAI engineering, and faceless content workflows on YouTube every week.

Subscribe to bizflowai.io on YouTube — never miss a new tutorial.

Planning an AI automation project or need a second opinion on your architecture?

Connect with me on LinkedIn — Lazar Milicevic, GenAI Engineer & bizflowai.io Founder.

Visit bizflowai.io for our services, case studies, and AI consulting.