Roles

Sustentus is a multi-perspective platform. Every user belongs to one of six roles, each with a distinct view of the service journey and a different set of capabilities in the platform.

Vendor

The organisation that sources service leads and manages customer relationships. Vendors are the primary paying subscribers of the platform.

What they see:

• Dashboard — CSAT metrics, customer performance, regional statistics, and full-funnel conversion reporting
• KPI dictionary — Every KPI on the dashboard, with the question it answers, what is and is not counted, the period it covers, and the records behind it. Each dashboard section also opens its own definition where the number stands
• Service activation rate — A live figure on the dashboard and in the dictionary: of the leads sourced in the period, the share that went on to become active delivery work. Opening it shows how far the whole group got, where the rest were lost, and the individual leads behind every count, which add up to exactly that count
• Revenue delivered — The contracted value of the engagements that reached delivered in the period, with the count of those same engagements beside it and twelve months of history behind it. An engagement counts only once every milestone is complete, the customer has acknowledged each one, and every bill against it is settled
• On-time delivery rate — The share of those engagements delivered on or before the date agreed with the customer, with four delivery-quality counts behind it: delivered on time, delivered to plan, escalation-free, and billed without query. These are what happened; satisfaction is what the customer said, and the two are reported side by side rather than merged
• Satisfaction average and revenue-weighted satisfaction — The mean of the scores customers recorded in the period, shown beside the same average weighted by what each customer actually paid, with the difference between the two stated rather than left to be worked out. The weighted figure never appears without the share of collected spend it covers, and neither figure is published below three responses — until then the surface says how many it has, how many it needs, and which surveys are still unanswered. Both open to the records behind them: one row per response with the improvement suggestion where one was left, and the top customers with their collections
• Active service revenue — The dashboard’s money tile and its entry in the dictionary: the contracted value of every engagement accepted and not yet settled or ended, as at the moment it was read. It is labelled a stock rather than a monthly figure, because it is a snapshot of work in flight and adding it to a period total would say something untrue. It opens to the four delivery stages that work sits in — every engagement in exactly one, so the rows add up to the figure — and beneath those, the engagements themselves with their contracted value, stage and days in stage. Every money figure a vendor sees names which money it is: value delivered, value committed but not yet billed, value billed, or value the customer has actually paid. No two of them are ever added together or compared. Figures are read in the vendor’s own reporting currency; an engagement priced in another is left out and its count is stated beside the figure rather than converted at a rate nobody agreed
• Customer health and churn risk — A health score out of 100 for every customer, and beside it the count of those at renewal risk. The score is four things weighted together: how satisfied the customer is, how recently they engaged, how reliably work was delivered to them, and which way their spend is moving. Each part is shown with the records behind it, and the four add up to the score they sit beside. A customer is flagged when their health is red, or amber with collected spend down more than 15% on the equivalent previous period, and the figure that triggered the flag is on the row. Where a part has nothing behind it — no delivered work yet, no satisfaction response, nothing collected in either period — the customer is not scored zero on evidence that does not exist: they carry no total, are listed on their own with every reason stated, and are left out of the at-risk count rather than counted as safe. Nothing is stored and nobody, administrators included, has any way to adjust a score, a weight or a band
• Retention by delivery speed and region — Of the customers who had work delivered in the previous period, the share who started something new in this one, cut two ways: by how fast their work was delivered, and by where they are. Every bucket carries the number of customers in it, so a bucket of three never reads like a bucket of thirty, and both cuts add up to the same population and the same number of returners. Delivery speed is the customer’s median delivery time — whole days from the day the lead was sourced to the day the work was delivered, counted as whole calendar days in the vendor’s own time zone rather than as elapsed hours. Customers are grouped by the country recorded on the engagement itself, so someone who moves country stays counted where they were and a finished period never moves. Where no country was recorded, or where a country belongs to no region, the customer appears in an unknown-region bucket that is always shown — never quietly folded into a named region and never given the vendor’s own. A rolling twelve-month figure sits alongside with its own customers and its own returners, and is not repeated when the twelve months is already the period being looked at. Opening any bucket lists the customers in it, returned and not, adding up to exactly the counts on the row
• Revenue at risk — What the flagged work in flight is worth, stated as a labelled slice of active service revenue rather than a second pot beside it, so the two are never added together or compared. An engagement is flagged when its customer is at renewal risk, when it has sat over 30 days in one stage, or when that customer’s mean satisfaction is 2 or below on the five-point scale they answer on — and it counts once however many of those it carries, so work that is both late and unhappy is counted once, not twice. Each flag is shown with its own total and count, and the screen says in words that adding those totals together means nothing, because the flags overlap by design. It opens to the engagements themselves, each listed with every flag it holds, adding up to exactly the figure shown. Two things it deliberately does not claim: delay against a date agreed with the customer, which work in flight carries none of, so days in stage stands in and is named on the definition as the weaker test; and scope reductions, which are recorded nowhere and so are not measured at all rather than estimated. Work already delivered is out — the risk left with it — and an engagement priced outside the reporting currency is left out and counted aside exactly as it is on active service revenue. The two thresholds are shown on the definition and change by migration and deploy, never in the product
• Leads — All leads across the pipeline with status, assigned expert, and timeline
• Customers — Customer list with invitation management and relationship tracking
• Team — Internal team members and territory assignments
• Create Lead — Multi-step lead creation form for manually sourcing leads

