Looking for SegmentStream Marketing Analytics? It moved to measure.segmentstream.com →
Support and customer success teams

A support desk on your own customer records, on the inbox you already use.

Conversations from your shared inbox arrive through a connection to Gmail, Help Scout or the helpdesk you use. Each one lands on the customer's record with its status, owner, priority and topic, and replies go back out from the same address.

The shared inbox, connected through Gmail. Each conversation is classified on arrival and sits on the customer's record.

northwind.segmentstream.app
A support inbox connected to Gmail: conversations with topic and priority, an open thread with the customer's message, an internal note and a reply, and the customer's record with assignee, priority, topic and first-reply deadline

Swipe the screen sideways to see all of it.

Support and customer success teams

Support desk: what it does

Connect your support inbox and tell your agent how your team triages. It writes the ingestion, the classification, the ticket actions and the inbox page.

What it does
  • Conversations arrive from Gmail, Help Scout or your helpdesk through a connection, on the schedule you set.
  • Each one is classified by topic and urgency on arrival, against categories you can read and edit.
  • Tickets sit on the customer's record, beside their contracts, orders and deals.
  • Status, owner, priority and notes change only through actions; replies go out as the member who wrote them.
  • Response times are SQL models, so the report and the inbox agree.

What it covers

  • Your inbox, connected →

    Gmail, Help Scout or the helpdesk you use connects, and customers keep writing to the address they know.

  • Triage on arrival →

    Each new conversation is classified by topic and urgency against categories written in plain language, through the evaluation connection.

  • Tickets on the customer record

    Every conversation sits on the customer's record, next to their contracts, orders and open deals, so nobody answers blind.

  • Replies and internal notes

    Status, owner, priority and internal notes change only through actions, with history. Replies go out from your support address through Resend, as the member who wrote them.

  • Response times and reports

    First-reply and resolution times by topic, member and customer, as SQL models your team can read.

  • The company agent →

    Ask which urgent tickets are waiting for a reply in Slack, Teams, WhatsApp, Telegram or email, and get an answer with your own permissions.

Built from typed blocks

No new product to buy: the blocks below, written by an agent into your workspace's repository and deployed with one command.

Entitiesontology/
  • ticket
  • ticket_note
  • saved_reply
  • client
  • contact
Actionsontology/
  • ticket.assign
  • ticket.setStatus
  • ticket.setPriority
  • ticket.addNote
  • ticket.reply
Rolesontology/roles.ts
  • support
  • support_lead
  • account_managerreads tickets
Connectionsconnections/
  • gmail or helpscoutOAuth 2.0
  • resend
  • evaluation
Pipelinespipeline/
  • support_conversations
  • classify_conversations
  • response_times
Appapp/
  • Inbox
  • Customers
  • Saved replies
  • Reports
Agentagent/
  • Company agent in Slack, Teams, WhatsApp, Telegram and email
One deploy

$ segmentstream deploy

Every block ships together from one git repository your company owns. SegmentStream runs it.

The entities, how they link, and which role may run each action. Your agent writes your own names and rules.
Rules live in actions

The rule is code, not a setting someone can skip.

Every change goes through an action. The role that may run it is checked first, then the rule inside it. The same check applies to people in the app, to API keys and to agents over MCP.

ontology/ticket.ts
const mail = connection("resend", { description: "Sends replies from the support address." });

