Automating freelance proposals without losing your account

The pitch for an autobid system is obvious: watch the job feed, score the postings, draft a tailored proposal, send it. The last step is the one that ends your account.

Upwork prohibits any tool that submits proposals, bids or messages without a human action, including browser automation and scripts that mimic a person. Enforcement is account suspension, and for somebody whose income runs through that account it is the most expensive automation mistake available. What is permitted is generous, and everything before the send is fair game.

What we'll cover

• Where the line actually is
• What you can automate freely
• Designing around the human click
• Scoring, which is most of the value
• Building it with CodeWords
• Drafting that does not read as drafted
• Speed, and whether it matters
• The statistics circulating about this
• What to track instead
• Making it survive
• Limits worth knowing about
• What to build first
• Frequently asked questions

Where the line actually is

Upwork's own guidance on bots and automation draws it at submission. Any third-party tool, script or browser extension that performs actions on your behalf without manual human intervention is prohibited, which explicitly includes automated proposal submission, browser drivers interacting with the proposal flow, and scripts that imitate human behaviour (Upwork on using bots and automation properly).

What is allowed is equally explicit: generating drafts with any AI tool is fine, provided you personally review, adapt and approve each proposal before it goes.

So the rule for anything you build is one sentence. A proposal leaves only because a person decided it should, with that decision made in the platform's own interface.

Other platforms differ in the detail and rarely in the direction. Check the specific terms of each one you work on rather than assuming Upwork's apply, and take the strictest reading where the wording is ambiguous, because the downside is asymmetric.

What you can automate freely

Almost the whole pipeline, and this is where the time actually goes.

Watching the feed. Polling for new postings that match your criteria, so you are not refreshing a page.

Filtering and scoring. Discarding the obvious misses before you see them.

Enriching. Pulling the client's history, their previous postings, their hire rate and spend, so you are deciding with context.

Drafting. Generating a tailored first version against the posting and your own history.

Notifying. Getting a short summary to you wherever you actually are.

Recording. Logging what you bid on, at what price, and what happened.

That is the great majority of the work. The remaining step is reading a draft and deciding, which is the part that needs your judgement anyway and takes a minute rather than twenty.

Designing around the human click

The constraint turns out to improve the system, which is not a consolation prize.

Deliver a draft, not a queue. The notification should carry the posting, why it scored well, and the proposed text, so the decision happens in one read.

Make rejection one action. Most postings should be declined, so declining must be cheaper than accepting.

Keep the send in the platform. Copy the approved text into the platform's own interface and submit it there. Anything that posts on your behalf is the prohibited case regardless of how the approval was captured.

Do not batch approvals. Approving fourteen at once is a human click in form and an automated submission in substance, and it produces identical proposals that read as such.

Log the decision. What you approved, what you changed, and what you declined. That record is what makes the scoring better.

Scoring, which is most of the value

Reading fewer bad postings is worth more than writing faster proposals, and almost nobody builds it.

Score on things that actually predicted outcomes for you. Client spend and hire history. Whether the posting describes the problem or only the technology. Budget stated versus vague. How many proposals are already in. How long the posting has been open. Whether the wording matches work you have actually done rather than work you could do.

The discipline is to derive these from your own history rather than from advice. Go through your last thirty proposals, mark which converted, and look at what the winners had in common. It is usually two or three factors and they are frequently not the ones people assume.

Then be ruthless. A scoring system that surfaces forty postings a day is a worse filter than the feed.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: which postings to watch for, how to score them, what a draft should contain, and where to notify you.
3. Authorize the connections to wherever you want the summary delivered and wherever you keep your own history.
4. Describe the exceptions, and make the boundary explicit: the automation drafts and notifies, and never submits.
5. Keep the sending step outside the automation entirely, in the platform's own interface, so there is no path by which it could submit.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Drafting that does not read as drafted

Clients see many proposals and the generated ones are recognisable.

Reference something specific to the posting, in a way that would be impossible to write without having read it. This single thing separates a proposal that gets read from one that does not.

Lead with the relevant work you have done, not with an introduction.

Answer any question in the posting. Clients frequently include one precisely to filter out automated responses.

Keep it short. Length reads as padding rather than effort.

Cut the opening flattery. "I was excited to see your posting" is the single most recognisable generated line in the category.

