Helpdesk & support

Answer the customer.
Without leaving what you know about them.

A support tool that lives outside your data can tell you what somebody asked. It cannot tell you what they ordered, when it was delivered, or what they still owe — not without an integration somebody has to build and keep alive. In RowFold a ticket is a record in your own workspace, so all of that is already one link away.

Start free Bookings & scheduling Watch a desk run 2 min
Watch it instead · 2 min A support desk that already knows the customer. Where it arrives · Answered already · The queue · The clock · Why here

01A ticket is a record

When somebody writes in, RowFold creates a row on one of your tables. Not an object inside a separate support product that you later reconcile against your real data. A record, on a table you chose, with columns you chose.

Everything else follows from that. A ticket is in your reports because it is a record. It sits in a filtered view, fires an automation, respects your per-field permissions, appears in the audit trail, exports to CSV, comes back through the API, and can be asked about in plain English. None of that had to be built for support. It works because a ticket is not special.

What is special is where it sits. Your Tickets table is one relation from Customers, and Customers is one relation from Orders, Bookings and Invoices. So the answer to “where is Tuesday’s delivery?” is not in another tab — it is on the record already open.

Plain English: the customer asking the question and the customer in your orders table are the same row. There is nothing to sync.
A ticket open in RowFold. The customer’s message and an internal note sit in one thread, badged differently, with the ticket’s own fields beside them.
The ticket is an ordinary record. Its status, who it is assigned to and the customer it links to are columns on a table you chose.

02Every way in, one table

Sign in and choose Run a help desk, from the + New menu. You pick the table, and it sets up the address, the chat bubble and any column a desk needs and the table has not got — then everything below is already true.

Four kinds of front door, all writing to the same place:

  • An email address of its own. Point your support address at a RowFold mailbox and each email opens a ticket. Replies go out from inside the record and come back onto the same thread, matched on the reply address first and mail headers second. Quoted chains and signatures are stripped before anything is stored. Replies can leave from your own address — support@yourcompany.com — once your domain passes three checks in Settings; until then they come from RowFold’s, with your organisation’s name on them.
  • A chat widget. A messenger you embed on your own site. Visitors write, you answer from the inbox, and they watch the conversation continue.
  • A public form. A link anyone can fill in without an account. Each submission opens a conversation.
  • Your own software. An inbound webhook endpoint that publishes its format and answers synchronously, or the REST API.

Subject matching is deliberately not implemented. “Re: Invoice” from two different customers is the classic way a support system cross-contaminates two threads, and a wrongly merged ticket shows one customer another customer’s conversation.

03The help centre

Your articles, published as a browsable site in your own colours, at a public address. The chat widget reads them first: somebody asking a question your articles already answer gets the answer, and no ticket is created at all.

The best question is the one you never see, and the ones that do arrive are then the ones actually worth a person’s morning.

A published help centre: a search box, article categories down one side and a list of articles, in the workspace’s own colours.
The public help centre, in your branding, at your own address. The categories are a column on the articles table.

04The queue

The inbox shows conversations, not a folder of everything open. Its default is waiting on a reply — the ones where the customer spoke last — which is a different and much shorter list than “open”.

The whole conversation lives on the record: both directions in one ordered list, with the channel each message came through. A note to a colleague is a different kind of thing from a reply, and structurally so — who may read a message is recorded separately from who wrote it, so an internal note cannot reach the customer by accident.

Your existing columns are detected, never invented. Opening the inbox does not add an “Assignee” or a “Status” column to somebody’s table; it finds the ones already there, and offers an explicit button when there are none.

The RowFold inbox in three panes: the queue of conversations on the left, the selected conversation in the middle, the record’s own fields on the right.
One queue for every way a customer can reach you — the conversation in the middle, and the record it belongs to on the right.

05Response times you can keep

Set a first-reply target, a resolution target, or both. The clock starts when the customer writes in and can run on your working hours rather than around the clock, so an email at ten at night does not eat its target overnight. It pauses while you are waiting on them, and the states that mean paused and resolved are read from your status field’s own options — a desk running “Triage / With engineering / Shipped” works with nothing renamed.

The important part is what happens when the policy changes. A deadline is stamped onto the ticket at the moment its clock starts, and never re-derived. Tightening first reply from eight hours to four applies to tickets from then on; it does not reach back, retrospectively breach a quarter of finished work, and quietly rewrite last quarter’s reports.

