Experts
The expert as a person on the platform — the directory they appear in, the evidence they submit, and the scores they carry. Their own profile data has its own pages: Expert knowledge and Expert experience. See Reading the tables for the conventions.
Capabilities
| Capability | Gate | Admin | CSM | SDM | Expert | Vendor | Customer |
|---|---|---|---|---|---|---|---|
| View the people on an engagement | people.view | ✔️ | ✔️ | ✔️ | ❌ | ❌ | ✔️ (own) |
| See a lead’s expert match set | match.override | ✔️ | ❌ | ✔️ | ❌ | ❌ | ❌ |
| Add an expert to a lead’s match set | match.add | ✔️ | ❌ | ✔️ | ❌ | ❌ | ❌ |
| Rate an expert on a delivered lead | expert.rate | ✔️ | ❌ | ❌ | ❌ | ✔️ | ❌ |
| Set an expert’s class and day rate | expert.editEngagement | ✔️ | ❌ | ✔️ | ❌ | ❌ | ❌ |
| View CSAT scores | csat.view | ✔️ | ✔️ | ✔️ | ❌ | ✔️ | ✔️ (own) |
| Submit a CSAT score | csat.submit | ✔️ | ❌ | ❌ | ❌ | ❌ | ✔️ |
Match curation is the SDM’s job, not the CSM’s: the SDM handles everything with the expert,
the CSM everything with the customer. Expert Match, the bid pool and the expert’s class and day
rate are what split the two manager roles. Rating a delivered expert belongs to the vendor.
Experts hold no csat.view of their own: their scores reach them through their engagement, not
through the CSAT surface. A CSAT entry records two parties, its customer and its vendor, so an
own-scoped csat.view grant to any other role shows nothing rather than the tenant’s responses —
which is what lets /csat derive its gate and admit a per-user grant.
Viewing and submitting are independent. A survey’s own page opens for a customer who holds either
permission: csat.submit gets them the form while their survey is outstanding, and a short
confirmation once it is answered; reading any response, their own completed one included, needs
csat.view. So a customer whose csat.view is revoked can still answer their own survey, and one
without csat.submit reads it instead of being handed a form they cannot send. The CSAT list
stays on csat.view alone.
The match set is read on the Customer Service Journey, in a Matching section between Requirements and
Proposals: the shortlist the matcher produced, in ranked order. It is gated on match.override
rather than on a view permission of its own — there is no match.view, and the permission’s name
predates the retired score override — so a per-user grant opens the section and its data together.
The matcher shortlists an expert only when they list the lead’s product and are available with room under the organisation’s active-project cap, and the shortlist is ranked on approved certifications on the lead’s product, then how many of the lead’s skills the expert holds, then the Industry, Location + language and Capacity ticks below, then past CSAT — no score is involved. Expert matching sets out every field it reads, each filter and ranking key, the cap setting and invited experts, traced to the code.
Each shortlisted expert is one card. It shows, in this order: their place on the shortlist (“#1 of 3”), the expert’s engagement class, whether they are vetted, one line of experience (position and years), their availability (with the earliest start date and weekly hours where recorded), their projects, their location, their indicative day rate, their past CSAT out of 10, with the number of responses behind it, their industries and how many of the lead’s skills they hold (“2 of 3 the lead needs”). Every line says so when the profile has nothing to show — “Cost not set”, “No CSAT yet”. An expert is vetted when at least one piece of their evidence is approved and not expired; past CSAT is the average of the completed customer CSATs on the leads they delivered. Neither is stored on the profile — both are read from where they already live.
The projects line reads “14 completed · 1 active”: completed counts the expert’s leads in this tenant that reached delivery or later (delivered, survey sent, completed); active counts the leads they are delivering now, leaving out any that has been delivered or qualified out. The matcher’s capacity filter reads the same active count, so the card and the matcher never disagree.
Under the lines, four criteria ticks say whether the expert meets what this lead asks for, each met or not met, with a plain reason that opens on hover, keyboard focus or a tap (the full rules: Expert matching):
- Product — the expert holds at least one approved vendor certification on the lead’s product, and the reason gives the count (“3 scheduler certifications”) — the count is the expert’s level on that product. Listing the product on the profile is not enough: an expert who does but holds no approved certification on it reads “Knows scheduler · no certification”.
- Industry — the expert serves the lead’s industry.
- Location + language — the expert is in the lead’s country (or, when the lead names only a region, its region) and speaks at least one of the lead’s languages.
- Capacity — the expert is available and below the organisation’s active-project cap (3 unless changed on Settings → Matching).
A lead that names no product, industry, location or language asks nothing on that point, so the tick is met. Price and CSAT stay figures on the card, not ticks.
Engagement class and day rate
Every expert is Internal, Partner or Freelance. Internal is the expert’s employment — an internal expert sits in the reporting hierarchy, and an admin changes that on the profile’s reporting line. An external expert is a Partner or a Freelance specialist, and one nobody has classified yet counts as Freelance. The indicative day rate is what a day of the expert’s time is expected to cost, in the expert’s own currency.
Admins and SDMs set both on the expert’s profile (/users/[id] → Overview → Engagement); anyone
else who can open the profile sees them read-only. The expert sees their own class and day rate on
My knowledge, but cannot change them. The class also appears beside each bid on the Proposals
section — except to the customer. Neither the class nor the day rate changes the ranking, and the
class changes no price.
Surfaces
| Page | Gate | Admin | CSM | SDM | Expert | Vendor | Customer |
|---|---|---|---|---|---|---|---|
/users, /users/[id] | explicit — full-tenant directory, staff only | ✔️ | ✔️ | ✔️ | ❌ | ❌ | ❌ |
/expert-evidence | explicit — the evidence review queue | ✔️ | ❌ | ✔️ | ❌ | ❌ | ❌ |
/csat | derived from csat.view | ✔️ | ✔️ | ✔️ | ❌ | ✔️ | ✔️ |
/admin/users | explicit — admin config surface | ✔️ | ❌ | ❌ | ❌ | ❌ | ❌ |
There is no standalone experts table: experts appear in the tenant-wide user directory at /users
alongside every other role. That directory renders full-tenant PII with no per-persona scoping,
which is why it carries an explicit staff-only list rather than deriving from people.view. /csat
carried the same explicit list for the same reason until its pages learned to narrow on the
viewer’s resolved scope.
An expert’s profile at /users/[id] is tabbed — Overview, Leads and requests, Finances, Access
and roles, History — and the tabs narrow within that staff-only rule rather than widening it.
The rule is a path prefix, so it admits any of the three staff roles to every tab’s URL; each tab
re-checks its own permission and redirects rather than relying on being hidden from the strip.
Access and roles needs tenantConfig.manage, which is why an expert’s reporting line, roles and
permissions are the administrator’s to see and a CSM’s profile of the same expert has four tabs
rather than five.
Submitted evidence is reviewed at /expert-evidence by admins and SDMs. A certification names
the one catalogue product it covers — the expert picks it when adding the certification on My
knowledge, and the review queue shows it beside the item. Only an approved certification with a
product counts towards the Product tick; drafts, submitted and rejected items, and certifications
added before products were asked for, count for nothing.
The expert’s own surfaces are separate from the staff ones above, and no other role reaches them, an administrator included, as with the vendor’s.
| Page | Gate | Admin | CSM | SDM | Expert | Vendor | Customer |
|---|---|---|---|---|---|---|---|
/expert | explicit — the role home | ❌ | ❌ | ❌ | ✔️ | ❌ | ❌ |
/expert/figures/… | explicit — persona surface | ❌ | ❌ | ❌ | ✔️ | ❌ | ❌ |
/expert/work | explicit — persona surface | ❌ | ❌ | ❌ | ✔️ | ❌ | ❌ |
/expert/bids | explicit — persona surface | ❌ | ❌ | ❌ | ✔️ | ❌ | ❌ |
/expert is the expert’s Work queue. Every card on it has exactly one destination: a card that
states a figure opens the page behind that figure, and a card that states none opens the surface
its rows live on — /expert/work for their Active projects, /expert/bids for the pool they
bid into.
/expert/figures/<figure> is one route covering every drill-down page behind a Work queue card.
Fifteen exist:
| Page | The card it opens from |
|---|---|
/expert/figures/overdue | Overdue |
/expert/figures/escalated | Escalated |
/expert/figures/due-today | Due today |
/expert/figures/customer-waiting | Customer waiting |
/expert/figures/earned-this-month | Earned this month |
/expert/figures/paid | Paid |
/expert/figures/awaiting-payment | Awaiting payment |
/expert/figures/in-delivery | In delivery |
/expert/figures/at-risk | Revenue at risk from delays |
/expert/figures/earnings-by-state | Earnings by state |
/expert/figures/payout-cycle-time | Average payout cycle time |
/expert/figures/csat | CSAT |
/expert/figures/platform-rating | Platform rating |
/expert/figures/repeat-work-rate | Repeat work rate |
/expert/figures/rework-rate | Rework rate |
Each states the figure and its sub-figures, how it is worked out, a register of the records behind it that foots to the figure, and a bridge reconciling the figure at the start of the selected range to the figure now — its chart and totals on view, each movement’s records opening on demand. Like the vendor’s, they are reporting surfaces only: nothing is created, edited or approved from one, and a row hands over to the record’s own page.
Two things the expert’s pages hold to that are particular to their money. Earnings figures are never summed: what they have been paid and what is awaiting payment are invoiced money, while work in delivery and work at risk are the contracted value of engagements that have not been invoiced, and adding the two families would count the same engagement twice. The Earnings by state card draws the four against the widest of them and states no total, and its page foots each family separately. Two figures read on their own window rather than the header’s range — earnings this calendar month, and the payout cycle mean over every completed engagement — and each says so on its face.
Creating and administering expert accounts — inviting them, changing their primary role, granting extra roles or per-user permissions — is an admin capability on the user detail page; see Roles → Admin.