Support System

Stakeholders

Marked by whether the system as built actually serves them.

• Closed tickets are immutable; a customer reply creates a linked follow-up.

  A closed ticket has already been counted in resolution metrics. Reopening it silently rewrites history. A follow-up keeps the record intact and still carries the context through a link.

  Alternatives considered

  • Reopen on any customer reply - simplest, but it corrupts resolution metrics
  • Allow reopen for a window after closing - familiar, but adds a second rule to explain

  Trade-off: Agents see a new ticket number for what the customer thinks is one conversation, so the link has to be easy to follow.

• SLA clocks pause in pending and on hold, and resume in business time.

  Waiting on a customer or a third party is not the agent's delay. Measuring it as one punishes the wrong people and hides real slowness behind noise.

  Alternatives considered

  • Wall-clock SLAs - simple, but nights and weekends cause breaches nobody caused
  • Pause only for pending - leaves on-hold tickets accruing time while waiting on someone else

  Trade-off: Resume has to recompute due dates against a calendar, and an agent can misuse pending to stop a clock. That needs a metric to watch, which is on the KPI list.

• Sticky routing sends returning customers to their previous agent when that agent is eligible.

  Customers resent repeating themselves, and continuity shortens resolution. The eligibility checks (online, in shift, skilled, language, optional capacity) keep continuity from stranding a ticket with someone who cannot work it.

  Alternatives considered

  • Always route by queue strategy - fair, but discards context
  • Always send to the previous agent - best continuity, worst when they are away

  Trade-off: Continuity can load one agent unevenly. The policy lets a workspace choose whether capacity is respected, and rebalancing protects sticky assignments by default.

• Routing behaviour is a layered policy, not a set of fixed rules.

  Queues differ. A billing queue wants continuity, and a first-line queue wants speed. Defaults, workspace, and queue layers let each differ without copying configuration.

  Trade-off: Behaviour depends on three places, so the settings page has to show which values are overridden.

• Record the method and reason for every assignment.

  Agents and supervisors will ask why a ticket landed where it did. A reason stored on the ticket answers that without anyone reading code or logs.

  Trade-off: More fields to store and display on every ticket.

• Two-layer tenant isolation: application filters plus forced row-level security.

  A missed filter in a multi-tenant system is a data breach. A second, database-enforced layer turns that mistake into an empty result.

  Alternatives considered

  • Application filters only - simpler, one bug away from a leak
  • A database per tenant - strongest isolation, much heavier to operate

  Trade-off: Cross-tenant jobs must opt in explicitly, and every tenant table must carry the policy.

• A transactional outbox instead of a message broker.

  Events are written in the same transaction as the change they describe, so there is no state where a ticket changed and nobody was told.

  Alternatives considered

  • Kafka or a queue service - more throughput, more infrastructure for a system of this size
  • Publish after commit - simple, but loses events on a crash

  Trade-off: Delivery is at least once, so every handler has to be idempotent.

• Leave AI out.

  The product question was whether the ticketing rules hold up. A language model would have added a feature to demo and nothing to test.

  Trade-off: The system lacks the capability a buyer will ask about first. It is on the roadmap as a later item, with its dependencies named.

• Resuming an SLA clock correctly: the due dates have to move by business time, not elapsed time, and the calendar includes holidays and a timezone.
• Deciding what a customer reply does in each state. The code reopens solved and pending tickets and leaves on-hold tickets alone, which is a rule worth stating rather than discovering.
• Routing without double-assigning under concurrency, solved with a per-queue advisory lock so different queues still route in parallel.
• Keeping rebalancing from undoing continuity, which is why untouched tickets only, a minimum wait, and sticky protection are all conditions.
• Writing a PRD after the build and keeping it honest about the gaps.

• No real users, no customer discovery, and no measured outcomes.
• Runs locally against seeded demo data. There is no hosted deployment.
• No continuous integration, and no measured test coverage.
• Backend unit tests cover a minority of modules; security properties are checked by a smoke test.
• Frontend tests are limited to one unit test file and four browser tests.
• No AI features of any kind.
• File attachments are stored on local disk.
• The knowledge base uses full-text search, not semantic search.
• OpenAPI documentation covers part of the API.
• No billing, no customer portal, and no single sign-on.

• 01The hard part of a ticketing system is the rules between the states, not the states. A reply to a pending ticket and a reply to an on-hold ticket are different product decisions.
• 02A policy a supervisor cannot read will not be changed. Describing each rule in plain language was as much design work as the rule.
• 03Recording a reason on every automated decision is cheap when you design for it and expensive to add later.
• 04A fair SLA is a product choice with a cost. Pausing clocks protects agents and gives them a lever to abuse, so the metric that watches the lever belongs in the same document.
• 05Writing requirements after the build is documentation, not analysis. It was still the fastest way to find where the code and the intent disagreed.

Product Management

Product scopingWorkflow and state designPolicy designSLA designPrioritisationKPI definitionRoadmap planningTrade-off analysis

Business Analysis

Requirements elicitationPRD and user storiesAcceptance criteriaProcess mappingPersona developmentCompetitive positioningGap analysis

Software Engineering

GoREST API designPostgreSQLRow-level securityTransactional outboxNext.jsReactTypeScriptWebSocketsTesting

Tools

GitDockerPlaywrightVitestOpenAPI