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:

• Live Service Command Centre — the vendor’s dashboard. Its three top figures are Active Service Revenue, Revenue at Risk and Forecast Service Revenue, each opening the customers, projects and owners behind it; below them, CSAT metrics, customer performance, regional statistics and full-funnel conversion reporting
• Forecast Service Revenue — revenue expected to convert: every project added in the range and still open, each with a Pricing status — Estimated at its package price, the list price of the service it asked for (a monthly price counted as one month; a project whose service carries no list price adds £0), or Expert priced at the price of the selected expert’s quote. When the customer approves the price the project leaves it for Active Service Revenue. It opens to the projects behind it — customer, project source, description, service type, BRD status, owner, Pricing status, package price and expert price — with the Price Book under them and a route into the Live Service Pipeline. It is a live figure in the KPI dictionary too, read on the dictionary’s period, and its entry opens this page on that same period, so the two never state different figures
• Revenue funnel, revenue lost before go-live and top customers — the three cohort figures below the Command Centre’s top tiles, each with its own entry in the KPI dictionary: the leads sourced in the period at the stage each stands at now; the open service revenue on leads that ended before delivery, by the stage and reason they were lost at; and every customer with a lead sourced in the period, with their leads, delivered work, satisfaction and settled spend side by side. In the dictionary each is a live figure read on the dictionary’s period, and its entry opens its page on that same period, so the two never state different figures
• Live Service Pipeline — every service lead in one owned flow (the service leads board, for every role that has one). The vendor’s board opens with “Track every project from initial request through delivery. Select a project to view its details.”, and its search finds a project by name, project ID or customer. Four summaries sit across the top, on every role’s board — Active projects (from initial request through delivery), Service Pipeline Value (the potential value of projects awaiting qualification — every open project, BRD approved or not), Delivery complete (awaiting feedback and CSAT) and Completed projects — and each opens the board filtered to exactly the leads it counts. The same four are live figures in the KPI dictionary, counted and valued exactly as the board counts them; they are stocks, so they do not move with the dictionary’s period, and each entry opens the board on the leads it counts with no saved list filter applied
• 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 organisation’s currency (the Default currency setting), whoever is signed in; an engagement priced in another is left out and its count is stated beside the figure rather than converted at a rate nobody agreed
• Customers at renewal risk — A health score out of 100 for every customer. The card leads with the average of those scores, out of 10 and coloured by the band it falls in, with the count of customers at renewal risk beneath it; customers who carry no score are left out of the average. 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

In the agentic app: The vendor is briefed before they ask. Opening it shows the leads they sourced in the last 90 days as a checkable figure, how far those leads got through the funnel with each lead counted once, the ones qualified out, and their lead book as it stands with its value per band — added as stored, never converted between currencies. Then comes the assistant’s reading: where most of the group stopped, the assumption to test first (a newer group has had less time to convert), and which band carries the most live work, with buttons to run the same funnel over another window, see the leads in a band or open the lead board. When the window sourced nothing, the briefing says so and shows the book; with no leads at all it offers creating one.

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
• Their overview — Ten cards on their active project, each opening to the records behind it: where the project stands, the go live date, their team, what is waiting on them, how much is done, what could go wrong, how the work has felt, what they have paid, the latest update, and the changes agreed. The header states the range and the moment everything was read at, once for the whole screen, and every card carries that range into the page it opens
• The figures behind a card — Six pages, one for each card that states a number: how much is done, go live, things for them to do, what is holding the project up, what they have paid, and the changes recorded. Each says what the figure is, how it is worked out, lists every record behind it adding up to exactly the figure, and reconciles the figure at the start of the range to the figure now with every movement itemised. Nothing is created, acknowledged or paid from these pages — a row hands over to the project or the bill it is about. Every word on them is the customer’s own: an outcome nobody has started reads “Not started yet” and one that is held up reads “Held up”, never an internal stage name
• 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. What they were quoted, what they have been billed and what they have actually paid are three separate figures, named apart and never added together
• 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”)
• Being able to check a figure for themselves rather than asking their manager what is behind it
• Transparent pricing via quotes and invoices
• Quality of the assigned expert

