Workflows · Every hand-off leaves a ticket

Nine workflows, one ticket trail

A workflow connects agents, your people and your customers around one piece of work. The rule is the same in all nine: every hand-off happens on a ticket, so afterwards you can read who had it, what they did, and who was asked.

Status today: none of the 9 runs end to end yet. Each card below says which pieces already run in the product and which are in build — we would rather show you the drawing than pretend it is the machine.

Whose ticket is it?

There are two kinds of ticket, and they never share a queue. Knowing which one you are looking at tells you who is allowed to read it and who has to answer it.

Loop B

A ticket for your own agents

Your customer, your agents, your people. The ticket is opened in your workspace, worked there and closed there. Nobody at Nexus is in the loop, and nobody at Nexus needs to be.

  1. Customeryour customer
  2. Ticketin your workspace
  3. Agentyour agents
  4. Personyour people
Loop A

A ticket that goes to Nexus

You need something from us: a billing question, a platform fault, a new agent. The ticket is opened in the Nexus workspace and worked by our agents and our people — the same workflows, run on ourselves.

  1. Customeryou
  2. Ticketin the Nexus workspace
  3. AgentNexus agents
  4. PersonNexus people

When a Loop B ticket needs Nexus

Escalating to Nexus does not move your ticket. It opens a linked child ticket in the Nexus workspace and leaves the original where it was, with your customer's thread intact. When we resolve the child, the resolution and its note are written back onto your ticket and the person who asked is told.

In build Today a person in your workspace can send a ticket to Nexus from the Tickets tab: that opens the linked child ticket (your ACME-42 gains an NX key beside it), leaves yours where it is, and writes the child's resolution note back onto it. Still in build: tickets opened by a phone call or by an agent's escalation reaching your own queue instead of one shared Nexus queue, and the e-mail that tells the person who asked.

Six states, the same for every workflow

A workflow does not invent its own statuses. It moves a ticket through these six, and a ticket can only move along the arrows the ticket store allows.

  1. submittedIt exists and has a reference.
  2. triagedLabelled by rule on arrival.
  3. assignedSomeone — an agent or a person — owns it.
  4. escalated to a personAn agent stopped and asked a person.
  5. waiting on the customerNothing moves until the customer replies.
  6. resolvedClosed, with a note saying how.

Available now Tickets carry a short key you can read aloud (ACME-42 instead of twelve characters) and a named owner once assigned. A person in your workspace can assign a ticket, answer the requester, resolve it with a note saying what was done, and reopen it within 14 days — and every one of those steps lands on the ticket's trail, with who and when.

In build The reminders and the automatic close on tickets that wait on the customer, and e-mail delivery of ticket notifications.

Workflow templates

A template is data, not code: a trigger, a ticket type, the states it uses, the agents involved, the hand-offs between them and who gets told. Installing one from your workspace is in build; the hand-off rules it is checked against already run.

How to read a card
  • Trigger what starts it: a schedule, a probe, a form
  • Ticket the record every hand-off is written on
  • Agent software doing a job, inside its guardrails
  • Person someone on your team, or on ours
  • Customer the person you serve
01

Customer request

In build

A question or problem arrives on any channel and is answered on one thread.

Trigger
A support form, an inbound e-mail or a phone call.
Who is involved
Front desk agent · Specialist agent for the topic · Workspace owner
Where it runs
Inside the workspace that installs it; the ticket never leaves unless a step escalates to Nexus.

Hand-offs

  1. CustomerCustomerwrites, e-mails or calls
  2. TicketTicketis opened with a referencesubmitted
  3. AgentFront desk agentlabels it: billing, login, outage or generaltriaged
  4. AgentSpecialist agentanswers from your knowledge baseassigned
  5. CustomerCustomergets the answer on the same threadresolved

Ticket states it passes through

  1. submitted
  2. triaged
  3. assigned
  4. escalated to a person
  5. resolved
Where a person is asked
The agent cannot answer from the knowledge base, or the conversation turns negative. Goes to: The workspace owner.
How they are reached
Telegram or a verified e-mail address work today. SMS and Slack are in build, and so is re-notifying at 15 minutes, 1 hour and 4 hours until someone acknowledges.
What the customer sees at the end
A reply on the thread they started, carrying the ticket reference, and a status they can check.

Runs today

  • The support form, inbound e-mail and phone calls each open a real ticket.
  • Labelling on arrival is rule-based, so a model error or a spending cap cannot strand a ticket.
  • A person in your workspace can assign the ticket, answer on it, resolve it with a note and reopen it within 14 days — from the Tickets tab, each step on the trail.

In build

  • A specialist agent picking the ticket up and owning it.
  • The sentiment rung, and delivery of the owner's notification.
  • A ticket from the website answer widget — today it shows an e-mail address instead.
02

Missed call to callback

In build

Nobody could take the call; the caller still gets a booked callback.

Trigger
A voicemail, "press 2 for a callback", or every line busy.
Who is involved
Voice agent · Scheduling agent · Workspace owner
Where it runs
Inside the workspace that installs it; the ticket never leaves unless a step escalates to Nexus.

