[ Link 01 ]
Requests spawn tasks on the same project.
A request raised mid-project can spawn a task on the same project without leaving Role Central — briefing, ownership and context stay attached to the record they came from.
Capture→Plan
/ Product
One workspacefor the full client-worklifecycle.
Role Central covers seven connected stages of client work — from the moment a request lands to the invoice that closes it out. Every stage is a real product surface. Follow the sticky nav below to see how each one works.
W/02
Why the lifecycle matters
One connected chain.
Each stage hands off to the next inside the same workspace. That’s where most of Role Central’s value lives — not in any single surface, but in the fact that one piece of work carries its context all the way through.
P/03
Problems it solves
Built for the work
that falls between systems.
Seven operational and commercial problems Role Central is designed for. Each one is solved by connecting product surfaces that most tools keep separate — the value comes from the connections, not just the features.
Retainer work is hard to control.
Planned work, random requests, logged time and retained capacity are usually split across different systems and month-end spreadsheets. Nobody sees the true position until it's too late to steer it.
/ Connected through
/ Outcome
See what was included in the retainer, what has consumed retained capacity this period, and what may need commercial close or charging — from the same records, not a reconstructed spreadsheet.
Time & retainer →Nobody knows where the time went.
The work gets done, but explaining effort afterwards becomes manual reconstruction — calendars, memory, half-filled timesheets. Reporting turns into detective work.
/ Connected through
/ Outcome
Planned work and actual effort stay attached to the customer, project or service that produced them — so answering “where did the time go?” is a filter, not an investigation.
Time reporting →Client requests disappear into email and chat.
Bugs, change requests, small favours and support asks arrive outside the project plan — through email, chat, Slack DMs, sticky notes. They lose SLA, commercial context and history the moment they land somewhere unstructured.
/ Connected through
/ Outcome
Capture once, assess once, route into delivery once — and keep the history all the way through to the invoice line the request eventually informs.
How capture works →Projects launch and handover falls apart.
The project tool worked during delivery. Post-launch support then moves into a separate ticketing system, a separate email inbox, and a separate spreadsheet — losing the customer's history along the way.
/ Connected through
/ Outcome
Handover is the same workspace as delivery. A request raised three months after launch still knows the project it came from, the service it belongs to and the team that owned it.
Delivery continuity →Teams know they're busy but can't see why.
Workload is split across tasks, support requests, planner blocks and out-of-office. Everyone senses pressure; nobody can point at where.
/ Connected through
/ Outcome
See existing commitments and current pressure before adding the next piece of work — for individuals and for the team.
Schedule & capacity →Chargeable work gets done before anyone decides if it's chargeable.
Commercial decisions happen too late. Someone helps a client on a Wednesday; a conversation about whether that was included or billable happens at month-end. Both parties would rather have decided upfront.
/ Connected through
/ Outcome
Commercial classification is part of the operational workflow — set at capture, visible on every list — instead of month-end reconstruction.
Commercial close →Customers need visibility without seeing internal work.
Clients want confidence and transparency. Internal delivery detail — private notes, delivery estimates, half-formed ideas — must stay internal.
/ Connected through
/ Outcome
Shared customer collaboration where it belongs; internal-only detail where it needs to stay. Both are visible to the delivery team; the customer sees only their side.
Security & trust →C/04
What ships
Real product surfaces,
not renders.
Every capability below is shipped in Role Central today. Provisional UI snapshots elsewhere on the marketing surface use development placeholders and are swapped for final Role Experience imagery when it lands.
01
Capture
Requests are first-class objects, from the moment they land.
REQ-2841Retainer · SLA 4h · owner Priya
Customer emails, bug reports, change requests and ideas each arrive as a real Role Central Request. Every request carries a title, requester, customer, service, request type, priority and commercial classification — before anyone starts triaging it.
Requests are the operational heart of Role Central. They're what make a delivery team's day interruptible and are the hardest work to keep organised. Role Central assigns each new request a canonical REQ-#### reference, an SLA (where the supporting Service defines one) and a commercial classification (Included, Retainer, Billable, Warranty, or Awaiting assessment).
Requests link to the tasks that fulfil them, the board discussions they trigger, the time logged against them and, eventually, the invoice line they inform. Nothing gets stranded in email.
02
Plan
Projects, milestones, dependencies and RAID.
PRJ · Q1 launchMilestones · dependencies · RAID · health
A project in Role Central is one shared document — customer-visible where it should be, internal where it must be. The overview pulls together health, stage, upcoming milestones and open dependencies; tasks, time, meetings and the risk register (RAID) each have their own view within the project.
The Project Overview surfaces open tasks, current requests, upcoming milestones and current risks in one glance. Customers see their view of the project without leaving Role Central; internal team members see the fuller operational picture.
Projects can produce Support Services on handover: the ongoing relationship inherits enough context that requests raised after launch already know which service they belong to.
03
Schedule
Working hours, capacity and planner blocks.
PLN · Wed 14:002h · Priya · alongside committed work
Deciding what to do isn't the same as deciding when. Role Central's planner treats scheduling as its own surface, respecting each team member's working hours.
Users have configurable working hours; organisations set working-hour defaults and holidays. Planner blocks let individual team members lay out concrete time for the tasks and requests they own, and capacity reports fold that back into a team-wide view.
SLAs pause on statuses like waiting for customer (defined per service), so the clock reflects the work the team actually controls.
04
Deliver
Tasks, contributors, boards and approvals.
TSK-0912Assignee · followers · linked request
Delivery is where most tools stop being useful. Role Central keeps tasks, board discussions, followers, contributors and approvals all connected to the request or milestone they came from — and to the customer they exist for.
Tasks have owners, contributors (internal followers who receive updates without needing to own the work) and links to the project, request or milestone they belong to. Board topics can be shared with the customer or kept internal.
Approvals are first-class: a customer sign-off leaves a real audit trail, not an ambiguous email thread. Approvals link back to the deliverable they concern.
05
Time
Time logs, retainer allowance, real capacity.
TIM · 1h 45mRetainer allowance draws down 1h 45m
Time in Role Central is not a separate timesheet app. It logs against the same tasks, requests and services the rest of the product uses, and it feeds retainer allowance draw-downs and capacity reports without duplication.
Support Services can carry a retainer allowance in minutes per period. Time logged against the service — or against the requests and tasks it originated — draws that allowance down automatically, so both team and customer see the true position in the current period.
Where the work is Billable rather than Retainer, the same logs feed the commercial close (see below) rather than the allowance ledger.
06
Report
Delivery, SLA and capacity, without a separate BI stack.
RPT · MarchSLA · retainer usage · capacity · health
Role Central reports on the surfaces it owns: project health, service SLA performance, capacity utilisation, and the current commercial position. All permission-filtered before aggregation.
Reports are first-party — no external BI tool is required to answer questions like "which services breached SLA last month?" or "which customers are approaching their retainer allowance ceiling?". The dashboards feed the same signals back into the operational surfaces so the founder-facing answer matches the operator-facing one.
07
Commercial close
Close the period. Issue the invoice. Move on.
MAR-CLOSERetainer statement · invoice draft
Every request, task and time entry has been commercially classified since it landed. Commercial close aggregates the billable and retainer records for a period into a frozen snapshot you can preview. From there you draft the invoice — lines pre-populated, editable — and issue it; the result is a numbered PDF.
Recurring charges — hosting, retainers, licences — advance on their own schedule with deterministic idempotency; you can't accidentally double-invoice a hosting fee. One-off billable work aggregates into the same close so nothing is missed.
Once an invoice is issued its snapshot is immutable; historical figures on old invoices don't change because someone renamed a task.
/ The point
The point isn't seven surfaces.It's that a customer bugon Wednesday and the invoice linein March come from the same record.
— from the Role Central design brief
N/07
Next
Reading a use case
might be more useful.
The lifecycle above is the same for every Role Central customer. If you’d prefer to see it in a shape closer to your own team, read one of the use cases.