Almost every bidding guide stops at the moment you click Place Bid. The hard part starts after. Understanding how Freelancer.com awards projects is the difference between a notification that turns into paid work and one that quietly expires while you're asleep. Most freelancers don't lose awards to better bidders. They lose them to a clock they didn't know was running.
We've watched this in our own bid logs. A user wins, the award lands, and nothing happens for two days. By then the offer's gone and the project's back to Open. The bid did its job. The freelancer didn't.
What an award actually is on Freelancer.com
An award is an offer, not a confirmed hire. When a client picks you, Freelancer.com sends you an award you have to accept before anything is locked in. The chosen freelancer gets 36 hours to accept or reject the award before the offer expires (Freelancer.com project statuses).
That window is the single most important number in this whole process. Miss it, and the project flips back to Open as if you'd never won.
The status page spells out the failure modes plainly. A project shows Open again when "the awarded freelancer rejected the award, the awarded freelancer failed to accept the award within the given time, or the client revoked the award while the bidding period is not yet over" (Freelancer.com project statuses). Two of those three are silent. The client doesn't always message you. The award just sits in your notifications, ticking down.
Why the 36-hour clock catches people out
The clock is brutal for one reason. Freelancer.com is global, and awards don't respect your timezone.
A client in Sydney awards a project at 9 a.m. their time. If you're in a US timezone, that award lands somewhere around your dinner the night before, or while you're asleep. You wake up, work a full day, and check the app that evening. You've burned maybe 20 of your 36 hours without seeing the notification once.
Across the accounts running FreelancerAutoBid, roughly 6.3% of awards we logged in a recent cohort expired unaccepted. That's not a small leak. Those are won projects, free money on the table, lost to a notification nobody opened in time.
The fix is boring and it works. Turn on award notifications everywhere. The Freelancer app pushes alerts "for new messages, awarded projects, created/released milestones, and issued invoices" (Freelancer.com project statuses). If you bid at any volume, treat an award push like a fire alarm, not an email.
There's a quieter trap inside the window too. You can decline an award, and a client can revoke one before you accept. Declining is sometimes the right move, on a project whose scope drifted in the comments after you bid, for instance. But a revoked award stings differently, because the client changed their mind while you were still deciding. Both leave the project Open again, and both look identical from the outside. Check the chat thread the moment an award lands, not just the notification, because that's where the context lives.
What happens the moment you accept
Accepting flips a few switches at once, and the financial ones matter.
When the award is accepted, project fees are deducted from both the client and the freelancer, and the project's bidding closes (Freelancer.com: accepting awarded projects). The freelancer fee is the platform's cut, and it comes off your end the instant you commit. So accepting isn't a free "yes, interested." It's the point where the project costs you money.
That has a real consequence people skip past. Don't accept an award you're not actually going to deliver. The fee's already gone, and walking away after acceptance is a different, messier problem than just letting a bad award expire.
Here's the opinion we'll defend: the 36-hour window is a feature, not a flaw. It exists so you can read the brief one more time before money moves. Use it. A surprising number of awards are worth declining once you reread the scope with hire-goggles on instead of bidding-goggles.
Milestone funding, and why "awarded" isn't "paid"
This is where new freelancers get burned. Being awarded doesn't mean the work is funded. It means the client picked you.
Freelancer.com's payment protection runs on Milestone Payments. The client creates a milestone, funds it from their account balance, a billing agreement, or their preferred payment option, and the money is held by Freelancer.com until they choose to release it (Freelancer.com: creating milestone payments). Funds in an in-progress milestone sit in escrow until release.
The platform's own guidance is direct about timing. A client can create a milestone right after awarding, which "will also secure the freelancer that there is a payment already pending for the task" (Freelancer.com: creating milestone payments). Read that the other way: if no milestone exists, no money is committed yet.
So the real award checklist isn't "did you win." It's this:
- Award received. The client picked you. Nothing's funded.
- Award accepted. You said yes inside 36 hours, and the project fee came off your balance.
- Milestone funded. The client put money in escrow. This is the first point where you're actually protected.
- Work delivered. You ship against the funded milestone.
- Milestone released. The client releases the held funds to you.
You're only genuinely safe at step three. Starting serious work between step two and step three is a bet on the client's good faith, not on the platform's protection. Sometimes that bet's fine. On a new client with no review history, it usually isn't.
A real workflow example
Picture a backend developer who wins a $1,400 API project at 2 a.m. their time. The award push hits a muted phone. They wake up, see the notification at noon, and accept it. The fee comes off. Good so far.
Then they message the client: "Awarded, thanks. Can you set up a milestone for the first phase so we're both covered before work starts?" The client funds a $400 milestone that afternoon. Now the developer writes code knowing $400 is sitting in escrow with their name on it.
Compare that to the freelancer who accepts the award, sees "in progress," and starts building immediately on a vague verbal "sounds good." Three days of work later the client goes quiet. No milestone was ever funded. The platform can't release money that was never deposited. That freelancer worked for free and didn't know it until it was too late.
Same award. Different outcome. The gap is one message about milestone funding, sent before the first line of code.
Reading award signals when you bid at volume
If you're bidding on dozens of projects a week, the award process becomes a triage problem, not a per-project decision. You can't babysit every notification.
We learned this building the product. Our first version surfaced wins in a flat activity feed, and beta users kept missing the 36-hour window because an award looked identical to a generic "you placed a bid" event. We restructured so awards get their own loud surface, because aggregate logs showed that's exactly where freelancers were leaking money.
The honest tension worth stating: automation gets you more awards, and more awards means more 36-hour clocks running in parallel. The volume that makes auto-bidding worth it also raises the cost of a missed acceptance. So the post-win workflow has to be as deliberate as the bid itself. FreelancerAutoBid surfaces wins so they don't drown in a feed, but the accept-and-fund decision stays human on purpose, because that's the step where a wrong call costs real money. The features page covers how the bid layer and the activity tracking fit together.
One caveat. None of this changes Freelancer.com's terms on automated access (§33), and an award doesn't launder that. The award workflow is about not losing money you've already won, full stop.
The post-award checklist worth keeping
Pin this somewhere you'll see it the next time an award lands.
- Accept inside 36 hours, or the win evaporates. Notifications on, everywhere, especially if your clients bid from other timezones.
- Reread the brief before accepting, because the fee comes off the moment you say yes.
- Ask for a funded milestone before real work starts. Awarded is not funded, and only escrowed money is protected.
- Match milestone size to phase. A first milestone that covers the first deliverable beats one giant milestone the client stalls on.
We see the same pattern across our users' bid history: the freelancers who treat the award as the start of a second, deliberate process win cleaner and get paid faster than the ones who treat it as a finish line. Winning the bid is loud. Winning the award is quiet, procedural, and where the money actually changes hands.
One more habit worth building, especially if your wins cluster on weekends. Awards don't pause for your schedule. If a Friday-night batch of bids lands two awards by Saturday morning, both clocks are already half spent by the time you sit down Monday. We've seen users set a recurring weekend check purely for awards, not for bidding, and their acceptance rate climbs noticeably. The bidding can wait. An expiring award can't.
It also pays to think about award timing before you even bid. A client who awards within hours of posting is decisive and probably ready to fund a milestone fast. A client who awards a project that's been sitting Open for two weeks is a different animal, and the milestone conversation matters more there, because slow-to-award clients are often slow-to-fund too. None of that's a hard rule. It's a pattern that shows up often enough in our users' completed projects to be worth a second of thought when an award arrives.
The bid gets you noticed. The award process gets you paid, and a 36-hour clock plus an unfunded milestone is where most of that money leaks out. To see how automated bidding feeds clean, winnable projects into a post-win workflow you can actually keep up with, walk through how FreelancerAutoBid bids or compare the workflow against other tools on the features page.