Hand-offs

  1. CustomerCallerleaves a message or presses 2
  2. AgentVoice agentrecords who called and why
  3. TicketCallback ticketis openedsubmitted
  4. AgentScheduling agentbooks a slot inside your hoursassigned
  5. CustomerCallergets the time confirmedresolved

Ticket states it passes through

  1. submitted
  2. triaged
  3. assigned
  4. escalated to a person
  5. resolved
Where a person is asked
No slot is free inside the time you set. Goes to: The workspace owner.
How they are reached
Telegram or a verified e-mail address work today. SMS and Slack are in build, and so is re-notifying at 15 minutes, 1 hour and 4 hours until someone acknowledges.
What the customer sees at the end
A confirmed callback time, and the call itself.

Runs today

  • A voicemail and "press 2" each open a real ticket.

In build

  • The ticket landing in your own queue — today it goes to a shared Nexus queue your workspace cannot see.
  • A ticket when every line is busy — today that only records an event.
  • The scheduling agent booking the callback and confirming it.
03

Lead to booking

In build

A new enquiry is qualified, booked, and the owner is briefed before the meeting.

Trigger
A contact form or a call from someone new.
Who is involved
Lead qualification agent · Scheduling agent · Workspace owner
Where it runs
Inside the workspace that installs it; the ticket never leaves unless a step escalates to Nexus.

Hand-offs

  1. CustomerProspectfills the form or calls
  2. TicketLead ticketis openedsubmitted
  3. AgentQualification agentscores it with reasons, and consults schedulingtriaged
  4. AgentScheduling agentbooks the meetingassigned
  5. PersonOwnerreceives a one-page briefresolved

Ticket states it passes through

  1. submitted
  2. triaged
  3. assigned
  4. escalated to a person
  5. resolved
Where a person is asked
The lead scores as high value: the owner is told now, not after the booking. Goes to: The workspace owner.
How they are reached
Telegram or a verified e-mail address work today. SMS and Slack are in build, and so is re-notifying at 15 minutes, 1 hour and 4 hours until someone acknowledges.
What the customer sees at the end
A meeting time, confirmed.

Runs today

  • Form capture with a score and its reasons at intake; cold no-fit leads are never contacted.
  • A booking page with double-booking guardrails.
  • One agent consulting another and getting a typed answer back.

In build

  • The chain itself: nothing links a lead to a booking without a person today.
  • The owner's brief, and the qualification agent running on a schedule.
04

Invoice follow-up

In build

Overdue invoices get three polite reminders; any dispute stops everything and goes to a person.

Trigger
A scheduled check of receivables by age.
Who is involved
Invoice follow-up agent · Your collections person
Where it runs
Inside the workspace that installs it; the ticket never leaves unless a step escalates to Nexus.

Hand-offs

  1. TriggerAgeing checkfinds an overdue invoice
  2. TicketFollow-up ticketis opened per invoiceassigned
  3. AgentFollow-up agentsends reminder 1, 2, 3 through a tone gatewaiting on the customer
  4. CustomerCustomerpays, or disputes
  5. TicketTicketcloses on paymentresolved

Ticket states it passes through

  1. assigned
  2. escalated to a person
  3. waiting on the customer
  4. resolved
Where a person is asked
Any dispute, at any step: contact freezes at once. Goes to: Your collections person.
How they are reached
Telegram or a verified e-mail address work today. SMS and Slack are in build, and so is re-notifying at 15 minutes, 1 hour and 4 hours until someone acknowledges.
What the customer sees at the end
At most three reminders, never pressure language, and a person the moment they object.

Runs today

  • Invoice drafting and sending tools, used by hand.
  • A guardrail that holds collections language for human review.

In build

  • The ageing schedule, the three-step reminder ladder and dispute detection.
05

Document chase

In build

Ask once, remind twice, close with a note — and never nag forever.

Trigger
Someone opens a request for documents.
Who is involved
Document collection agent · The person who asked
Where it runs
Inside the workspace that installs it; the ticket never leaves unless a step escalates to Nexus.

Hand-offs

  1. PersonYour teamopens the request
  2. TicketRequest ticketis openedassigned
  3. AgentCollection agentasks the customer for the listwaiting on the customer
  4. AgentCollection agentreminds at 2 days and 5 dayswaiting on the customer
  5. TicketTicketcloses when complete, or at 10 days with a noteresolved

Ticket states it passes through

  1. assigned
  2. escalated to a person
  3. waiting on the customer
  4. resolved
Where a person is asked
Only part of the list arrives. Goes to: The person who opened the request.
How they are reached
Telegram or a verified e-mail address work today. SMS and Slack are in build, and so is re-notifying at 15 minutes, 1 hour and 4 hours until someone acknowledges.
What the customer sees at the end
One clear list, two reminders, and a plain closing note that says how to pick it back up.

Runs today

  • The waiting-on-the-customer state exists, and the customer's reply takes the ticket out of it.

In build

  • The 2-day and 5-day reminders and the 10-day close.
  • The document collection agent itself.
06

Monitor incident

In build

A check fails, the agent that owns the system fixes it, and the check has to go green before anyone closes it.

