supportcron

Review a customer issue

The escalation queue places each issue beside its action review. Read the stored customer context, prepare a response, then inspect the destination, visibility and exact body before applying. The review button names what you chose: Review note, Review reply, or Review reply and resolution. Editing the response clears the prepared review. Queue counts and ranking guidance are in a disclosure below the issues. Uncertain provider receipts remain available for inspection.

Each issue names its Source the way a person reads it, such as Zendesk ticket 204 · last event 09:10: the provider and ticket number, and the time of the latest provider event the board has for it. Each issue also shows Sales activity. While the escalation is open, new sales outreach to that account is held: an approved email waits instead of sending. The line comes from the same check the send makes, so it reads "Held due to open escalation" exactly when a send would wait.

The notice at the top of the board follows the queue. While an issue is open it reads A customer issue needs attention and says new sales outreach is held. Once support resolves it and outreach still waits for a person to review the next action, it reads The issue is resolved; review the next action. When a held send explains itself, it names the ticket the same way the Source row does, such as "Outreach is paused while support resolves Zendesk ticket 204 for this account." AI Assist drafts the reply from the issue on that row, the customer, ticket and summary, and never from your sales pitch. Review the draft before you prepare the action.

A resolution does not release outreach by itself. Once the same ticket has a newer resolution, the line reads "Held until the next action is reviewed" and offers Next action reviewed, release outreach. Pressing it records who reviewed it and when, and sales outreach to the account can resume. A resolved ticket nobody reviews stops holding the account 14 days after it was resolved. Another open issue on the same account keeps it held either way.

Beside each issue sits the Renewal action. It shows the renewal date and how far away it is, the annual value and the health band, each read from the account record and marked "Not recorded" when the record has none. It also names the outreach hold in one of four words with its reason: Held while the issue is open, Awaiting review once support resolved it, Released after a person recorded the review (with the ticket and the date), or Not held.

The panel prepares a renewal task, success plan or expansion follow-up through the same flow as Prepare action on the Health board. Review renewal action checks the account and shows the destination, visibility, due date and the account revision. Save reviewed action saves a review draft, or a Planhat or Gainsight proposal that still waits for approval; nothing is written to either tool from this page. Preparing the action is part of the customer success seat, so on an account without it the controls are disabled and say so.

Overview

supportcron runs a support lead's day on a schedule, on our servers. Three tasks run on a clock: a daily 6:15am escalation triage, a Wednesday deflection-candidates review, and a load review on the first of the month. Three more run on demand: first-response drafts, the account-escalation brief, and support-risk score narration. A daily brain synthesis turns the day's runs into lessons. Everything is draft-first, and there is nothing to install.

What it is for, on the page. Under the headline, this page says what it produces, what makes it run, and where the output lands. Every Work page reads that line from one registry, so the three answers cannot drift from the page.

supportcron can add a reviewed private note to a connected Zendesk ticket. It cannot send a public reply or resolve a ticket. Those operations stay unavailable until they pass a controlled live run.

What this role does for a founder

Carry customer issues into the next decision. Help you respond to customer issues with context and make those issues visible to the rest of the revenue work.

Uses the support conversations you connect, your approved help material, and the account's business and customer history. It becomes active when there are issues to assess and says so when there are none.

Before it has work

• A support tool connected (preview)
• Approved help material
• Customers with open issues

Where its work goes

• To Customer success: An escalation, or a confirmed resolution. Update the customer plan and retention priorities.
• To Account executive: A support issue on an account in an active buying conversation. Adjust the timing and wording of the next message.
• To Sales engineer: A reproducible product question or gap. Validate the answer and describe the real remediation.

Needs support records and approved knowledge. The support connectors (Zendesk, Intercom) are in preview until verified against a live account. It must not call a ticket resolved because a response was drafted, invent a service level, or promise that it can fix product defects. The full overview, with the work, outputs, an example and the measures to watch, is on the Customer support page.

Customer Support, not Customer Success

These are two roles, and the difference decides which one answers a question. cscron owns the post-sale commercial relationship: health, adoption, onboarding, renewal posture and expansion. supportcron owns the queue: open escalations, response times, recurring issues and support load.

They share a customer and little else, so they are wired to tell each other rather than to duplicate. When supportcron finds an escalation on an account, it publishes a signal the account executive's and the CSM's next runs both read. When sales flags a deal at risk, supportcron reads that back, which is what lets the triage rank by what is at stake rather than by what is oldest.