Breach alerts fire once, on the edge, rather than hourly for a fortnight — a repeated alert is how people learn to ignore the one that matters.

Plain English: a target is a live setting. A deadline is a fact about one ticket. Changing the first cannot rewrite the second.
A response-time policy: a plain-English summary at the top, then the first-reply and resolution targets, the working-hours switch, and the statuses that pause the clock.
The summary at the top is written from the settings under it, so what the policy promises and what it actually does cannot drift apart.

06Teams, routing, macros and ratings

  • New tickets can assign themselves. Preference first — whoever dealt with that customer last — then load, so it spreads across whoever is on the roster rather than dealing round in a fixed order.
  • Teams take work together. Name a group — Billing, Onboarding, Tier 2 — and it gets its own queue in the inbox, its own share of new tickets, and its own escalation path. Moving a ticket to another team is a hand-off rather than a label: somebody on the receiving team picks it up in the same act, unless whoever has it is already one of theirs.
  • Saved replies and macros. A reply can carry values from the record itself, and a macro can set the status and assign it in the same click. You see the finished text before it sends.
  • A rating on close. One click, out of five, with an optional comment, and it lands back on the record next to everything else you know about that customer — so satisfaction is reportable alongside the rest of your data rather than in a separate dashboard.

A ticket keeps its team in an ordinary column, the same as its status and its owner — so a team filters in the grid, groups on a board, appears in a report and can be read by an automation. There is no separate place team assignments live, and nothing to keep in step.

Escalation is tied to the response time you already set, and fires once. When a ticket on a team misses its first-reply or resolution target, it is handed to that team’s escalation path — another team, or one named person — reassigned, written on the ticket, and everyone involved is told. Once per missed target, never on a loop, and never walking a chain: if the receiving team then misses its own target, that is its own escalation.

Plain English: a roster says who could take a ticket. A team says who it belongs to — which is a thing a ticket can have while nobody has picked it up yet, and a thing you can hand over.
The routing setup page: a switch to assign new tickets automatically, and the list of people who are on the roster for new work.
Name the people who take new work. The order — whoever dealt with that customer last, then whoever has least on — is worked out from the tickets themselves.

07One customer, one conversation

Somebody writes in twice. Somebody buries a second question in a reply. Both are ordinary, and both leave the queue saying something untrue about how much work is waiting.

Merging moves the conversation, and nothing else. Pick the ticket to keep, and the other one’s messages move onto it, in order, interleaved by when things were actually said. The emptied ticket goes to the Trash — it keeps its number, its fields, its clock and its history, and it is one click to get back. Nothing on the surviving ticket is overwritten: not a field, not the owner, not the status, and not the deadline, for the same reason tightening a target does not reach backwards.

We deliberately do not merge the two records. Two records have two sets of values, two histories and two numbers, and every rule you could write for folding those together — newest wins, non-empty wins — quietly throws away something somebody typed. So the thing that actually duplicates is the thing that moves.

Which is why every merge undoes. The thread marks where the two conversations join, with an Undo beside it; press it and the messages go back and the ticket comes out of the Trash. Splitting is the same thing pointed the other way: on any reply, Split from here moves that message and everything after it onto a new ticket carrying the customer’s address and nothing else — not a status somebody set about the old problem, not an owner who closed something else.

A customer who replies to the old address still reaches you. The reply follows the merge onto the ticket that has the conversation, which is the whole point — without it the duplicate you just removed comes straight back.

Plain English: merging is about the conversation, not the row. Nothing is deleted, nothing is overwritten, and you can put it back.

08What it does not do

Checked against the code, not assumed:

  • No routing rules. A queue has one front door — the team a new ticket starts on — and everything after that is somebody moving a ticket. There is no “if the subject contains…”, on purpose: a second place tickets get sorted is a second thing to disagree with a person’s own triage, silently.
  • No capacity limits. Routing balances on how much each person is holding; it will not stop handing somebody work at a number you set.
  • Nothing locks a conversation. You can see who else is looking at a record, but that is information rather than a lock — a stuck lock on a support desk is worse than an occasional collision, so this is a decision rather than a gap.

Next: bookings and scheduling, built on the same engines, or what it costs. The helpdesk is part of RowFold, not an add-on with its own price.