We liked it, so we built it. The feature is small, but the way you pick that time went through a few versions before it felt right, and that's the part worth sharing.

We started with a list of presets

The first version was the obvious one. A small menu with a handful of choices: later today, tomorrow, this weekend, next week, in a month. Anything else dropped you into a calendar.

Plenty of tools ship exactly this, and it works. But using presets only cover the cases you thought of. The moment someone wants "next tuesday afternoon" or "the 23rd at noon", they fall through to the calendar, and now there are two completely different ways to pick a time in the same little menu.

Then we let you just type it

So we threw the hard coded list away and replaced it with a single text field. You write when you want the ticket back in plain language, "tomorrow at 9am" or "in 3 hours", and that's it.

Parsing human dates yourself is a swamp you don't want to wade into. There's a library that already does it well, chrono-node, and it carries the whole feature. Here's the core of how we use it:

import * as chrono from 'chrono-node';

function parseWhen(text: string): Date | null {
    if (text.trim() === '') {
        return null;
    }

    return chrono.parseDate(text, new Date(), { forwardDate: true });
}

That's the entire parser. parseDate returns a Date or null, so a failed parse is trivial to handle. The forwardDate option is the detail that makes it feel right: when the input is ambiguous, chrono resolves it into the future. Type "9am" after nine in the morning and you get tomorrow at nine, not a time that already passed today. For a snooze, the future is almost always what you mean.

The risk with free text is that people don't trust it. They type something and wonder what the computer actually understood. So under the field we show the parsed result back, "Reopens Fri, Jun 19 at 09:00", and we update it as you type. We debounce that preview so it settles after you pause instead of flickering on every keystroke, and we only show a validation error once you actually try to submit, never while you're still typing.

Recents bring back the one-click speed

Typing is flexible, but we gave up something when we deleted the presets: the single tap. Clicking "tomorrow" was faster than typing it. We wanted that speed back without bringing the hardcoded list back.

The answer was to remember what you type. Every phrase you confirm gets saved, and the next time you open the field they're waiting there as one-click options.

A few decisions went into that list. We keep three, deduplicated, so it stays short and doesn't fill up with near-identical entries. We sort them by their resolved time, soonest at the top, rather than by how recently you typed them, because when you're scanning for "the soon one" versus "the far one" the time is what you're after. And we store the phrase you typed, not the date it resolved to, then re-parse it on click. That way "in 3 hours" still means three hours from now the next time you use it, instead of pointing at a moment that's long gone.

The nice part is that the list becomes yours. If you always snooze things to "monday 9am", that's what sits at the top, not a generic option we picked for everyone.

It's live, and it came from you

Waiting until is available now for every There There workspace. Open a ticket, set it to Waiting, and type when you want it back.

If you're using There There and there's something you wish it did, tell us. There's a decent chance you'll see it in a post like this one.

In There There, all panes are resizeable so you can size a ticket message, the AI panel, ... to how you like best. The sidebar can of course also be dragged. And to make it get out of your way, we added a collapsed state of it as well.

We have spent some time animating going from/to the different states. You can click the border of the sidebar to see that animation. You can also manual drag so you can see the animation slowly.

Pretty slick, right?

Small thing, but it is the kind of detail we like to sweat.

While it's always nice to get a thank you as a response, it's slightly annoying that in most helpdesks such a response reopens the ticket. And you have to close it manually again.

It's a tiny moment, but it repeats all day, on every closed ticket a customer is kind enough to acknowledge. A thank-you shouldn't cost you a context switch.

So There There leaves a closed ticket closed when the reply is only a thank-you. Getting that right took more care than you'd think, so here's how it works.

The rule we wanted

We keep a ticket closed only when the reply has nothing to act on. A question, a follow-up, a link, a complaint, anything that needs a reply, and it reopens like normal.

One kind of mistake is much worse than the other. If we wrongly keep a ticket closed, a real customer message slips through unnoticed. If we wrongly reopen one, you just close it again. So whenever we're unsure, we reopen.

A cheap check before an expensive one

To avoid AI costs, we first try to detect with plain code when a reply isn't a regular thank-you. The obvious cases are cheap to rule out:

private function mightBeThanksOnly(string $messageText): bool
{
    $maxThanksOnlyLength = 500;

    // A genuine thank-you is short; anything long probably has substance.
    if (mb_strlen($messageText) > $maxThanksOnlyLength) {
        return false;
    }

    // A question mark means the customer is asking something.
    if (str_contains($messageText, '?')) {
        return false;
    }

    // A link means "take a look at this", so there's something to do.
    if (preg_match('#https?://#i', $messageText) === 1) {
        return false;
    }

    return true;
}

Anything that doesn't pass reopens the ticket without a model ever running, which handles most replies on its own.

A tiny agent with one job

Only the survivors reach a model, and it's the cheapest one we have, doing the smallest task there is: return a single boolean.

class DetectThanksOnlyMessageAgent implements Agent, HasMiddleware, HasStructuredOutput
{
    use Promptable;

    public function model(): string
    {
        return config('ai-pricing.cheap.name');
    }

    public function instructions(): Stringable|string
    {
        return view('prompts.ai.detect-thanks-only-message')->render();
    }

    public function schema(JsonSchema $schema): array
    {
        return [
            'is_thanks_only' => $schema->boolean()->required(),
        ];
    }
}

We ask for is_thanks_only, true or false, and Laravel's AI SDK hands back a validated shape, no parsing required. The prompt handles the nuance: it ignores quoted text, signatures, and "Sent from my iPhone" footers, counts "bedankt", "merci", and "danke" as thanks, and when in doubt classifies as not thanks-only.

Fail toward the safe behaviour

A model can be slow, rate-limited, or simply down. So the whole check fails in the safe direction.

try {
    $response = (new DetectThanksOnlyMessageAgent($ticket->workspace))
        ->prompt($messageText);
} catch (Throwable $exception) {
    Log::warning('Thanks-only detection failed; reopening ticket as usual', [
        'ticket_id' => $ticket->id,
        'message_id' => $message->id,
        'error' => $exception->getMessage(),
    ]);

    return false;
}

return (bool) ($response['is_thanks_only'] ?? false);

The expensive part is allowed to fail. The cheap fallback, reopening the ticket like we always did, is always underneath it.

Leave a trace

We never keep a ticket closed silently. Instead we record it as an activity on the ticket, with its own sparkles icon in the timeline.

if ($allowSuppression && $this->messageIsThanksOnly($ticket, $message, $textOverride)) {
    app(RecordTicketActivityAction::class)->execute(
        ticket: $ticket,
        type: ActivityType::ReopenSuppressed,
        properties: ['message_ulid' => $message->ulid],
    );

    return true;
}

app(ChangeTicketStatusAction::class)->execute($ticket, TicketStatus::Open);

So anyone scanning the ticket sees that a thank-you arrived and we chose to leave it closed. If we ever get it wrong, it's in the history instead of being a mystery.

In closing

This feature isn't rocket science. Nobody subscribes to a helpdesk for how it handles the word "thanks." But small things like this add up. They decide whether a tool feels good all day or like a thousand paper cuts.

We notice paper cuts like this because we use There There ourselves, every day, to support Mailcoach, Flare, and all other Spatie products. When something is annoying, we feel it before you do, and we fix it. Reopen suppression is just one of dozens of small fixes like that.

That's why we think There There can be one of the best helpdesks around: it's shaped by the people who use it every day.

There There is a Laravel app. That surprises nobody who knows us. At Spatie we've been building quality Laravel applications since the framework's early days, so it's the foundation we know best. The interesting parts are the choices around the edges, so let me walk through the whole thing.

Laravel, on purpose

We've shipped Laravel apps for over a decade. We know its sharp edges and its escape hatches, and that accumulated knowledge is worth more to us than the newest framework of the month. Boring, in the sense of predictable, is a feature here. It means we spend our days on support workflows and AI, not on reinventing queues and authentication.

The app runs on the latest PHP and Laravel. Sign-in is handled by Fortify, with Socialite for logging in through Google and GitHub. API access uses Sanctum and Passport, depending on the client.

Inertia and React for the front end

The interface is built with Inertia and React, with TypeScript and Tailwind throughout. Inertia is the part I'd recommend to anyone building a Laravel app with a rich front end. You get the single-page feel without standing up and maintaining a separate API. The server stays the source of truth, and a controller hands a React page its props directly.