How they interact with AI: When a request is raised, its next action reads Complete customer conversation: the platform hands the customer to the assistant, which opens the conversation about that request itself and asks one question at a time — often with clickable answers — to write the business requirements. The customer submits the resulting BRD before it goes for review and on to the bid pool, and the conversation stays readable on the request.

In the agentic app the customer has a register of their own, Project Discovery, which both reads and writes: their own requests and the stage each is at, the requirement document as a card of field rows showing what is recorded and what is still open, and where a request has got to on the journey in their own words. They write the overview and the requirements in conversation, along with what they need, their industry, where, the languages, when they need it and an indicative budget. The card fills in as they answer, and anything the register worked out for itself is marked as inferred with the reason shown beside it. Submitting is theirs alone — the register asks, the customer authorises, and only then does the document go for approval, with the drafted rows written onto the request in the same step. Service and product are set when the request is raised; the register never changes them.

Project Discovery speaks first. Opening the agentic app shows the customer’s requests and the stage each has reached, and, when one is still being written, the requirement document on the newest of them — what is recorded and what is still open. Then comes a reading in plain words of what the document still needs and what happens next, with buttons to carry on writing it, see what is missing, see where a request has got to or open it on the platform. Nothing in the briefing submits anything. A customer with no requests is told so and offered the page where a new one is raised.

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.

Every expert is also Internal, Partner or Freelance, and carries an indicative day rate in their own currency. Internal follows their employment — an internal expert sits in the organisation’s reporting hierarchy; an external one is a Partner or Freelance specialist (Freelance until someone says otherwise). Admins and SDMs set the class and the day rate on the expert’s profile; the expert sees both, read-only, on My Knowledge. The SDM reads them on each matched expert’s card, beside vetted status, experience, availability, location and past CSAT, and the class appears on each bid.

What they see:

• Bid Pool — Available leads matching their expertise, open for proposals
• Proposals — Their submitted proposals with status tracking
• Projects — Their projects, active and completed, 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); their engagement class and indicative day rate, read-only
• My Team — Team members and collaborations
• Work queue — Their own overview: the work awaiting their action, the bid pool, their active projects in delivery and to close out, and their earnings and quality. Every card on it opens to the engagements, invoices or scores behind its figure — all of it their own work, and none of it anyone else’s
• Active projects — Every approved project they have in progress, reached from the Work queue’s cards; the rows that also need their action are marked as needing attention

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.

How delivery works: Once a bid wins and the quote is accepted, the project workspace’s Delivery section becomes the expert’s working surface, and the Proposals section drops away — the bid is settled, and the milestones are the engagement now. From each milestone the expert advances its delivery status and, once it is complete, raises its invoice. See Delivery.

In the agentic app the expert is briefed before they ask. Opening it shows their bid pool triaged — each open lead’s verdict and why, their fit, the service’s list price and the days left to bid — with how much of the pool looks worth their time, then the assistant’s reading: the lead worth bidding on now and why, and which ones to pass on. Its buttons open a lead’s bid form or bid page on the platform, or ask what to clarify before bidding — never the price, which comes from the catalogue, not the customer. With nothing in the pool, the briefing says so and turns to the work they already have in flight.

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:

