Customer Support Supercube

What it is

Support queues grow faster than support teams. The same twenty questions arrive every day in slightly different words, the answer to "where is my order" lives in a different system from the ticket, the knowledge base was last updated when the product looked different, and the one person who knows the refund policy is on holiday.

The Customer Support Supercube sets up a support operation where the agents do the looking-up, the drafting and the sorting, and people do the conversations. It seeds tables for customers, tickets, messages, knowledge articles, macros, products and known issues, returns and satisfaction. It declares agents that triage every incoming ticket, draft a reply grounded in the knowledge base and the customer's own records from the other supercubes, answer the routine cases outright where the company allows it, escalate the rest with context attached, keep the knowledge base current from resolved tickets, and review a sample of conversations for quality. It publishes apps for the queue, the customer view, the knowledge base and the quality dashboard.

Once it is running, a customer emails to ask where their order is. The Triage agent identifies the customer, finds the order in the Supply Chain Supercube, sees the parcel is delayed by the carrier, drafts a reply with the tracking link and the new date, and, because the company allows auto-reply on order status, sends it and closes the ticket. The next email is a complaint about a damaged item; the Triage agent classifies it, pulls the order and the photos, drafts a reply offering the replacement the policy allows, and puts it in front of a person with everything they need. That person spends their time on the complaint, not on finding the order.

Who it is for

Any company that answers customers, from a founder answering a shared inbox to a support team of twenty. Roles that use it are support agents (the human kind), the support lead, product and engineering people who receive escalations, and operations staff who process returns.

For a step-by-step setup, read how to triage support tickets with an AI operating system, from intake and routing rules to a shared queue and human handoffs.

Agents

Data

Data sources

• Channels. Email through Gmail or Outlook shared mailboxes; chat and WhatsApp Business; a help desk such as Zendesk, Freshdesk, Intercom or Help Scout if one is already in use, mirrored two-way.
• Customer records. Orders and shipments from the Supply Chain Supercube; invoices and payments from Finance; deals and account owner from Sales; subscription status from Stripe.
• Product. Bug trackers such as Jira or Linear for escalations and fix status; release notes for the Knowledge Curator.
• Uploads. Existing help-centre exports, policy documents, product manuals, extracted into articles.
• Derived. Categories, priorities, sentiment, first-contact resolution, knowledge gaps, quality scores.

Apps

• Queue. Tickets by priority and status with the Triage summary and the Responder's draft ready to edit and send. Used by support staff.
• Customer view. One customer's tickets, orders, invoices, subscription and notes in one page. Used by support staff.
• Knowledge base. Searchable articles, with a public and an internal audience per article. Used by staff and, published, by customers.
• Returns desk. Return and refund decisions against policy with the order and the evidence. Used by support and operations.
• Known issues board. Open product problems, affected customer counts and fix status. Used by support and engineering.
• Quality dashboard. Volume, response and resolution times, satisfaction, first-contact resolution, quality scores by category and person. Used by the support lead; feeds General Management.

We need a CRM for the sales team, with a deal pipeline.

Published Sales CRM. It uses the contacts and deals tables.

Sales CRMv3 · publishedread-write

Lead2

Northwind$8k

Initech$5kA

Qualified1

Globex$24kG

Won1

Acme$40k

Connectors

Process automations

Triage on arrival Trigger: a message arrives on any channel. Steps: the Triage agent identifies the customer, matches to an open ticket or opens one, classifies category and priority, checks for a known issue, assembles the customer's orders, invoices and history, and routes per the category rules. Checkpoint: none. Output: a ticket with context, in the right queue, within a minute.

Draft or auto-reply Trigger: a ticket is triaged. Steps: the Responder finds the relevant articles and macros, reads the customer's records, drafts a reply, and either sends it if the category allows auto-reply and confidence is above the threshold, or attaches it to the ticket for a person. Checkpoint: a person sends every reply outside the auto-reply categories. Output: routine questions answered immediately; everything else answered faster.

Return and refund Trigger: a ticket is classified as a return or refund request. Steps: the Responder checks the order, the return window and the policy rule, proposes a decision, and drafts the reply and the return label. Checkpoint: a person approves refunds above a value and every exception to policy. Output: decision recorded, refund or replacement raised in Supply Chain and Finance, customer informed.

Escalation to engineering Trigger: a ticket is classified as a bug or a person marks it. Steps: the Escalation Coordinator links it to an existing known issue or creates one, files the issue in the tracker with reproduction details, and tells the customer it is being looked at. When the tracker marks a fix released, it drafts an update to every affected customer. Checkpoint: engineering triages the issue; a person approves the fix announcement. Output: bugs reach engineering with context; customers hear when they are fixed.

Knowledge upkeep Trigger: routine, weekly. Steps: the Knowledge Curator finds resolved tickets whose answer had no article, drafts the article, flags articles unused for 90 days or contradicted by a release note, and proposes retirements. Checkpoint: the support lead approves new and retired articles. Output: a knowledge base that matches the product.

Quality review Trigger: routine, daily. Steps: the Quality Reviewer samples resolved conversations per person and per category, scores them against the rubric, notes coaching points, and rolls up the weekly report with satisfaction and resolution trends. Checkpoint: the support lead reviews before anything reaches an individual. Output: coaching notes and a report, never an automatic verdict on a person.

By industry

E-commerce brand. Order status, returns and damaged items dominate; auto-reply on order status alone removes a third of the queue. The returns desk enforces the return window and flags serial returners. Peak season volume is forecast from the Marketing calendar.

SaaS company. Tickets are how-to questions, bugs and billing; the Responder reads product docs and the customer's plan and usage. Escalations to Linear or Jira carry logs the customer attached. Known issues are surfaced to the Sales Supercube's account managers.

Subscription box service. Pauses, skips, address changes and delivery problems; the Responder acts on the subscription in Stripe within policy and confirms; the Triage agent groups tickets by delivery batch to spot a carrier problem early.

Utilities and telecoms reseller. Billing disputes and outage reports; the known-issues board becomes the outage board and the Escalation Coordinator drafts status updates by area. Regulatory complaint handling timescales are SLAs on the category.

Education provider. Students and parents ask about enrolment, fees and timetables; audiences on articles separate the two; the People and Finance Supercubes supply staff and fee records under strict scoping.

Local services business. Booking changes and quotes by WhatsApp and phone; the Responder drafts confirmations and reschedules against the Operations Supercube's job calendar.

Guard rails

• Auto-reply is off by default and enabled per category by an admin with a confidence threshold. Every automatic send is tagged as such in the message and the audit log.
• Refunds, replacements and policy exceptions are approved by a person, with thresholds per company.
• The Responder answers only from the knowledge base and the customer's own records; it never invents a policy, and it says when it does not know.
• Customer records from other supercubes are read with the viewer's own access level in the customer view, so a support agent sees what their role allows.
• Quality scores go to the support lead first and are coaching material, not a performance metric fed to anyone automatically.

Not in the box

• It is not a telephony system. Calls are logged as messages by a person or a transcription connector.
• It does not replace Zendesk or Intercom for a company that already lives there; it makes them faster and keeps them current.
• It does not resolve product bugs. It gets them to engineering with the context and tells customers when they are fixed.
• It will not promise a customer anything outside the policies in its tables.