Project history and useful referencesProject history

A timestamped history to help you follow your freelance project.

A signed agreement, a shared preview, a revision request: each step needs its context. Dealokr brings recorded project events together so you can understand what is done, what is pending and what needs checking.

Explore project history

You return to a project after a few days and the same questions come up: which version did the client review, what did they request and what still needs to happen? Useful project history gives you reference points without relying on memory or interpreting a status on its own.

In Dealokr, project events sit alongside the agreement, payment, deliveries and decisions. To see how these reference points fit into the full project journey, explore how Dealokr works.

The benefit shows up whenever you need to regain context: preparing another version, answering a payment question or explaining the handoff status. You can relate events to the relevant documents and conversations, then identify a clear next action.

Four reference points for reviewing a project.

The agreement and version that define the expected work.
The reviewed deliverable, feedback and related decision.
The exact payment event, kept separate from bank arrival.
The references worth checking or retaining for the next step.

01 · Start with the agreed scope

Find the agreement that gives each step its meaning.

A timeline becomes useful when you can connect it to the work that was agreed. Before reading the latest event, find the project agreement, deliverables and review conditions. In Dealokr, these reference points remain associated with the project, so you can start from the shared scope instead of reconstructing the request from a recent comment alone.

Two professionals compare several paper documents.

Identify the right starting point

Check the project name, parties, scope and relevant agreement version. A prepared document and a signed agreement represent different stages. To understand what was expected, read the appropriate version and its status together, rather than relying only on its title.

Retained documents can be consulted in the project workspace. When a newer version exists, take a moment to understand which change it addresses. The fact that a document is more recent does not, by itself, explain what had previously been accepted or how the scope developed.

Keep changes in their original context

An additional request during the project should be considered alongside the conversation and agreement that define it. Identify what changes in the expected result, schedule or deliverables. This helps you read later events without treating a new requirement as though it had always been part of the original scope.

The benefit is practical when you resume work: you know which result to prepare and which question still needs clarification. Project history supports that reading; it does not turn a suggestion or intention into an already accepted condition.

02 · Identify what was presented

Connect each delivery to a recognisable version.

“The file I sent” quickly becomes an unclear reference once several attempts exist. Give each delivery a recognisable name and version, then find the related event in the project. You can connect the material presented, the feedback received and the next version without mixing up a draft, a review preview and the agreed final package of files.

Paper cards are sorted in a compartmented holder.

Name the material so you can return to it

A name such as “presentation-v02-review” is easier to reference than a series of files all called “final”. Add details that suit your work: a version number, the part of the deliverable or a review reference. Your client should be able to recognise the material you are asking them to examine.

In Dealokr, deliveries, conversations and recorded events provide points you can relate to each other. Open the relevant file or conversation to check the detail. A line saying a delivery was made does not replace checking its actual content, format and proposed version.

Keep previews separate from final handoff

A preview is there to help the client examine the work. Hosted final files follow their own access state in the delivery workflow. Viewing a preview therefore does not mean the client has received all production material or approved what they saw.

If part of the delivery is available through an external service, check its permissions and version in that tool as well. The project helps you find the link and its context; it does not automatically create a copy of everything that changes at the external provider.

03 · Understand the feedback

Find the decision behind a revision request.

Feedback becomes actionable when it identifies the material reviewed, the point concerned and the response needed. Project history helps place a revision request or approval in the sequence of the work. With the preview and conversations in Dealokr, you can find the decision’s context instead of trying to infer your client’s intention from a status on its own.

An open notebook contains handwritten questions beside a laptop.

Read the message with the version it concerns

Start with the question the client was answering. Had you asked them to check a specific item, choose a proposal or approve the whole preview? “That looks good to me” means different things depending on what was presented and any reservations stated alongside the response.

For a revision, identify the location to change, the expected result and any missing information. If the feedback remains vague, restate the question before producing more work. A clear exchange is more useful than a long timeline of replies that never resolve the actual issue.

Keep the decision understandable after changes

When a new version addresses the feedback, explain what changed and what still needs a response. If several stakeholders give incompatible opinions, ask the agreed decision-maker to resolve them. History keeps the available context; it does not choose which preference to follow on their behalf.

Approval concerns the work presented. It remains separate from client payment, the transfer request and final-file handoff. Likewise, recorded preview access does not establish that the client read or accepted everything. To understand their decision, return to the response itself.

04 · Read the right financial event

Separate client payment, transfer and bank arrival.

A confirmed payment is reassuring, but you need to know which operation the confirmation concerns. For fixed-price work, Dealokr organises the client’s payment upfront, followed by a transfer requested by the freelancer under the project conditions. History and available statuses help you distinguish those steps without confusing their recording with money arriving in your own bank account.