We use Wayfinder to generate typed functions for our routes, so the front end calls backend endpoints without us copying URLs around by hand. When a route changes, TypeScript tells us what broke.

A structure organised by domain

Instead of letting app/Models and app/Http grow into a sprawl, we organise the code by domain. Each big concept in the app gets its own folder with everything it needs close by.

app/Domain/
  Tickets/
  Channels/
  Brain/
  Workspace/
  Ai/
  Workflow/

Each domain holds its own models, actions, events, and the rest. Related code lives together, and it's obvious where a new feature belongs. If you want the full reasoning behind this approach, we cover it in depth in our Laravel Beyond CRUD course.

The AI part

The AI in There There runs on Laravel's AI SDK. When a ticket comes in, we gather context: the conversation so far, the customer's history, and the most relevant knowledge base articles. We find those articles with embeddings, so a search matches on meaning rather than on exact words. The model drafts a reply from that context, and it never sends anything to a customer on its own. A person always signs off.

MCP, in both directions

We lean on the Model Context Protocol two ways. There There ships an MCP server, so you can point an AI client at your workspace and have it read and manage tickets through a defined set of tools. Internally, our own agents use those same tools to do their work. The protocol gives the AI an explicit, safe list of actions instead of free rein over the database.

The unglamorous plumbing

A helpdesk lives and dies on boring infrastructure. Background work goes onto queues watched by Horizon. Live updates, like seeing a colleague pick up a ticket while you're looking at it, travel over websockets with Reverb and Echo. And we roll features out gradually with Pennant.

Keeping ourselves honest

Every change is covered by tests written with Pest, and we run Larastan over the codebase to catch type problems before they ship. Pint keeps the formatting consistent so nobody has to argue about it.

Our own packages

A fair amount of There There is held together by packages we wrote at Spatie and have leaned on for years. That isn't loyalty for its own sake. We reach for them because we already trust them in production.

Most of the data that moves between the backend and the React front end is shaped by laravel-data, and laravel-typescript-transformer turns those same objects into TypeScript types so the two sides can't drift apart. Ticket and channel queries are filtered and sorted with laravel-query-builder, and anything that needs a manual order uses eloquent-sortable.

Attachments on tickets and knowledge base articles are handled by laravel-medialibrary. When someone wants a ticket thread as a document, we render it with laravel-pdf, which drives a headless browser through Browsershot. The social share images you see when a page gets posted somewhere are generated on the fly by laravel-og-image.

Filling the knowledge base means reaching out to the wider web, so we fetch pages with our crawler, and we check records with dns when you connect an email channel. On the operations side, laravel-backup keeps the database safe, activitylog records who changed what, laravel-slack-alerts pings us when something noteworthy happens. There's more in the composer file, but you get the idea.

Used services

Beyond the code, a handful of hosted services keep There There running.

Flare is where our errors, logs, and performance data go. When something throws in production, we get the exception with full context, and the performance side shows us which routes and queries are slowing down before anyone files a ticket about it. It's our own product, so we feel every rough edge firsthand.

Oh Dear watches the site from the outside. Uptime, scheduled jobs that quietly stopped running, broken links, expiring certificates, mixed content, and more. When the site goes down or a cron misses its window, we hear about it straight away. That one's ours too.

Inbound and outbound email runs through Postmark. It's what turns an incoming email into a ticket, and a reply back into an email that lands in the customer's inbox.

Payments and subscriptions run on Stripe, wired into the app with Laravel's Cashier.

Hosting runs on UpCloud. These days we prefer infrastructure that's fully owned by European companies, and UpCloud, based in Finland, fits the bill, so that's where There There lives.

Even this blog

The blog you're reading is part of the story. It doesn't live in a database. The posts come from a content API, fetched and cached on demand, with the feed generated by a small package of ours. That let us add a blog in an afternoon instead of bolting a CMS onto the product.

In closing

None of these choices are flashy, and that's the point. A framework we know well, a structure that keeps code where you expect it, and a short list of well-worn tools let us spend our attention on the thing that actually matters: making support feel less like a chore. There There is built by the team at Spatie, the same people behind a long list of open source Laravel packages.