Aurority
I designed Aurority around a fictional fast-growing customer organization where quality had become fragmented across teams and tools. The brief was deliberately simple: understand and improve quality without creating unnecessary bureaucracy.
The problem was bigger than QA.
Aurority has 38 Support agents, 18 Sales reps and 6 Team Leads. Support operates 08:00-22:00 seven days a week; Sales operates weekdays. Customer outcomes are deteriorating, but leadership has no consistent way to distinguish agent performance from process, product, knowledge or system failures.
What leadership sees
- CSAT fell from 4.6/5 to 4.1/5.
- Customers increasingly report inconsistent answers.
- Sales sometimes promises outcomes Operations cannot fulfil.
- 31 Sales-to-Ops handover issues occurred in the previous quarter.
What is missing
- No formal QA department or common scorecard.
- No pass threshold or calibration process.
- Team Lead reviews are inconsistent.
- No central quality reporting or coaching tracking.
- No recurring complaint root-cause analysis.
From operational friction to a usable system.
The primary focus was not to build another QA dashboard. It was to design an operating system that could turn fragmented signals into accountable action while keeping human judgment where context matters.
I started with the breakdowns leadership could already see—declining CSAT, inconsistent answers, handover failures and disconnected coaching—then traced where information or ownership was being lost.
A poor outcome can come from people, process, knowledge, systems, product or commercial decisions. The workflow therefore opens an investigation before assigning blame or prescribing action.
Stable IDs, routing, trigger creation, notifications, due dates and rechecks can be automated. Diagnosis, severity judgment, coaching and cross-functional decisions remain human responsibilities.
Zendesk, HubSpot, Aircall and the other operational tools remain systems of record. Aurority pulls only the structured information required to connect evidence, ownership and action.
Every meaningful issue needs an owner, evidence, a due date, a route for cross-functional requests and a visible status so problems cannot disappear inside Slack threads.
An intervention is not considered successful because a task was completed. The system rechecks the relevant outcome so the team can see whether the action actually improved quality.
Map the work before designing the system.
The first step is not choosing QA software. It is understanding where information is created, where it changes hands, where decisions happen and where context disappears.
Zendesk
Email/chat interactions, tickets, internal notes, tags, escalations and CSAT.
Aircall
Sales and service calls, recordings, duration and interaction references.
HubSpot
Leads, pipeline stages, deal values, loss reasons, ownership and Sales-to-Ops handover.
Slack
Internal communication and escalation. Useful for attention - dangerous as a source of truth.
Notion
SOPs and knowledge. Some pages are eight months stale and ownership is inconsistent.
Looker Studio
Management reporting for CSAT, response times, tickets, conversion and revenue - but no quality layer.
Deputy
Schedules, shifts and team coverage.
Zapier
Automation layer between systems.
Typeform
Ad hoc feedback, onboarding, pulse and training forms without a central quality structure.
Support handover notes are inconsistent. Escalations have no common reporting logic. Sales exceptions can live only in Slack. 1:1s are intended biweekly but are inconsistently held and coaching is not tracked. New hires complete two weeks of onboarding without QA certification or 30/60/90-day quality monitoring.
Centralized does not mean duplicated.
Aurority is not a replacement for the tools where work happens. It pulls only the structured information needed to detect, diagnose, route and recheck quality outcomes.
Capture once
Never ask a human to re-enter data a source system already knows. Add the right structured fields to Zendesk and HubSpot and pull only what the central layer needs.
Structure at the point of creation
Quality improves when contact reason, resolution status, escalation reason, special requirements and handover completeness are captured consistently at source.
Diagnose before prescribing
A falling metric points to an investigation door. It does not prove the cause.
Communicate with fewer words
The central system stores the case. Quality-feed channels carry detail. Normal department channels receive only attention nudges when action is required.
The same symptom can be caused by People, Process, Knowledge, System, Product, Commercial decisions or a customer-specific situation.
Source → Quality Operations → action.
Source systems
Zendesk · Aircall · HubSpot · Product usage · Typeform · Notion · Deputy.
Structured fields are captured where work happens.
Aurority Quality Operations
Business outcomes · trigger engine · Quality Issue IDs · evidence · severity · root cause · owner · interdepartmental requests · actions · due dates · rechecks.
Action surfaces
Dashboards for visibility, quality-feed channels for detailed automation, normal Slack channels for attention nudges, and source tools for execution.
Business outcomes first. QA metrics second.
The top layer answers whether the business or customer experience is changing. Lower layers help explain why.
A trigger starts an investigation.
Expert-defined V1 rules are transparent and testable. They can later be validated against actual outcomes. No fake machine learning is required to make the system useful.
Customer-risk triggers
Absolute thresholds combine with change-from-customer-baseline signals. A single weak signal can stay informational; multiple aligned signals increase severity.
Operational triggers
Repeated escalations, unresolved cases, handover failures, knowledge staleness, conversion deterioration and revenue variance can open investigations.
Critical-event bypass
Some events should bypass normal accumulation rules and route immediately because customer or revenue impact is already material.
Alert-noise control
Trigger usefulness is measured. Rules that generate noise without action can be adjusted rather than becoming permanent notification clutter.
Automation supports ownership. It does not replace it.
Customer-specific issue
The relevant customer-facing team owns the initial investigation. If another department is needed, a linked interdepartmental request transfers the question — not the entire history.
Business-level anomaly
Operations owns initial diagnosis because the cause is unknown. Ops drills into time, segment, source, funnel stage, team, deal size, loss reason and historical comparison before routing.
Root-cause routing
Interdepartmental Requests
Cross-functional work is a first-class object, not an untracked Slack message. Each request carries the sender, receiving department, linked Quality Issue, question/request, priority, response SLA, response, status and timestamps. The receiving team must acknowledge/respond within the defined working-hour SLA; that does not mean every problem must be solved within the same window.
Information ≠ attention
#support-quality-feed
Detailed structured automated notifications live here: issue ID, severity, evidence, owner, due date and status.
#support
Receives only a short nudge when a repeated, high or critical issue needs human attention. This reduces notification blindness.
Fast human input
A short “Report Quality Issue” Typeform captures Department, interaction/customer link, issue type, short description, customer impact and urgency in under a minute. Automation creates the QI ID, routes it and sends the appropriate feed/nudge.
Quality review should create learning, not just scores.
QA scorecard
Communication · resolution · accuracy · process adherence · documentation · ownership · critical failure · overall score · agent_controlled.
Coaching loop
QA finding → coaching action → Team Lead → 1:1 → follow-up review → improvement measured.
Positive quality
The system also records strong examples so QA does not become a database containing only failures.
A low CSAT score is a diagnostic signal. Review the agent's notes and the actual interaction before deciding whether the cause was within the agent's control.
Notion Quality Knowledge Hub
Notion remains the home for standards, scorecards, calibration guidance, QA processes, known issues, training and change logs — not the issue database. Every governed page has an owner, version, last-reviewed date and next-review date.
Enough structure to investigate. No monster database.
The model centers customer and operational evidence around stable IDs, while source references avoid copying recordings or unnecessary source data.
Customer
accounts
users
product_usage
surveys
People
agents
teams
schedules
Interactions
tickets
calls
deals
revenue
Quality Ops
qa_reviews
quality_issues
trigger_rules
trigger_events
actions
interdepartmental_requests
Testing the operating model against real decisions.
01 · Northstar Labs — churn-risk investigation
Customer-specific issue → Support owns initial investigation.
Support reviews agent comments, ticket history, calls/interactions, escalations and attempted resolutions. Both agents followed the documented process correctly. QA scores the work highly and marks the outcome as not agent-controlled. The nine-day case is waiting on Product to resolve a technical issue, while the customer has contacted Support twice asking for updates.
Product owns technical resolution. Support retains customer-communication ownership. Once Product provides the known-issue status, expected resolution and workaround, Support takes the case back, apologizes and can apply policy-controlled service recovery. The recheck asks whether the customer was contacted, the issue resolved, usage recovered, tickets closed and sentiment improved.
02 · Enterprise commercial anomaly
Business-level anomaly → Operations owns initial diagnosis.
Ops drills from time period → segment → region/source → funnel stage → team/rep → deal size → loss reasons → historical comparison. Evidence then determines the next owner. Objection handling can route to coaching; pricing rejection to Commercial/Pricing; missing capability to Product; bad CRM stages to Process/Data.
The receiving department owns its action. Operations retains oversight and closes the loop after the agreed recheck.
03 · Sales handover failure spike
Distributed pattern → investigate Process/System before People.
Because the pattern is spread across the team and clusters around “Special Customer Requirements,” a mass coaching program would be premature. The issue could be interpretation, field format, HubSpot automation or integration mapping.
A broken CRM field does not need six forms, three department heads and a steering committee.
The synthetic stories were tested against the database.
The project includes a relational synthetic dataset, SQLite database and SQL investigations. During validation, the generated handover data was corrected because the first version did not actually reproduce the intended deterioration. The published version does.
Validated scenario signals
- Handover failure: 6.0% → 20.0%
- Enterprise win rate: 47.1% → 22.2%
- Dataset CSAT snapshot: 3.96/5
- Dataset NPS snapshot: 7.37/10
- Open Quality Issues: 3
Repository evidence
aurority.db - SQLite databasedata/ - synthetic source tablessql/ - investigation queriesdocs/ - architecture, operating model and validationdashboard/ - executive dashboard prototype
It makes sure signals do not disappear, ownership is clear, communication loops are closed, and actions can be measured.