• Go live control — The CSM’s overview: their portfolio of active customers, the customers blocked and who is blocking each, the customers at risk of missing go live, and the follow-up threads on them. Every card opens to the customers behind its figure, and each figure has one name — Portfolio, Blocked customers, Customers at risk of missing go live — on its card, its popover and its page. A card that states a figure opens a page giving that figure with its sub-figures, what is counted in and taken out, a register of every customer behind it that adds up to exactly the figure, and a reconciliation of how the figure moved since the start of the selected range with every movement itemised to the account. The header states the range, the scope and the moment everything was read once for the whole screen; every figure on it is a count as at that moment, so the range changes none of them — it is the window the movements on the drill-down pages are read over. Where the platform cannot record something the page says so plainly: an account the health engine has not scored is stated separately rather than counted as healthy, and a reconciliation whose opening the platform does not hold names the day its record begins instead of inventing one
• Leads Management — Full lead pipeline with ability to create, assign, and progress leads
• User Management — Manage team members and assignments. The list is segmented — all, customers, managers (CSM and SDM), experts, vendors — with a live count on each segment and the columns that segment needs: a customer’s company and open leads, a manager’s team size and portfolio, an expert’s skills and rating. The segment sits in the address bar, combines with search and the scope filters, and is remembered between visits. Opening anyone gives the whole person on one page, in tabs: Overview (their contact and profile data and the key figures), Leads and requests (every lead they are the customer, CSM, SDM or expert on, each linking to its workspace), Finances (their quotes and invoices, each list totalled), and History (their activity trail). Who brought them in is named in the header wherever an inviter was recorded. The segment you arrived from decides which tab opens first
• Activity Tracking — Monitor all activities and status changes
• Finances — Quotes, invoices, and financial reporting
• Products — Service catalogue management
• CSAT — Customer satisfaction scores and trends
• Configuration — The settings hub, including a Skills tab for the 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.

In the agentic app the CSM is briefed before they ask. Opening it shows what is blocked — the open go-live blockers across their accounts and the revenue those accounts carry — then the assistant’s reading of it: the one account worth the next two minutes and why, with buttons for the moves that follow, such as what they can do on that account or its page on the platform. With nothing blocked, the briefing says so and shows the portfolio instead. The briefing becomes a saved conversation only when the CSM replies to it.

In the agentic app the SDM is briefed before they ask. Opening it shows coverage across their pools, worst first, and how many pools no available expert can cover, then the assistant’s reading: the uncovered pool worth their next move and why. The assistant cannot put a value on uncovered demand, and says so; a button opens the platform’s uncovered demand value figure, where it is valued, and others ask what a pool’s brief would need or whether price is the problem. With no active demand in their area, the briefing says that instead.

SDM (Service Delivery Manager)

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

What they see: The CSM’s capabilities on the delivery and portfolio surfaces, plus expert management — and, alone among the two, the bid pool:

• Proposals — Every bid on a lead, and the accept/reject decision on each, from the lead workspace and the /proposals list. This is the SDM’s alone: the SDM selects the expert, and accepting the bid sends the quote to the customer. The CSM sees no proposals — only how many bids are in, on the lead’s Quote section, until the quote exists.
• Their leads from the first bid — The customer’s approval of the requirements hands a lead with no SDM to the active SDM carrying the fewest leads from bidding through the survey, who is told it is theirs (Requirements). Assign SDM changes it by hand.
• Go live readiness, opened up — Every card on the overview at /sdm opens the supply behind it: leads in the area opens those leads, go live demand the work waiting to be covered, gaps not covered and quote and bid readiness the coverage pools behind each shortfall — a pool is one product in one region and language, named by those three — go live risks and immediate risks the pools that will hold a go-live up, uncovered demand value what that exposure is worth, expert strength one row per expert, average bid price every bid behind the average, and service revenue every paid invoice behind the revenue. Each figure keeps that one name on its card, its popover and its page. Each page states the figure, what it counts and leaves out, a register of every member that foots to it, and a movement across the range showing what entered and left, itemised and dated. The range, whose supply the screen is about, and the moment it was read are stated once at the top and carried into every page
• Expert performance — Bid success rates, delivery timelines and CSAT scores per expert, each opening to one row per expert with the counts behind every rate, so a register of experts foots on numerators and denominators rather than on an average of percentages
• Delivery oversight — Milestone progress across active projects
• Quality control — Reviewing flagged BRDs and proposals