Trigger
A scheduled check or probe detects a failure.
Who is involved
Monitoring · The agent that owns the system · On-call person
Where it runs
Inside the workspace that installs it; the ticket never leaves unless a step escalates to Nexus. Nexus runs this one on itself, with its departments as the teams.

Hand-offs

  1. TriggerProbereports red
  2. TicketIncident ticketis opened with the evidencetriaged
  3. AgentOwning agentremediatesassigned
  4. TriggerProbeis run again and must be green
  5. TicketTicketcloses with the green result attachedresolved

Ticket states it passes through

  1. triaged
  2. assigned
  3. escalated to a person
  4. resolved
Where a person is asked
The probe is not green inside the time you set. Goes to: The on-call person.
How they are reached
Telegram or a verified e-mail address work today. SMS and Slack are in build, and so is re-notifying at 15 minutes, 1 hour and 4 hours until someone acknowledges.
What the customer sees at the end
Usually nothing — that is the point. If it touched them, a note saying what happened and when it was fixed.

Runs today

  • Faults in our own platform open a ticket automatically.

In build

  • Probes you define for your own systems.
  • Remediation by the owning agent, and the verify-green gate — today a probe ticket is closed at labelling.
07

Audit finding

In build

Whoever fixes a finding never gets to close it: the auditor does.

Trigger
An auditor files a finding.
Who is involved
Auditor · The team that owns the area · Founder or owner
Where it runs
Inside the workspace that installs it; the ticket never leaves unless a step escalates to Nexus. Nexus runs this one on itself, with its departments as the teams.

Hand-offs

  1. AgentAuditorfiles the finding with evidence
  2. TicketFinding ticketis openedtriaged
  3. AgentOwning teamaccepts or disputes, then fixesassigned
  4. AgentAuditorverifies the fix independently
  5. TicketTicketis closed by the auditor, never by the fixerresolved

Ticket states it passes through

  1. triaged
  2. assigned
  3. escalated to a person
  4. resolved
Where a person is asked
A dispute the two sides cannot settle. Goes to: The founder or workspace owner.
How they are reached
Telegram or a verified e-mail address work today. SMS and Slack are in build, and so is re-notifying at 15 minutes, 1 hour and 4 hours until someone acknowledges.
What the customer sees at the end
Nothing directly: this one is internal. The trail is what you show a regulator or a client who asks.

Runs today

  • This is how Nexus itself is audited, by an independent auditor — on written reports, outside the product.

In build

  • Findings as tickets, the accept-or-dispute step, and auditor-only closing.
08

Change or implementation

In build

A change is planned, built, reviewed, and closed only with evidence that it shipped.

Trigger
A team opens a change.
Who is involved
The team making the change · Reviewer · Approver
Where it runs
Inside the workspace that installs it; the ticket never leaves unless a step escalates to Nexus. Nexus runs this one on itself, with its departments as the teams.

Hand-offs

  1. PersonTeamopens the change with a plan
  2. TicketChange ticketis openedtriaged
  3. AgentBuilderbuilds itassigned
  4. AgentReviewerreviews it
  5. TicketTicketcloses with the deploy evidence attachedresolved

Ticket states it passes through

  1. triaged
  2. assigned
  3. escalated to a person
  4. resolved
Where a person is asked
The change is in a class you marked risky: it waits for an approver before it ships. Goes to: The approver you named.
How they are reached
Telegram or a verified e-mail address work today. SMS and Slack are in build, and so is re-notifying at 15 minutes, 1 hour and 4 hours until someone acknowledges.
What the customer sees at the end
Nothing directly — or a change note, if you choose to publish one.

Runs today

  • This is how Nexus runs its own changes — in an internal work queue, outside the product.

In build

  • Changes as tickets, the review step, and closing on deploy evidence.
09

Report anomaly

In build

When the weekly numbers jump, or cannot be read at all, a person is told with the numbers in hand.

Trigger
The weekly report moves 20% or more against the week before, or could read none of its sources.
Who is involved
Business reporting agent · Workspace owner
Where it runs
Inside the workspace that installs it; the ticket never leaves unless a step escalates to Nexus.

Hand-offs

  1. AgentReporting agentbuilds the weekly report
  2. TriggerComparisonfinds a jump, or empty sources
  3. TicketAnomaly ticketis opened with both weeks' numbersescalated to a person
  4. PersonOwnerexplains it, or asks for a fixresolved

Ticket states it passes through

  1. escalated to a person
  2. resolved
Where a person is asked
Always. A number that moved is a question for a person, not something an agent should explain away. Goes to: The workspace owner.
How they are reached
Telegram or a verified e-mail address work today. SMS and Slack are in build, and so is re-notifying at 15 minutes, 1 hour and 4 hours until someone acknowledges.
What the customer sees at the end
Nothing: this one protects you from acting on a broken report.

Runs today

  • The business reporting agent builds the weekly report on a schedule.
  • The report card in your workspace says so when it could read no source, instead of showing zeros.

In build

  • The week-over-week comparison, and the ticket it opens.

Want one of these running on your desk?

Tell us which one and what it would replace. We will tell you, as plainly as this page does, how much of it runs today.