SITFD · PHP Version · Zendesk/WHMCS Gap Analysis

1 Who is client vs staff? The core question

In Zendesk, a ticket header always shows three things: requester name + avatar + role, assignee name + avatar + role, and company. In WHMCS, the same header shows client name + avatar + email + phone. SITFD shows only the requester name as plain text. There is no way to tell at a glance whether a message is from the citizen, the company, the agent, or the supervisor.

The timeline — same problem, repeated

Every message in the timeline (whether from the client, the agent, the supervisor, or an internal note) is rendered as a plain text block with the same font and color. Zendesk uses color-coded bubbles: client (blue, left-aligned), agent (green, right-aligned), internal note (yellow/lock icon). WHMCS uses a side-bar with reply type prefix ([Staff Note], [Client Reply], [System]). On SITFD, the only differentiator is a tiny "Internal note" pill that is easy to miss.

┌─────────────────────────────────────────────────────────────┐
│ TICKET HEADER            LAB-2026-000004                    │
│ Status: in progress        Priority: high                   │
│ Requester · Data Labs Karachi                              │   ← no avatar, no role, no email
│ City: Sukkur · Department: Labor                           │
├─────────────────────────────────────────────────────────────┤
│ TIMELINE                                                   │
│                                                             │
│  Hi, I am writing to bring to your notice... [client text]  │   ← looks like every other message
│  — 18 Aug 2026 09:42                                        │
│                                                             │
│  [Internal note]  Escalated to L2                          │   ← only differentiator is this tiny pill
│  — 18 Aug 2026 10:18                                        │
│                                                             │
│  We are looking into this. Will revert shortly. [agent]    │
│  — 18 Aug 2026 11:05                                        │
│                                                             │
│  …all use the same font, color, no avatar, no role badge…  │
└─────────────────────────────────────────────────────────────┘

What I tested in the browser — proof of the gap

• Browser SVG extraction of the ticket detail page: 0 avatar circles rendered.
• No `` tags, no `
• The "Internal note" badge is the only visual differentiator — it is 11px and monochrome.
• Requester field shows: <span class="font-medium">Data Labs Karachi</span> — that's it, no chips.
• Email/phone fields are absent from the requester block entirely.
• Open the same ticket as Company vs POC — the requester block is identical.

How Zendesk / WHMCS solve it

2 Departments — can you create one? Can you see counts? Can you move tickets?

A ticketing system needs three departmental capabilities: CRUD departments (create, rename, archive), per-department analytics (how many tickets are in each dept right now), and move tickets between departments (with an audit trail). I tested all three.

2.1 CRUD — partial

2.2 Per-department analytics — works on reports, missing on dashboard

2.3 Move tickets between departments — works, but no audit trail

POC and Admin can change a ticket's department from the ticket detail page (dropdown shown above the action buttons). The change persists. But the timeline after the move does not show a "moved from Health → Labor" event in the visible UI. The history table internally records it (the audit trail exists), but the user-facing timeline does not render it.

2.4 Dashboard widget is broken (separate bug)

Across all 9 roles, the dashboard metrics show 0 for every counter. The data is there (the Reports page shows 185 tickets, 38 open). The dashboard widget is querying a different endpoint or the wrong column. The dashboard also takes 15 seconds for Admin and 7.7 seconds for DG Labor on first load — likely a cold-cache issue.

3 Timeline — distinguish internal vs public, audit dept moves

The timeline is the heart of a ticketing system. It needs to answer three questions at a glance: who said this? who can see this? what changed?

3.1 Speaker identity — broken

• No avatar (no `` in the message block).
• No role badge (client / agent / supervisor not distinguished).
• Speaker name is plain text. On long threads, you cannot tell client from agent without reading the message.
• System events (status changes, dept moves, SLA pauses) are not rendered as separate event types.

3.2 Visibility — broken

• Internal notes are distinguished only by a tiny pill. There is no visual treatment on the surrounding message block (no bg color, no border, no icon).
• No "visible to client only" vs "internal only" indicator at the message level.
• No toggle to filter the timeline to "client-facing only" or "internal only".
• No "what would the client see right now?" preview.

3.3 Audit trail — partial

The history table internally records every state change (status, assignee, dept, priority). But the user-facing timeline does not render these as distinct event types. When a ticket moves from Health → Labor → Escalate → Resolve, the timeline shows a flat list of messages with no "system event" markers.

What Zendesk / WHMCS do

4 SLA — live timer, business hours, breach alarm

SLA is the single most important feature for a complaint system. The user said "how follow-up was done" — SLA tracking is the answer.

5 Macros, canned responses, time tracking

Three productivity features that turn a ticketing shell into a support workstation. All three are missing.

6 Other missing features (Zendesk/WHMCS checklist)

What works (don't rebuild)

• Auth + 9 roles + 1-click login URLs
• Department CRUD via API (update works, create needs UI)
• Reports — 7 report types, drill-down, CSV export
• KB search + articles + categories
• WhatsApp channel integration
• Anonymous ticket tracking via /track
• Public landing page with real stats
• Reference number uniqueness (no trailing-0 bug here)

7 3-phase build plan

From "functional shell" to "production ticketing system" in three sequential phases. Each phase is self-contained and shippable.

Before/after — requester block

Before/after — timeline

8 Quick wins (≤2 days)

The 5 highest-impact fixes that can ship without Phase 1 starting. Each is a single backend tweak + a small UI change.