The most useful prompt input is your own successful proposals. A draft generated against those sounds like you; one generated against general advice sounds like everyone.

Speed, and whether it matters

Being early helps, and it is worth less than people think and much less than being relevant.

A proposal arriving within the hour is in the set the client reads. Beyond that the returns fall away quickly, and no amount of speed rescues a proposal for work you have not done. Since your pipeline drafts in seconds and you approve when you next look at your phone, you are comfortably inside the window without needing to automate the send.

Which removes the main argument people make for crossing the line. The speed advantage that automated submission buys is small, and the downside is the account.

The statistics circulating about this

Worth naming, because you will encounter them while researching this.

There are widely quoted figures about automation-related ban rates and average income lost per suspended account. Every source for them that I could find is a company selling Upwork automation software, citing another such company. None traces to Upwork or to any published study with a method.

That does not make the underlying risk imaginary. Upwork's own documentation states the prohibition and the consequence plainly, and that is the citation worth having. Numbers produced by parties with an interest in the answer are not, in either direction.

What to track instead

Your own numbers are available and are the only ones that describe your situation.

Proposals sent, interviews, hires, and the conversion between each. Win rate by category of work. Win rate by how quickly you responded, which tells you whether speed matters in your niche. Average value of work won by proposal style. Time spent per proposal including the reading.

Thirty proposals is enough to see a pattern. That is a month for most people, and it will change what you bid on more than any tooling will.

Making it survive

Keep submission manual, with no code path that could send.

Re-read the platform's automation policy periodically, since these terms change.

Feed declined postings back into the scoring, or it never improves.

Keep your drafting examples current as the work you want changes.

Track outcomes per proposal, since scoring without outcomes is guesswork with extra steps.

Limits worth knowing about

Automated submission is prohibited and enforced by suspension, with little meaningful appeal.

Platform terms differ and change, so check each one you work on.

A better proposal cannot fix bad targeting, which is why scoring matters more than drafting.

Generated text is recognisable unless grounded in your own writing and the specific posting.

Speed is a small edge, and not one worth an account for.

What to build first

The scoring filter and a notification. No drafting, no templates, no integrations beyond the feed and wherever you read messages. Just: here are the three postings today worth your attention, and here is why each scored. Most of the time this thing recovers is time spent reading postings you were never going to bid on.

Two habits make the difference. Keep the submit action in the platform's own interface, with no code path that could send on your behalf, since that single boundary is what protects the account the whole business runs through. And build the scoring from your own last thirty outcomes rather than from general advice, because the factors that predict your wins are specific to the work you do.

Frequently asked questions

Is automated bidding allowed on Upwork?

No. Upwork prohibits any tool that submits proposals, bids or messages without manual human intervention, including browser automation and scripts that imitate a person. Enforcement is suspension.

Can I use AI to write proposals?

Yes. Generating drafts with an AI tool is permitted provided you personally review, adapt and approve each one before it is sent. The prohibition is on automated submission, not on assistance.

What parts of the process can be automated?

Watching the feed, filtering and scoring postings, enriching with client history, drafting, notifying you, and recording outcomes. That is most of the time cost.

Where exactly should the human step sit?

At submission, in the platform's own interface. Anything that posts on your behalf is the prohibited case regardless of how the approval was captured.

Is approving several proposals at once acceptable?

It is a human click in form and automated submission in substance, and it produces near-identical proposals that read that way. Approve one at a time.

What should a scoring system look at?

Factors that predicted outcomes in your own history: client spend and hire rate, whether the posting describes a problem or a technology, budget clarity, proposal count, and how closely the work matches what you have actually done.

Does responding quickly matter?

Being in the first hour helps. Beyond that the returns fall away, and relevance matters far more. A pipeline that drafts instantly and waits for your approval is comfortably inside the useful window.

Why do generated proposals fail?

They lack anything that could only have been written after reading the posting, they open with flattery, they run long, and they ignore the question the client included to filter them out.

Are the ban-rate statistics reliable?

The figures circulating come from companies selling automation tools for these platforms, citing one another. The prohibition and its consequence are documented by the platform itself, which is the source worth using.

What should I measure?

Proposals sent, interviews, hires, win rate by work category and by response speed, and time spent per proposal. Thirty proposals is usually enough to see the pattern.

Related reading

• Every question costs you people and buys you quality
• Closing the loops a practice leaves open
• Managing credentials across automations