Where a figure is derived from the live coverage grid, which keeps no history of its own, its movement is read from a nightly record of that grid. Until the first night’s record exists, those pages say so plainly rather than inventing an opening figure.

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
• Platform setup, opened up — Every figure on the overview at /admin opens the tenant-wide detail behind it: configuration gaps open the go-live checks, SLA coverage the service stages, connected integrations the catalogue, the user count the directory, and the notification signal the failed sends. Each page states the figure, what it counts and leaves out, a register of every member marked in or out with the figure footing to it, and a movement across the range showing what entered, itemised and dated. Where a change has no date recorded — removing an SLA definition, deactivating a person — the page says so rather than showing an empty table. Cards that state a status rather than a figure open the settings area they summarise. Go-live readiness at /admin/setup is computed from the tenant’s real configuration — catalogue, SLAs, service model, integrations, roles, and every active service carrying a list price in the organisation’s currency (the Default currency setting) — never from boxes ticked by hand; a service priced in another currency counts as unpriced, and the gap says how many have no price and how many need repricing
• Settings — A single consolidated settings hub at /admin/settings with a tab per configuration area (tenant settings, locations, services, products, industries, skills, commercial, SLA, automations, integrations, role templates, scope and licences, statuses, demo data). Tenant settings are backed by a canonical registry, so every default setting is present and discoverable. Each person sees only the tabs they can open, and opening Settings lands them on the first of them — a CSM or SDM on Services, an admin on the tenant settings
• 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 Live Service Command Centre, 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. The list is segmented — all, customers, managers, experts, vendors — each with a live count; administrators appear under all rather than as a segment of their own. Every user’s profile carries the same tabs a CSM sees — Overview, Leads and requests, Finances, History — plus an Access and roles tab that is the administrator’s alone: it holds the reporting line, primary and extra roles, and the per-user permission matrix. A tab someone may not see is absent from their profile rather than shown disabled
• System Configuration — Automation rules and tenant-level settings

Unique capabilities:

• Read every KPI definition behind the Live Service Command Centre 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 (the profile’s Access and roles tab) — 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; the user is notified of their new role, named by its label (“Your role has been updated to CSM”), whether the change was made here, in the console or in the identity provider; 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 (the profile’s Access and roles tab) — a per-user permissions matrix 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 that holds it is admin-only, and the admin superuser is all-granted and cannot be overridden

In the agentic app the administrator is briefed before they ask. Opening it shows this month’s assistant spend against the last month that carried any, and where the month has gone agent by agent, then the assistant’s reading: where the month lands, and what is trimmable — failed and refused turns, heavy tool use — and what is not. No spend limit is recorded, so the comparison is always with the workspace’s own last month, and the assistant changes nothing. With no earlier month to compare with, the briefing says so and shows this month’s spend.

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.
• A primary-role change made directly in the identity provider never overwrites a role the person already holds. A single-role user’s role is updated in place on their next sign-in; a multi-role user is given the new role alongside the roles they hold, created from their verified email address, and their existing roles stay as they are until an administrator revokes one. If their address is unverified, they are asked to verify it before signing in.

Seeing another persona’s view

An admin sees their own view and nothing else: the platform has no way to view it as another person or role. To walk another persona’s experience, sign in as that person on the demo host, where every persona is a seat with a real sign-in of its own (see Demo environment). Pages that belong to one persona, such as the vendor’s Live Service Command Centre, open only for that persona.

Role-Based Data Visibility

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

The CSM and SDM sit in one column on every row but proposals: the bid pool and the accept/reject decision on each bid are the SDM’s, and the CSM holds no proposal permission at all. The CSM’s commercial view of the same engagement is the quote, which names the winning expert and the accepted amount. The SDM handles everything with the expert; the CSM everything with the customer, the quote’s questions and decision included.

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 Live Service Command Centre pages, for instance, are vendor-only routes, which an admin does not open). The feature role matrix breaks both gates out per feature area, and /admin/settings/scope renders the live per-tenant answer.