CLIENT WORK MANAGEMENT
Run Client Work Without Losing the Context Around It.
Task lists lose the context around the work: who the client is, what was agreed, what has already been delivered and what it is costing. In Bikabo the context is the structure, so it cannot be separated from the work.
ONE STRUCTURE, END TO END
Clients, Engagements and Tasks.
Every Task belongs to an Engagement, and every Engagement belongs to a Client. There is no free-floating work, which is what lets any Task answer questions about the business it belongs to.
- Client The business you deliver for.
- Engagement A project or a retainer, with its own agreement, team and currency.
- Task One activity or deliverable inside that Engagement.
- Assignment Who is doing it, and who is checking it.
- Work What was actually done, logged against the Task.
- Review Submitted, reviewed, revised or approved.
- Cost Approval is what makes cost confirmed.
- Delivery What the Client actually receives.
- Payment Client money in, team money out.
Types of Work Make the Repeatable Work Repeatable.
Most service businesses do the same handful of things over and over. A Type of Work captures one of them: what it is called, how it is measured, and what your team needs to record each time they do it.
On plans that include custom fields, you decide what Bikabo asks for. On plans that include scheduling, a Type of Work can be one that happens at a specific date and time. More of the day to day moves into your own configuration rather than waiting on somebody to remember the house rules.
Types of Work are versioned. Changing one affects the Tasks created afterwards and leaves the ones already done exactly as they were recorded.
Set the Team Once, Override When You Need To.
Each Engagement can carry a Primary Assistant and a Default Checker. Every new Task inside it starts with those two already filled in, so the routine case takes no decisions at all.
Nothing stops you choosing someone else on a particular Task. The default is a starting point, not a constraint. On plans that include it, an Engagement can carry a full team rather than just those two people.
Whatever happens after that is kept. Assignments, submissions and reviews are separate records, so reassigning a Task adds to its history rather than replacing it. When a Task has been through three people, you can still see what each of them did.
Planned Work and Additional Work Are Not the Same Thing.
This is the distinction that makes scope growth visible while it is still growing, rather than at the end when somebody adds up the hours.
Planned Work
Work that was part of the Engagement as agreed. It is what the Agreement was priced against.
Additional Work
Work discovered along the way. It is logged as what it is, flagged for review, and carries its estimated cost before anyone approves it.
Recording Additional Work does not change what the Client owes. Whether extra work becomes extra money is a commercial decision, made deliberately and recorded against the Agreement, with the original figure still on the record.
Blockers Get a Record, Not a Message.
When work cannot proceed, the person doing it raises an Action Request: a structured item with a reason, an owner and a resolution, attached to the Task it is blocking.
The alternative is a message in a thread that somebody has to notice. Action Requests are counted, they are visible on the Engagement, and closing an Engagement tells you how many are still open.
Files and Conversation Sit With the Work.
Files are uploaded against the Task they belong to, and whether a Client can see one is an explicit decision rather than a side effect of where it was uploaded.
Internal discussion happens on the Engagement or the Task. Client conversation is a separate channel. Both live next to the work, and they never mix.
Ending an Engagement Is Part of Running One.
Clients stop early. Priorities change. An Engagement that ends before it was meant to should not sit open forever, and it should not be quietly archived either.
Close-out shows you where the Engagement actually stands first: what was delivered, what is approved, what is awaiting review, what is in progress and how many Action Requests are still open. Work that has not started is cancelled with a recorded reason. Work that is in progress gets a decision from you, task by task, defaulting to letting it finish.
An Engagement that ended early is recorded as exactly that, distinct from one that completed as planned, with the reason attached. Everything earned stays earned.
The Work Record Is What Makes the Numbers Possible.
None of the structure above exists for its own sake. Because every Task belongs to an Engagement, because assignments are recorded, and because approval is a distinct event, Bikabo can answer what a piece of client work is costing without anyone maintaining a second system to tell it.
That is the whole design. The work record produces the financial record, rather than the two being reconciled later.
Where the line is drawn
- The structure is Client, Engagement, Task and Type of Work. It is a model of client work, not a blank canvas you have to design a process on before you can use it.
- Work is created and assigned by the people accountable for it. Nothing writes or hands out your Tasks on your behalf.
- Every record here is something a person did. Nothing on this page is estimated, inferred or predicted.
Questions About Managing Client Work
Yes. A Client can hold as many Engagements as you need, each with its own agreed value, payment schedule, team and currency. Work, costs and client money all roll up per Engagement and per Client.
A reusable definition of a kind of work you do repeatedly, including how it is measured and, on the plans that include it, the specific fields your team should fill in every time. Setting it up once means Bikabo asks for the same information on every Task of that kind, instead of relying on somebody remembering.
The change applies to new Tasks. Work already done under the previous definition keeps the fields it was created with, because Types of Work are versioned rather than overwritten. Adding a field does not rewrite the history of work already completed.
Yes, and that is the point. Work discovered mid-Engagement is recorded as Additional Work rather than quietly folded into the plan, and it surfaces for review with its estimated cost attached. Who is allowed to declare work as Planned is deliberately restricted, so scope cannot grow silently.
They can reject the assignment with a reason, which flags the Task as needing a decision rather than leaving it to rot. You can reassign it to someone else, and the full history of who held it before, what they submitted and how it was reviewed is preserved.
Bikabo walks you through closing it. Work that has not started is cancelled automatically with a recorded reason. Work that is in progress gets an explicit decision from you, task by task. Nothing that has already been earned or delivered disappears.