What they care about:

• Conversion rate at every stage of the funnel (lead → activated → engaged → bid pool → delivered)
• Time-in-stage metrics and bottleneck identification
• Bid response rates — are experts engaging with their leads?
• CSAT scores from completed projects

How they onboard: Vendors sign up via the marketing site, selecting a subscription tier (Self-Service, Growth, Managed, or Partner). On signup, a tenant is provisioned with isolated data, configurable workflows, and embeddable lead capture forms.

Customer

The end-user requesting a service. Customers are typically introduced to the platform by a vendor.

What they see:

• Projects — Status and details of their active and completed projects
• Milestones — Each milestone on their project, and a way to acknowledge a completed one as done. Acknowledging changes nothing about the project; it is how delivery is counted as finished rather than only reported as finished
• Finances — Quotes, invoices, and payment history
• Create Request — Submit a new service request (lead)
• Help Centre — Support resources

What they care about:

• Progress on their service request — where is it in the journey?
• Confirming for themselves that a piece of work is genuinely done
• Clear, jargon-free status updates (not internal terminology like “bid pool”)
• Transparent pricing via quotes and invoices
• Quality of the assigned expert

How they interact with AI: When a lead is created on their behalf, the customer logs in and engages with the BRD Agent. The agent asks one question at a time to gather business requirements, covering seven topics in sequence: business context, goals and success criteria, target audience, current approach, budget and timeline, systems and integrations, and stakeholders. The customer approves the resulting BRD before it enters the bid pool.

Expert

The service provider who bids on and delivers projects. Experts maintain their own profile in My Knowledge — seniority and years of experience, the industries they serve, the skills they can deliver with a proficiency level and years for each, products, and structured availability — plus bank details for payouts. These datapoints make experts matchable to the right leads.

What they see:

• Bid Pool — Available leads matching their expertise, open for proposals
• Proposals — Their submitted proposals with status tracking
• Projects — Active projects with milestone progress
• Invoices — Invoice creation and payment tracking per milestone
• My Knowledge — Profile and matchable expertise: position, bio, seniority and years of experience, industries served, skills with a per-skill proficiency and years, products, and structured availability (weekly capacity, earliest start date, work mode)
• My Team — Team members and collaborations

What they care about:

• New leads in the bid pool that match their skills
• Status of their submitted proposals (pending, accepted, rejected)
• Milestone completion and payment status
• Earnings and payout tracking

How bidding works: Experts browse the bid pool, review the BRD attached to each lead, and submit a proposal with a title, summary, price, timeline, and milestones. Multiple experts can bid on the same lead. If an expert finds a BRD unclear or problematic, they can flag it for manager review rather than submitting a blind bid.

CSM (Customer Success Manager)

Internal customer-facing role. CSMs ensure engagement quality and step in when the automated process needs human intervention.

What they see:

• Leads Management — Full lead pipeline with ability to create, assign, and progress leads
• User Management — Manage team members and assignments
• Activity Tracking — Monitor all activities and status changes
• Finances — Quotes, invoices, and financial reporting
• Products — Service catalogue management
• CSAT — Customer satisfaction scores and trends
• Skills — Skills linked to the services they support

When they get involved:

• An expert flags a BRD as unclear or problematic
• A customer goes cold during the engagement phase
• A lead has been sitting in the bid pool with no proposals
• A dispute arises during project delivery

CSMs handle exceptions, not the standard flow. The goal is for AI and automation to handle the process while CSMs focus on the 5–10% of cases that need human judgement.

SDM (Service Delivery Manager)

Internal expert-facing role. SDMs manage expert performance and delivery standards.

What they see: Same capabilities as CSM, with an emphasis on expert management:

• Expert performance — Bid success rates, delivery timelines, CSAT scores per expert
• Delivery oversight — Milestone progress across active projects
• Quality control — Reviewing flagged BRDs and proposals

When they get involved:

• An expert is underperforming or missing milestone deadlines
• Proposal quality is low and needs coaching
• Expert pool gaps — no suitable experts for a category of leads
• Onboarding new experts and verifying their qualifications

Admin

Platform administrator with full system access.

What they see:

