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 1½ min

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.

02Every way in, one table

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.
  • 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.

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.

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.

06Routing, 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.
  • 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.

07What it does not do

Checked against the code, not assumed:

  • No merging or splitting tickets. If the same person opens two, you have two.
  • No teams. Routing has a roster of named people, not a team object with its own queue and escalation path.
  • 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.