A person uses a calculator beside financial documents.

Place confirmations within the payment workflow

The client pays 100% of the fixed price through Stripe Connect before work starts. Funds are collected in the platform’s Stripe balance before transfer to the freelancer’s connected account. A confirmed client-payment event concerns that initial project funding, rather than a payout reaching your bank account.

Reference point	What it means	What to check
Client payment confirmed	The initial payment concerns project funding.	The related project, amount and payment status.
Transfer requested	The freelancer requests the operation under the applicable conditions.	Its status: a request is not confirmation.
Transfer confirmed	The transfer to the connected account is confirmed; hosted final-file access follows this workflow.	The transfer concerned, especially for a project with milestones.
Bank arrival	The bank payout follows Stripe’s separate schedule.	The provider’s information and the bank account.

Do not skip a step when replying to your client

After review, the freelancer requests the transfer when the conditions allow. Approval alone or a deadline passing does not automatically trigger that operation. Hosted final files become accessible after transfer confirmation under the project workflow.

To answer “where is the payment?”, specify the relevant step and its actual status. If the project uses milestones, one partial transfer does not mean everything has been transferred or all files are available. For bank arrival, check the relevant Stripe information rather than interpreting a delivery entry.

05 · Open the useful context

Read an event’s date and supporting details.

In project history, you can open an event’s details to find its description, date and available references. Read those details with its status to place the action within the project. You can then return to the right document, identify the version concerned and ask a precise question about the next step in the work.

A green clock and an open notebook sit on a desk.

Check what is confirmed and what is pending

An expected step is not the same as an event that has already been confirmed. Read its status with the description and displayed date. If a detail is missing, check the relevant document, delivery or operation before telling someone that the action has taken place.

When asking someone to check a point, provide the entry reference and the material concerned. They can find the same information more easily and understand your question. “I mean preview v02 and the feedback that follows it” gives you a shared starting point for reviewing the record.

Answer a specific question

Instead of reproducing the whole timeline, find the reference point that answers your question: which version was presented, what response was received, which transfer is confirmed? Then relate the entry to its supporting material. A date without content can show a sequence without explaining the decision.

After a call or a conversation in another tool, a summary can supplement the available context: what was discussed, what remains to be confirmed and the material concerned. Identify it as your own recap and ask for a response on the useful points. Project history does not automatically include every exchange that takes place elsewhere.

06 · Prepare the next action

Return to a project with an understandable record.

The most useful way to use history is often to prepare a simple response: here is the scope, here is the reviewed version and here is the remaining issue. Find the few events that matter, check their supporting material and state the next action. In Dealokr, you can regain context and resume the conversation from shared reference points.

An organised desk holds a ring-bound pad and work supplies.

Prepare a short, verifiable summary

Before another review or a project restart, bring together the relevant agreement, latest version and open points. Separate what is confirmed, what is pending and what still needs checking. You can then ask your client a precise question without expecting them to reread every conversation.

For example, you find preview v02 followed by feedback requesting changes to two headings. You have prepared v03 to address those comments. The next step is to ask the client to review v03 while noting the two changes, rather than requesting fresh approval without identifying the material.

If a disagreement arises, stay with facts and references: the material presented, the response received and the issue to clarify. The record helps you prepare material for a conversation or a request for advice. It does not decide who is right or guarantee that an item will be accepted as evidence, a bank dispute will succeed or proceedings will have a particular outcome.

Retain what your activity needs

Organise your own backups and keep the documents required for your circumstances. Operational project history does not replace your retention obligations and should not be treated as a complete or unlimited archive of all your exchanges. Share only useful material, with access suited to the recipient.

For your next project, the benefit begins at the start: a clear agreement, identifiable versions and specific feedback. History then becomes useful day to day, helping you move forward and regain context, rather than a record you attempt to reconstruct only when something goes wrong.

Useful project history connects each step to its context: the relevant agreement, reviewed material, response received and exact payment event. Use these reference points to understand the situation and choose the next action, checking the documents and operations that matter.

Back to the reference points

Sources and verification

Dealokr — Project history and event details
Dealokr — Agreement versions and retained documents
Dealokr — Previews, feedback and client decisions
Dealokr — Client payment, transfers and hosted-file access
Dealokr — Available context and limits of project history

The payment workflow described concerns fixed-price projects. History reflects recorded events and their available context; it does not guarantee an exhaustive log, qualified timestamping or a legal outcome. Client payment, transfer and bank arrival remain separate.