Until now, a client logging into their PtahCast portal could see exactly one thing: a read-only delivery forecast. The moment they had an actual question — "I found a bug," "can you check on this," "what's happening with the thing I asked about last week" — the portal had nothing for them, and it went to email or Slack instead, off-platform and untracked. That's the other half of client communication this product was missing, and it's live now: clients can file a support ticket, follow it, and reply on it, in the same place, with the same login, they already use for their forecast.
What it does
An agency turns this on per client — nothing appears until you choose to enable it, and it isn't a plan-tier upsell; it's available on every plan the moment you flip it on for a given client. Doing so creates a dedicated support board for that client, seeded with its own workflow: New, Triaged, In Progress, Waiting on Client, Resolved. It's a separate board from their delivery work on purpose — different columns, different audience for "what's in progress," and a throughput history that belongs to support requests alone, not mixed into the numbers a delivery forecast relies on.
From their portal, a client can file a ticket with a title, description, urgency, and an optional attachment. Every contact for that client sees every ticket filed by anyone at that client — the same client-wide visibility the delivery report already uses, rather than each contact only seeing their own requests. Worth knowing if a client happens to have internally siloed stakeholders, but for the overwhelming majority of client relationships this is exactly the transparency you'd expect from colleagues sharing one support queue.
Replies work both ways. A client can follow up on their own ticket, and your team can reply back — or leave an internal note instead, visible only inside the agency. The composer makes that an explicit choice every time, not a checkbox easy to miss: reply to the client, or note it internally. A client-authored comment is never anything but client-visible; there's no way for a client-portal account to post something that only your team sees, because the option is simply never shown to them. New tickets email your Owners and Admins; a client-visible reply emails the client back — no dashboard-watching required on either side.
The part nobody else in this market does
Any helpdesk tool can show a status column. What none of them show a client is an honest, data-driven answer to "how long." PtahCast's support board runs through the exact same Monte Carlo engine that already forecasts every delivery board — so the client's ticket list carries a live queue forecast: "current support queue: forecast to clear in about 4 days (P70), 7 days (P85)." And each ticket's own page goes one step further, with a per-ticket estimate based on where that ticket actually sits in your priority order right now — a real, recalculated-on-the-fly answer to "when does mine get looked at," not a fixed SLA date pulled from a contract.
That per-ticket number is explicitly labeled for what it is: an estimate based on queue position, assuming tickets get worked in roughly the order they're prioritized — not a guarantee, and the portal says so in plain language rather than implying more certainty than the number actually has. It's the same honesty PtahCast already applies to a Commercial (P85) delivery date; there was no reason to abandon that principle just because the queue in question is support tickets instead of project scope.
What it doesn't do
Deliberately scoped narrow, on purpose:
It isn't a combined capacity model. A client's delivery board and their support board each keep their own throughput history — this doesn't attempt to model one shared developer pool split across both. That's a real, materially bigger idea for later, not something to guess at now.
Submission is portal-only. No email-to-ticket, no chat widget, no pulling tickets in from a client's own Zendesk or Freshdesk. If a client raises something, it comes in through the portal, the same authenticated channel everything else here already uses.
It's not trying to be a full helpdesk. No SLA rules engine, no canned responses or macros, no knowledge base, no CSAT surveys. This gives a client one honest place to ask and one honest way to see how long — it doesn't compete with Zendesk on breadth, because that was never the point.
Workflow columns are fixed at setup. The seeded New/Triaged/In Progress/Waiting on Client/Resolved columns can be renamed or rearranged afterward exactly like any other board, but there's no separate customization step before that.
Where it lives
On your side, the support board is just a normal Kanban board — the same one you already know, nothing new to learn. The only new agency-side UI is the reply/internal-note choice on the comment composer and a small indicator on any ticket a client is actually watching, so nobody on your team is ever in doubt about whether their next comment is about to land in a client's inbox. Turn it on for a client from their detail page whenever you're ready.