AI-powered performance management for distributed teams

Split by user context, not by feature flag

Managers are scanning for team-level problems. Employees are checking their own standing and preparing their next submission. Putting both groups through a single navigation with conditional visibility creates friction for each of them, so the product uses separate route groups from the start, each shaped around a distinct mental model rather than a shared entry point.

Employee route: personal score history, skill breakdown, and last manager feedback.

Manager route: team-level scores, risk flags, and submission status across every rep.

Weighted criteria as the intelligence layer

Every KPI requires a goal, plain-language instructions, and a set of weighted criteria before it can go live. The AI only ever scores against the criteria and instructions a manager actually wrote, so defining a KPI forces managers to produce something most teams never formalise: a structured, weighted definition of what good looks like for a specific role. The AI scores each criterion individually against that definition and rolls the weights up into a final number, so the intelligence lives in the manager's configuration.

Weighting started out manual: managers typed a percentage per criterion and had to make it sum to 100% themselves. That got replaced with an importance picker, Low, Medium, High, or Critical per criterion, with the weight calculated automatically from that level. Managers think in how much each criterion matters rather than doing arithmetic, and the numbers always add up correctly.

The manager authors the goal, the instructions, and marks each criterion's importance. Nothing here is inferred by the model, and the weighting math is no longer the manager's problem.

Projects group KPIs and reports by initiative, each with its own average score, team, and review status. The KPIs view shows those same weighted-criteria bars rolled up across every active goal in the org, so a manager can start from whichever question they're actually asking: which project is at risk, which KPI is dragging the average down, or who on the team needs attention.

The Projects grid — five active initiatives, each surfacing its status and score at a glance.

Inside one project: active goals, assigned team, and full report history in a single view.

The KPIs view — every active goal with its criteria weights and rolling score in one place.

Project Memory — one surface for the agent's context

Early versions had three separate fields: scoring instructions, project description, and a knowledge base. Managers kept asking which one affected scoring. The separation that made sense architecturally created confusion in practice, so all three were collapsed into a single editable textarea. The manager writes in plain language, no structured fields or format requirements. Memory updates are triggered manually rather than after every edit, which prevents a manager from silently changing how their team's work is scored without realising it.

Project Memory: scoring context and instructions live in one plain-language field, updated deliberately via "Update Memory" rather than silently on every edit.

Anti-gaming rules, encoded in the prompt

The real risk with any AI scorer is behavioural: a model that rewards polished writing over real work teaches employees to write better reports rather than do better work. Phrases like "I ensured quality was met" are capped at 5.0 unless backed by specific actions and measurable outcomes. Keyword stuffing is detected and ignored. Prompt injection attempts trigger a forced score of 1.0 across every criterion and surface a flag to the manager. These rules define what counts as evidence, a content design decision encoded in the prompt.

Coaching notes appear only on criteria scoring below 6.0, surfaced inline per criterion rather than collapsed into a summary banner, so the manager sees exactly where the work fell short.

Every criterion score is tied to quoted evidence and a coaching note. A report that never mentions the goal scores 0 on the relevant criteria, no matter how well it's written.

Override as a feedback loop

Most AI tools treat override as a fix for when the model got it wrong. Here it's a deliberate workflow: when a manager overrides a score, both values persist in analytics alongside a mandatory written justification. Optional fields get skipped, mandatory ones create the audit trail. Over time the system builds a trust signal per employee (Likely Inflated, AI Aligned, or Underscoring) based on the pattern of the manager's last eight calibrated reports, so the override becomes data about both the employee and the manager.

Overrides are tracked as their own metric alongside pending review, not buried inside individual reports.

The override modal makes the reason field required. There's no way to change a score without leaving a written record of why.

Employees see the score, not the override reason

Employees see the final adjusted score but not the override reason, deliberately. If they could see the gap between the AI score and the manager score, they'd reverse-engineer what language triggered the override and adjust future submissions accordingly. The audit trail exists for the manager and the organisation, not the person being evaluated.

Team status over team trends

The earlier dashboard showed a radar chart for criteria scores and a trend line across submissions. Both required a minimum number of reports before they were meaningful, and both introduced a display problem: which criteria should appear on the radar, in what order, and what happens when two employees have different scorecards with different criteria sets.

The first fix replaced the charts with per-rep status flags, which solved the team list but exposed a problem one level up: the KPI cards at the top of the dashboard, team average, reports reviewed, needs review, overdue, all carried the same visual weight, so nothing told a manager which number to look at first.

Before: trend line and criteria radar, both needing a minimum number of reports before they meant anything.

An interim iteration: charts replaced with per-rep status flags (Templated Reporting, 2 Missed) before the interface itself caught up.

The fix was to stop treating the chart as a separate element and fold it into the KPI card it belonged to. Team Avg Score became the one primary card, sized and placed first, with its own trend line built directly into it rather than living in a chart elsewhere on the page. Every report-status number, reviewed, needs review, overdue, was consolidated into a single Reporting This Period card with one progress bar, instead of competing as separate stats.

A manager now has one number to check first and one bar to scan for submission health, then can drop into the team list underneath for anyone who needs a closer look.

After: Team Avg Score is the primary card with its own trend line built in, and every report-status number rolls up into one Reporting This Period bar.

An agent instead of more dashboards

After removing the trend chart, the question became: where does depth live? A manager who notices a rep's score declining and wants to understand why has nowhere to go in a dashboard-only product except to open individual reports one by one.

The answer was an agent called Ask Zevian. It is a grounded-retrieval agent: managers query it in plain language, it retrieves only from submitted report content, and it generates its answer from that retrieved evidence. The agent design decision was scoping the retrieval surface itself.

Empty state: scope filter up top, suggested questions the agent can actually answer from retrieved evidence.

"Reading reports…" — the retrieval step is surfaced, not hidden behind a generic spinner.

The answer state: a plain-language response with the specific reports it drew from cited underneath.

The grounding was intentional. Non-technical managers using this product to make decisions about people need to trust that an answer came from something real, so the agent is restricted to retrieval over what the team submitted rather than open-ended generation. The suggested questions on the empty state are all ones it can answer with retrieved evidence rather than assumption. The scope filter at the top, employee group and date range, bounds the context the agent retrieves from, so managers can narrow to one person or one month.

Multi-tenant design

• —Every employee, project, goal, and report belongs to an organization
• —Product could be sold to multiple teams
• —A simple 3 layer hierarchy to define data access for multiple roled managers

KPIs stored as weighted criteria

• —Report scores are stored as individual criterion rows with their own instructions, bundled in a KPI
• —This enabled skill tracking derived per-criterion scores fpr both the organization and per employee

AI that scores evidence

• —The core product risk: if the model rewarded polished writing, the system would become easy to game
• —Addressed with explicit anti-gaming rules: keyword stuffing detection, vague-affirmation penalties, confidence calibration, and padding detection
• —This model improved trust in the system as each scored report was grounded in evidence and the manager's own instructions