• Everything — Full dashboard with system-wide analytics
• Settings — A single consolidated settings hub at /admin/settings with a tab per configuration area (tenant settings, locations, services, products, industries, commercial, SLA, automations, integrations, role templates, scope and licences, statuses, setup checklist, demo data). Tenant settings are backed by a canonical registry, so every default setting is present and discoverable
• Status viewer — A read-only view of the status workflow in the statuses tab at /admin/settings/statuses
• Metric registry — A read-only register at /admin/metrics of every KPI definition behind the vendor dashboard, grouped exactly as a vendor sees them, plus the definitions that are a denominator rather than a headline
• Role templates — An editor in the role templates tab at /admin/settings/role-templates for the default permissions each role holds; edits take effect on affected users’ next request and the admin role is a read-only superuser
• Scope and licences — A read-only view in the scope and licences tab at /admin/settings/scope of what every role can do and which surfaces each can open, read live from the same permission templates the platform enforces, so editing a template changes the view on the next request. Licence classes are shown as groupings over capability, and are reporting only — no licence ever blocks anyone from signing in or working
• Snapshot Management — Create, restore, and manage database snapshots (demo tenants)
• User Management — Create and manage users across all roles
• System Configuration — Automation rules and tenant-level settings

Unique capabilities:

• Read every KPI definition behind the vendor dashboard in the metric registry — and only read them. Changing a definition is the only write anyone has over these numbers: no role, admin included, can enter, adjust or override a reported figure
• View the status workflow — statuses, transitions, and per-persona labels are defined in version-controlled JSON (packages/services/src/db/workflows/workflows.json) and changed in-repo via a pull request, not edited at runtime; the statuses tab at /admin/settings/statuses is a read-only viewer
• Edit role templates — change the default permissions each role holds from the role templates tab; every change is audited and applies to affected users on their next request, and the admin role’s own template is a read-only superuser set so an admin can never be locked out
• See the whole permission model on one page — the scope and licences tab renders every role’s effective capabilities and the surfaces each can reach, derived from the live templates and route rules rather than written down separately, including the sub-paths a more specific rule narrows. It grants nothing and changes nothing: permissions are still edited in the role templates tab, and per-user exceptions are not shown there
• Configure tenant-level settings
• Manage demo environments with snapshot create/restore
• Access audit logs and system health information
• Change a user’s primary role from the user directory (user detail page) — pick a new role and the change is written through to the identity provider and mirrored immediately, so the user’s effective permissions follow the new role on their next request; demoting the tenant’s last admin is blocked, and every change is audited
• Grant or revoke a user’s extra roles from the same user detail page — this manages the roles a person can switch into, separate from the primary role above and from role templates (which set each role’s default permissions); a user’s last remaining role can never be revoked
• Grant or revoke a single user’s permissions from the user directory (user detail page) — a per-user Permissions tab shows that user’s effective permissions as a matrix, with each cell’s provenance (inherited from their role template, individually granted, or individually revoked); toggling a permission writes a per-user exception that applies on the user’s next request and is audited, without touching role templates or other users of the same role. The tab is admin-only, and the admin superuser is all-granted and cannot be overridden
• View As any persona or a specific user in their own tenant from a single login — walk the platform exactly as that user does, without switching accounts (see Admin View As below)

Multi-Role Users

Internal users (admin, CSM, SDM, expert, vendor) can hold more than one role and switch between them in-session — no re-login. A user who holds several roles sees a role switcher in the sidebar user menu with a badge showing their active role; switching lands them on that role’s home. Users with a single role never see the switcher. Customer is external and is not a switchable role.

Because one person can hold several roles, the platform treats them as a single person, not one entry per role:

• Directory and People views show one row per person, listing all the roles they hold — never a duplicate row per role.
• Notifications that target more than one of a person’s roles send a single email, while the in-app notification is available under whichever role they’re viewing.
• Notification preferences and shared identity (name, email, avatar) are held once per person and stay consistent across all their roles.

Admin View As

An admin can view the platform as any persona, or as a specific user in their own tenant, from a single login — no account switching. Picking a persona shows that role’s experience for permission testing; picking a specific user reproduces their exact point of view — their permissions, data scope, persona home, and navigation all resolve as that user, so an admin can walk any of the six experiences without holding a mostly-empty admin-flavoured version of them.

View As lives in one floating control at the bottom right of every page. Idle it is a quiet icon-only button; while viewing as someone it expands to show that person’s name and role the whole time, with a one-click exit beside them, and emulation ends on sign-out. View As is admin-only and never crosses tenants, and every action taken while viewing as someone is recorded against both the admin and the person being viewed, so the audit trail always shows who really acted.

The control opens on the roles — switching role is what it is for — and choosing one presents the people who hold it, by name, so a specific user is two clicks away with no submenu to open. Each role also offers a role template only entry: that role’s permissions with nobody’s data behind them, for permission testing. The list is the same on every tenant. What a demo tenant changes is only the register: while emulating, the control reads as neutral presenter chrome, where any other tenant gets an amber audit warning, because there it sits over real customer data. The admin-only gate, the same-org check and the audit trail are unchanged either way.

Role-Based Data Visibility

The same underlying data is presented differently depending on the viewer’s role.

This table summarises the platform-default role templates in packages/services/src/permissions/defaults.ts. Two things it deliberately does not capture: a tenant admin can edit those templates, and page access is a second gate on top of the permission (the vendor dashboard pages, for instance, are vendor-only routes — an admin walks them through View As, not through a permission). The feature role matrix breaks both gates out per feature area, and /admin/settings/scope renders the live per-tenant answer.