Submission, Review, Approval.

Three separate events with three separate records. Each one is attributable to a person and a moment, which is what makes the history worth having later.

In hand
  1. Assigned An Assistant holds the Task, with a Checker named.
  2. Submitted The work is handed to review. Not finished, and not payable.
In review
  1. Reviewed The Checker approves it or sends it back with a reason.
  2. Approved Quality is accepted. Cost becomes confirmed.
Out the door
  1. Delivered A separate act. This is what the Client sees as Completed.

Revisions Are a Cycle, Not a Failure State.

Work that is not right yet goes back with a reason. The Assistant fixes it and resubmits, and the same assignment continues rather than restarting as something new.

Every pass through that loop is kept: what was submitted, what the reviewer said, what changed. Three revisions on a Task is a fact about the Task, available later when somebody asks why it took a fortnight.

Reviewers Are Named.

Every Engagement can carry a Default Checker, so work has a reviewer before anyone asks who should look at it. Each Task can override that.

A Checker can only review work they are the Checker on. Holding the permission to review is not the same as being able to review anything, and an Admin stepping in to override a review is recorded as exactly that.

DECISION REQUIRED

When an Assignment Does Not Work Out.

Someone is unavailable, the work was misjudged, the wrong person was picked. The useful question is what happens next, and Bikabo makes it an explicit decision rather than a silent reassignment.

Reassign

Hand the Task to someone else. Everything the previous person did stays on the record.

Cancel

The work is no longer needed. The Task is closed with that stated, not deleted.

Accept existing work

What was done is good enough. Approve it as it stands, with the usual financial consequence.

Partial compensation

Pay for what was genuinely done without pretending the work passed review.

Approval Is Where Cost Stops Being Provisional.

Before approval, work counts as pending exposure: what you would owe if it were approved as it stands. Approval turns that into confirmed cost, at the rate that applied at that moment.

Approved is not delivered

Work can pass review and sit waiting to go out. Delivery is its own act, and it is the one the Client sees.

Approved is not paid

Approved cost is what you owe. Paid cost is what has left the business. The gap between them is a real thing worth being able to see.

Approving the same work twice does not pay for it twice. The approval path takes a lock on the record, so a double click, a slow connection or a retried request cannot produce two earnings for one piece of work.

A Review Decision Is Not a Message.

Teams talk about the work, and they should. But "looks fine to me" in a thread is not a review, and it cannot be counted, reported on or pointed at six months later.

The formal decision stays structured: who reviewed it, when, what they decided, and what they said. Discussion sits alongside that rather than replacing it.

The Record Survives the People.

Assignments, submissions and reviews are separate records, so reassigning a Task adds to its history rather than overwriting it. Deactivating someone ends their access and leaves everything they did in place.

When somebody asks who reviewed this and what they said, the answer does not depend on anyone still working here.

Questions About Review and Approval

No. Submitted means it has been handed to review. It is not approved, it is not payable, and it has not been delivered to the Client. Those are three further, separate events.

No. Approval is an internal quality decision. Delivery is the act of giving the work to the Client, and it is recorded separately. Until work is delivered, the Client still sees it as In Progress.

Not automatically, and never silently. When approved work goes back for revision you choose the financial treatment: no deduction, a partial deduction, or a full reversal. Whether the correction is a reversal or a recovery depends on whether that earning had already been paid out, and Bikabo works that out rather than asking you to.

No. Assistant and Checker compensation are independent. A correction on a revision only ever touches the Assistant’s earning.

They reject the assignment with a reason. The Task is flagged as needing a decision rather than sitting idle, and you choose what happens: reassign it, cancel it, accept the work as it stands, or record partial compensation for what was genuinely done.

Yes, explicitly. Partial compensation is recorded as its own ledger event without changing the fact that the work was rejected. It never reads as a quiet acceptance of work that did not pass.

No. Review is done by a person, and the record says which person. There is no quality score, no automated rule builder and no configurable multi-stage approval chain.

Make Quality Review Part of the Work, Not an Afterthought.

Submission, review, revision and approval as recorded events, each one attributable and none of them silently rewritable.