Why the triage ranks the way it does

Loudness is not severity. The daily triage ranks an escalation on an account with an open renewal above an older one with nothing riding on it, then an escalation on an account already flagged at risk, then age against first response, then blast radius as the record states it.

A support queue sorted by age will never surface the first pairing, because the commercial clock lives in a different system from the ticket. That pairing is the whole reason this role reads the org's shared facts rather than only its own.

The Escalations board

Escalations, under Work, is the browsable form of that daily triage. Same ranking, same inputs, computed the same way. Each linked Zendesk or Intercom conversation can prepare an internal note, a public reply, or a reply that resolves the case. The action stays in review until a person applies it, and the receipt records the provider result.

Every row shows its reasoning. Open "Why this rank" on any account and you get the four inputs it was ranked on, each marked stored or assumption. Stored means a record carried it. Assumption means nothing did and the board proceeded without it, which is the honest label for an account with no renewal date rather than a zero that reads like a reading.

An account nobody measured is not "at risk". The health engine treats missing data as risk, which is right on a health board and wrong here: on a freshly imported book every account would carry an at-risk flag nobody applied. So the board uses a health band only for an account the engine had something to score, and says so on the row when it did not.

Three kinds of empty, never one. A board with nothing on it tells you which situation you are in: no accounts yet, no helpdesk connected (and which one to connect), or genuinely nothing escalated. A read that failed says that instead, because "nothing escalated" during an outage is a false statement about your customers rather than an empty state.

A Zendesk row can prepare an internal note. Write the exact note and choose Review private note. The server checks that the stored ticket belongs to this account, confirms the requester, and binds the note to the ticket revision you read. The review shows the destination, customer, internal visibility, revision and exact body. Only Add reviewed private note writes to Zendesk. A changed ticket or uncertain customer stops the write.

Account history sits under each issue. A table lists what is already on record for that account, newest first: its tickets, when they opened and resolved and their status at the last sync, outreach sent to the account and any reply, when sales outreach was held and when a person released it, handoffs another role raised about the account, and linked opportunities and meetings. The three columns are When, Event and Receiving work. Each row gives the time on your own clock in the short form (Sep 15, 10:02, with the year only when it is not this one), shows the exact UTC time when you hover it, keeps its recorded source beneath the event, and links to its stored record. Receiving work names a recorded outreach hold or the action requested from another role, with its recorded settlement when present. Other rows say No receiving work recorded. Nothing is inferred. An account with no stored record reads No earlier activity recorded.

An interrupted write stays stopped. If Zendesk may have accepted a note but the result did not return, the proposal moves to outcome unknown. It cannot be sent again from the queue. The Escalations page asks a signed-in operator to inspect the named ticket, record the Zendesk audit ID when the note exists, and settle the original receipt. Recording the check never makes another provider call.

The board does not send public replies or resolve tickets. Those actions require a controlled live verification before they can be enabled.

The Deflection board

Deflection asks a different question of the same signals: which issues keep arriving, and which of those are worth writing an answer to once. It splits into document these and not yet, and every not-yet names the test it failed rather than leaving you to work it out.

The two tests. A theme is recommended once it has been seen at least three times across at least two accounts. Both matter and they catch different things. Three reports from one customer is a conversation to have with that customer, not a document for everyone. Two reports across two customers is not yet a pattern.

The grouping is deliberately crude, and it is worth knowing how. There is no stored theme on a support signal to read, so themes are formed from the summary text: lowercased, with the parts that vary per occurrence removed (email addresses, urls, ids, numbers), then keyed on the first few remaining topic words. That merges "SSO login failing for dana@acme.com" with "SSO login failing for sam@globex.io" and keeps "SSO provisioning delayed" separate.

It will occasionally split one issue into two themes when two people describe it differently. The alternative was asking a model to group them, which groups better and returns a different board on two consecutive loads, and a board that changes when you refresh it is not one you can work from. If the grouping proves too crude the fix is to record a theme when the signal arrives, not to make the read cleverer.

Every label on the board is a summary somebody wrote. None is generated.

The Support load review

Support load is the monthly review as a board: every support signal on your book split by the account it came from and by the theme it belongs to, month over month, heaviest first.

A zero is shown, not skipped. Every row carries a column for every month in range, so a quiet month for an account reads as a quiet month rather than as a gap in the data. The change column compares the newest month with the one before it, and says "no comparison" rather than "level" when there is only one month of history.

