How it works

A project becomes clear when each step has its decision.

Dealokr turns scattered exchanges into one record: what is planned, what triggers the next step, what needs review and what has been approved.

Create a Dealokr deal Use the guide

Dealokr supports the deal and its history. Payments and file permissions remain with the relevant providers.

The framework

The five moments that shape a project.

The workflow complements your expertise by making the next action explicit for freelancer and client.

01
The result
Before sending the link, write the expected result, deliverables, boundaries and client decision-maker.
02
The trigger
Tie the payment step to a real moment: booking, kickoff, phase start or milestone.
03
Review
Share a version the client can approve or request a specific revision on.
04
The decision
Keep the response with the relevant version instead of in an isolated conversation.
05
The handoff
Name what is handed over after approval: files, links, access or documentation.

In practice

Make the next action clear.

Each step should show who decides, what needs checking and what follows. That makes the workflow useful day to day.

The deal starts before the first file.

An amount and a date do not make a project clear. Clarity comes when the client can explain what they will receive, what they need to confirm and what follows their response. That preparation means the freelancer does not carry all the context alone.

In Dealokr, scope definition starts the record. It connects project terms to review and handoff. A change affecting the result can then become a new phase rather than an implied request.

Payment is a status, not a promise.

The client completes the payment step with the configured deal provider. Dealokr displays the returned status alongside terms and next actions; it does not collect or hold funds or guarantee a transaction outcome.

This lets the freelancer identify the visible trigger without claiming to replace the payment provider, bank or applicable payment rules.

Delivery should produce an actionable response.

A review delivery should show what the client is examining and the expected decision. A useful response approves, requests a specific revision or flags a scope issue. This is easier to handle than “it is not quite right”.

After approval, final handoff follows the deal’s agreed route. Access rights in Drive, Figma, GitHub or another platform remain managed by the owner in that tool.

History is especially useful when the project becomes difficult.

When a question arises, you do not need to reconstruct the story across a quote, messages, screenshots and several links. Steps, versions and responses can be read in the same context.

This is an operational project record. It does not replace a suitable contract, invoice, legal, tax or accounting advice or the parties’ obligations.

Operational checklist

The test of a useful workflow.

Check these three moments before creating a deal. If one remains unclear, make it visible in the record first.

Before starting

The result is understandable without a context call.
Deliverables, exclusions and revisions are named.
The person consolidating the client decision is known.

During the project

Payment status is distinguished from production progress.
The next milestone and review are visible.
Requests that change the result are stated explicitly.

At the end

The version receiving a decision is identifiable.
Final handoff is described before delivery.
Terms, responses and steps remain available in the record.

Useful wording

Simple language for the moments that matter.

Adapt the bracketed details to your situation. These examples clarify the project; they are not legal clauses.

After the brief

Present the record as a shared reference.

“I am sending one space for the expected result, the starting step, versions to review and final handoff. You will always see what needs action.”

The client sees the benefit immediately: fewer messages to track down.

Before kickoff

Connect payment to a concrete action.

“This step covers the start of [phase]. Once its status is confirmed in the record, I will begin and send the first review on [date].”

Explain the trigger without jargon or payment guarantees.

At delivery

Request a specific decision.

“Here is version [name]. Please approve the result or identify the adjustments needed against what is agreed in the deal.”

The client knows what to answer and which version it concerns.

A system, rather than an abstract promise

A deal becomes reliable when everyone sees their next action.

The value comes from connecting scope, payment, review, approval and handoff. Keep your commercial documents, obligations and external permissions current separately.

Common questions

Useful answers before starting the project.

Does Dealokr find clients for freelancers?

No. Dealokr comes after the introduction, supporting an existing project through terms, payment, delivery and approval.

Does Dealokr hold the client’s money?

No. Money movement belongs to the configured payment provider. Dealokr keeps the deal context and statuses useful for the next steps.

Does Dealokr replace contracts, invoices or legal advice?

No. It complements them by making scope, versions, decisions and handoff easier to follow.

A protected next deal

Keep payment and final handoff in the same deal.

Create a clear project for you and your client, with a protected payment flow through the configured provider, protected delivery and visible approval.

Create a Dealokr deal See the workflow