SCHEDULED WORK
Manage Client Work That Has to Happen at a Specific Time.
Some client work happens at a time rather than by a deadline: a call, a live session, a window when someone else’s system is available. It is still work your team is assigned to and still work that costs something.
A Scheduled Session Is Still a Task.
Scheduling adds context: when it happens, how long it lasts, which timezone it was agreed in. It does not add a second workflow, a second place to look or a second set of statuses.
That matters more than it sounds. Because it is a Task, a scheduled session is assigned the same way, reviewed the same way, and costs the same way. A business that runs half its work as sessions does not end up running half its business somewhere else.
You mark a Type of Work as one that happens at a specific time, and every Task of that kind asks for the schedule.
The Time It Was Agreed In Is the Time It Stays In.
Distributed teams get this wrong constantly. A session agreed with a client in one place, assigned to someone in another, read by an admin in a third, and somewhere in that chain an hour goes missing.
Bikabo records the original timezone alongside the time and keeps it. What was agreed is what is stored.
Conflicts Surface Before You Commit.
Assigning someone whose other scheduled work overlaps raises a warning at the moment you assign, not after the client has been told. It warns rather than blocks, because you know things the software does not.
Changes and Reminders.
Sessions move. Rescheduling is a recorded change rather than a quiet edit, and moving one is a separate permission from editing a Task, because the two are different kinds of decision.
Reminders for upcoming work go out on a schedule, set once for the business rather than configured per client, and the same reminders can be sent manually whenever you want.
When a Session Cannot Go Ahead.
The client did not show, the access did not work, the system was down. That is an Action Request: a structured blocker with a reason and a resolution, attached to the work it stopped, rather than a note somebody has to notice.
Access Details Need Somewhere Safer Than a Note.
Work that happens on someone else's system needs the details to get in. Put those in a task note or a message and they spread through the app in plain text, into notifications, into email, and eventually into a screenshot.
Secure Access Details are a field type with their own rules:
- Encrypted at rest.
- Masked by default, everywhere they appear.
- Revealed only by someone holding the specific permission to reveal them.
- Every reveal recorded, with who and when.
- Excluded from notifications, email, exports and the Client Portal.
The person doing the session gets what they need. Nobody else does, and you can see who looked.
What the Client Sees.
Where you have made it visible, a client can see what is scheduled and when, so they know what is coming without asking.
The access details attached to that work never appear in the portal, and neither does who internally is assigned to run it.
What This Is Not.
- Scheduled work is created deliberately, one piece at a time, so a standing rule cannot quietly book a client session nobody intended.
- Scheduling here lives with the client work it belongs to. It is not a second calendar to keep in step with your own.
- It answers when a piece of client work happens, not how a whole team's capacity is planned across a quarter.
Questions About Scheduled Work
No. It is a Task with a date, a time, a duration and a timezone on it. It is assigned, reviewed, approved and costed exactly like any other work, which means it appears in the same queues and the same cost figures rather than in a parallel system.
The time is recorded with the zone it was agreed in, and kept that way. A session agreed for 3pm in Nairobi stays 3pm in Nairobi, whoever is reading it and wherever they are.
Rescheduling is a recorded change rather than a silent overwrite, and moving a session is a distinct permission from ordinary task editing.
It warns you. When you assign someone whose other scheduled work overlaps, Bikabo flags the conflict before you commit rather than after. It is a warning, not a block, because sometimes an overlap is intentional.
In Secure Access Details, a field type built for exactly that. Encrypted at rest, masked by default, revealed only by someone who holds the permission to reveal them, and every reveal recorded. They never appear in an email, an export or the Client Portal.
They go out on a schedule, set once for the business rather than arranged per client, and they can also be sent manually at any time.
No. There is no calendar sync in either direction, and no repeating rule that generates sessions week after week. Each scheduled Task is created individually.