Ticket Yar تیکت‌یار

An internal tool that reads support tickets from Jira, finds relevant knowledge, and drafts a reply in Persian for a human agent to approve.

Role: Technical lead
Type: Internal product (Dotin)
Period: 2025 – present
Link: Not public

No public link: this is an internal tool at Dotin, a banking software company. A short demo video is available on request.

The problem

Support teams in banking get many tickets that repeat known issues, such as a failed service call, a known error code or an account-state question. Answers usually exist somewhere in team notes, but finding them for each ticket takes time.

My role

Technical lead and developer. I designed the prompt and RAG architecture, built most of the backend, and worked on the client dashboard.

Stack

TypeScript

NestJS (migrated from Next.js)

Prisma + PostgreSQL

Semantic search over embeddings

Vercel AI SDK generateObject + Zod

DeepSeek API

Jira REST / JQL

Winston

Cron schedulers

Swagger

Husky

How it works

A Jira connector pulls tickets into a queue for each business, using validated JQL filters.
Processing cycles run on a schedule. Tickets are classified and matched against the knowledge base with semantic search.
The model drafts a reply inside a fixed schema. If it cannot answer, it returns INSUFFICIENT_KNOWLEDGE (the gap is in the knowledge base) or NEED_MORE_INFO (the gap is in the ticket), rather than guessing.
A support agent approves, edits or rejects the draft, and approved replies are posted back to Jira.
A knowledge collector turns messy internal notes (Markdown) into clean knowledge entries.

Prompt design keeps the platform’s fixed rules in a system prompt. Instructions for each business sit in a clearly lower-priority section, so one business can’t override the safety rules.

Result

2m 25s → 34sBuild time after moving the backend to the SWC compiler

Built to a working MVP, which was demoed internally in early 2026.

What I learned

Separating “missing knowledge” from “missing ticket info” makes a non-answer useful. It tells the team whether to add a knowledge base entry or to ask the customer for more details.

Test data for the knowledge collector also had to be as messy as real support notes. Clean sample documents hid problems that real notes exposed.

How it works

A Jira connector pulls tickets into a queue for each business, using validated JQL filters.
Processing cycles run on a schedule. Tickets are classified and matched against the knowledge base with semantic search.
The model drafts a reply inside a fixed schema. If it cannot answer, it returns INSUFFICIENT_KNOWLEDGE (the gap is in the knowledge base) or NEED_MORE_INFO (the gap is in the ticket), rather than guessing.
A support agent approves, edits or rejects the draft, and approved replies are posted back to Jira.
A knowledge collector turns messy internal notes (Markdown) into clean knowledge entries.

Prompt design keeps the platform’s fixed rules in a system prompt. Instructions for each business sit in a clearly lower-priority section, so one business can’t override the safety rules.

What I learned

Separating “missing knowledge” from “missing ticket info” makes a non-answer useful. It tells the team whether to add a knowledge base entry or to ask the customer for more details.

Test data for the knowledge collector also had to be as messy as real support notes. Clean sample documents hid problems that real notes exposed.