What it cannot tell you. This counts signals, not hours. Nothing in the record says how long anything took to answer, so a theme with twice the volume is not necessarily twice the work, and the board does not claim it is. Escalations are counted separately from total load, which is the closest thing to a severity weighting the data supports.

What the drafts will not say

A first response acknowledges the specific problem, says what is being done, and gives the next checkpoint. It will not give you a fix date, because it cannot know one. It will not state a cause, because that is an engineering finding rather than a support draft. And it will not use a number it did not read from your records: no uptime figures, no affected-user counts, no "less than 1% of customers".

A reply that over-promises costs more trust than the outage did, which is why these are refusals in the skill rather than guidance in a doc.

The brief for the account owner

When an escalation lands on an account with commercial exposure, account-escalation-brief writes what the account owner needs, in their language: what the customer experienced, what it puts at risk from the stored opportunity record, where it stands including "unresolved", and what to do differently in the next conversation.

It states the position honestly rather than softening it. An owner told a problem is handled who then hears otherwise from the customer is worse off than one who was told the truth.

What to connect, and what each one is for

Connections → Recommended shows this seat's list. The CRM pair comes first because the ranking is commercial: escalation-triage sorts by what is at stake, and what is at stake comes from the opportunity record.

• Salesforce or HubSpot: the account and opportunity records the ranking reads.
• Intercom or Zendesk: the helpdesk. Conversation and ticket events become the support signals the triage reads. Zendesk also supports a reviewed internal note.
• Jira: where an escalation goes once it becomes engineering's.
• Slack: where the brief for the account owner lands.
• Gmail: the thread history behind a customer conversation.

Intercom is on the preview tier, and the badge in Connections says so. The integration is written and its conversation events project into signals, but the payload shape for Fin-handled conversations follows Intercom's published documentation rather than traffic we have watched arrive from a live Fin workspace. Preview means we built it and have not confirmed it against the real thing. Connect it and the triage reads what arrives; treat a Fin resolution state as worth checking rather than as settled.

Without a helpdesk connected, escalation-triage still runs, on accounts, opportunities and whatever signals exist. It will have less to rank and it will say so rather than inventing a queue.

Your console (runs on our servers, nothing to install)

By the numbers (live). supportcron ships 6 hosted skills, 3 of them on an auto-run schedule (daily driver: escalation-triage). Tier: front-line. These counts are read from the live registry, not hand-typed.

supportcron has a control surface in your browser at /supportcron/console. It drives the hosted runtime that runs supportcron's agents on our servers on a schedule, so nothing depends on you keeping an app open. Scheduled AI work runs on your own provider key (Claude, OpenAI or OpenRouter; every tier is bring-your-own-key), after any platform-funded first-run allowance the deployment turns on. The free deterministic checks need no key. A key turns drafting on; nothing is sent until you turn the send layer on. Bedrock is built but not accepting keys yet; Settings shows it as coming soon until the transport is validated.

Today and Activity link to the original work in this workspace. Work also opens saved research and drafts. A direct link can retrieve an older finding or draft beyond the recent queue. Research expands its facts and quotes; historical drafts keep their status and disable unavailable edit actions.

• Schedule. A runtime on/off switch, plus every skill with its cadence and tier. Toggle any skill or run one now.
• Draft queue and Runs. Review the drafts your runs produced and see what ran, when, and what it cost.
• Live coach (front-line seats). On-demand interactive coaching: practice a live buyer roleplay, build a pre-call brief for a connected meeting, draft a reply to an inbound thread, write a deal-specific battle card for a competitor, or draft the lesson out of a deal you closed. Draft-only, on your budget, nothing sent.
• Build. Probe an MCP server you have already connected to see the tools it offers, and check a custom skill draft against the same compiler the fleet runs. Both are read-only: probing lists tools without calling one, and validating saves nothing.
• Settings. Budget meter, identity, and bring-your-own-key.

Delivery. Output is draft-first and lands where you choose: your in-app draft queue by default, and optionally your Google Drive "Accounts" folder, where the console names the last files that landed so you can tell delivery is working without going to look. For a security-strict team that needs real Gmail or Outlook drafts and CRM writes on their own credentials, an optional self-hosted path (n8n on your own machine) is available. Nothing is ever auto-sent. Full walkthrough: Persona Console.