export const Ticket = entity("ticket", {
  description: "What the team decided about one support conversation.",
  properties: {
    conversationId: p.text({ unique: true, description: "The id in the inbox." }),
    customer: p.email({ description: "Who wrote in." }),
    subject: p.text({ description: "The conversation's subject." }),
    status: p.select(TICKET_STATUS, { default: "open", managed: true }),
    priority: p.select(PRIORITIES, { default: "normal", managed: true }),
    replies: p.integer({ default: 0, managed: true, description: "Replies sent so far." }),
  },
  relationships: {
    client: rel.one("client", { optional: true, inverse: "tickets" }),
    owner: rel.one(User, { optional: true, inverse: "tickets" }),
  },
}).actions((self) => ({
  reply: action({
    description: "Reply to the customer from the support address.",
    input: Schema.Struct({ ticket: self.ref, text: Schema.String }),
    connections: [mail],
    prepare: ({ input }) =>
      Effect.gen(function* () {
        const ticket = yield* self.get(input.ticket);
        const sent = ticket.replies + 1;
        // The email goes out even if the transaction fails, so its key comes
        // from the record: a retry reaches the same email, not a second one.
        const response = yield* mail.post("/emails", {
          headers: { "Idempotency-Key": `ticket:${ticket.id}:reply:${sent}` },
          json: { from: SUPPORT, to: ticket.customer, subject: `Re: ${ticket.subject}`, text: input.text },
        });
        if (!response.ok) {
          return yield* new ActionRejected({ message: "The reply was not sent." });
        }
        return { sent };
      }),
    handler: ({ input, prepared }) =>
      Effect.gen(function* () {
        const ticket = yield* self.get(input.ticket, { forUpdate: true });
        if (ticket.replies + 1 !== prepared.sent) {
          return yield* new ActionRejected({ message: "Someone replied first. Read the thread again." });
        }
        yield* self.update(ticket, { status: "waiting", replies: prepared.sent });
      }),
  }),
}));
Inside SegmentStream

Your inbox and tools, connected once.

Connections are declared in code and authorised in the console; the credentials stay with the platform.

segmentstream.com
The console's connections page: Resend, Xero, Stripe, Supabase, LinkedIn and Telegram connections, each connected, with the key it is declared under in code
Connections declared in code and authorised here. The credentials stay with the platform, never in the repository.
What it replaces
  • Zendesk
  • Freshdesk
  • Front
  • shared-inbox spreadsheets
Keep your inbox

Your support address stays where it is. The connection reads new conversations, replies go out from the same address, and past conversations load once through the same API, so the history is there on day one.

Moving from

Done for you · Keep your inbox

We can do the whole move for you.

Our forward-deployed engineers take the migration end to end: the model, the export, the import, the side-by-side comparison, and the switch. It starts with a fixed-scope pilot, and nothing is switched off until the numbers match.

Have us build it

Enterprise, with our engineers

Our engineers connect your inbox or helpdesk, load your history, write the triage categories with your team and build the inbox, then run it beside your current tool until the team switches.

Build it yourself

Self-serve, with your own agent

Connect your support inbox and tell your agent how your team triages. It writes the ingestion, the classification, the ticket actions and the inbox page.

curl -fsSL https://segmentstream.com/install.sh | sh

Related solutions

Questions

Do we need to move our support email?

No. Your support address stays in Gmail, Help Scout or the helpdesk you use. The workspace reads new conversations through a connection and replies from the same address, so customers see no change.

How is a conversation classified?

A decision model reads each new conversation and picks a topic and an urgency from categories written in plain language. Change a category by editing its text; every ticket records the version that classified it.

Can an agent help answer?

Any agent connected over MCP can read a conversation and draft a reply as a note, with the permissions of the member it works for. Who may send is decided by your roles.

Enterprise pilot

Rather have it built for you? Start a pilot.

Our engineers connect your inbox or helpdesk, load your history, write the triage categories with your team and build the inbox, then run it beside your current tool until the team switches.

  • One solution, on your data, in your own workspace
  • First version live in two weeks
  • Parity proven before anything is switched off
  • Fixed scope and price, credited to your contract if you continue

Not ready for a pilot? Send the form anyway with your question. An engineer will reply, not a sales rep.

How the pilot works

Goes to our founder’s inbox. No sales queue, no newsletter.

Build your company’s own software. Let agents run it.

$ segmentstream workspace create acme --region eu --subdomain acme

▸ Created workspace acme · database, warehouse and a private git repository

$ segmentstream workspace WORKSPACE-ID clone acme && cd acme

▸ your coding agent builds what your team asked for and runs the checks

$ git add -A && git commit -m "First version"

$ segmentstream deploy

▸ app, company agent, API and MCP tools live for your invited members

Start a pilot

Our engineers build the first version on your data in two weeks, at a fixed price.

Or build it yourself with your coding agent:

curl -fsSL https://segmentstream.com/install.sh | sh

We’ll email you product updates, tips and onboarding help. Unsubscribe anytime.