Zəngəzur
Human support agents at Azerbaijani telecom operators take over chats the chatbot couldn’t solve (Bot ↔ Müştəri). Each handover arrives as a long AZ/RU/EN transcript, so the agent has to read the whole bot conversation to work out what the customer wants, how upset they are and whether they’re about to leave for a competitor. Customers repeat themselves, angry or at-risk customers wait in the same queue as simple ones, and nobody records why the bot failed, so the same gaps keep sending chats to humans.
Preliminary score
- Value for the user21.0 / 25
A specific problem and a clear outcome from solving it.
- Prototype and use of AI25.0 / 30
A working core scenario, and what AI actually contributes to the result.
- Quality testing17.5 / 20
Tests, examples of failures, and comparison with the current approach.
- Feasibility13.0 / 15
Data requirements, running costs and a clear next step.
- Originality6.5 / 10
A meaningful difference from common solutions.
A finalist: the live jury scored it 60.0 / 100 on stage.
What the judges wrote
- Claude Opus 5.5Preliminary84/100
- Strengths
- Your user is sharply defined: the human agent who inherits a failed chatbot chat in mixed AZ/RU/EN, shown with a vivid handover (T16) where a customer threatening to leave is told to restart the phone. Your evaluation is unusually honest and systematic: 40 hand-labelled chats with tricky cases, a keyword baseline, per-field accuracy, a named field where Gemini loses (bot-failure reason, 62.5% vs 67.5%), and concrete misses such as T17, T25 and T34 with explanations. The architecture shows careful thinking: PII masking before the model, schema-checked JSON, rule-based offers so the model never invents prices, a cache and an offline fallback with a badge showing who decided, all backed by 82 pytest tests. Your feasibility section gives measured token counts, a per-chat cost and a concrete two-week shadow pilot.
- To improve
- Your main claimed outcome, faster handling, is still unmeasured; even a small timed test with 2–3 outside people on the same chats, raw versus with the copilot, would turn an assertion into evidence. Your bot-failure reason field needs clearer definitions and an example for each reason, because 9 of 15 misses default to 'no permission'. The 26 s average latency (up to 152 s) is long for an angry customer waiting, so show paid-tier or single-model timings. The deck still names a different hackathon and track, and it says the prototype started on 8 October; align your materials with this event and clarify that timeline for the organisers.
- GPT-6 AstraPreliminary82/100
- Strengths
- Your prototype connects multilingual handover analysis, risk-based queues and editable Azerbaijani replies into a coherent agent workflow. Your separation of AI interpretation from masking and priced-offer rules provides sensible safeguards, while badges clearly distinguish Gemini from offline results. Your 40-chat evaluation provides concrete comparisons and named failures, including the important finding that Gemini underperforms on bot-failure reasons.
- To improve
- Your next evaluation should use independently labelled, held-out operator chats and a counterbalanced agent study measuring handling time and reply quality against the current manual workflow. Your bot-failure taxonomy needs clearer definitions, and FAQ drafts should require human approval before export, particularly given the 62.5% reason accuracy. Your live workflow needs a response-time target and mitigation for the measured 152-second worst case. Your cost estimate should use current prices for the deployed models rather than the older placeholder tariff.
The team
Samur Eyyubov
data
Rauf Yunisli
business
Kamal RüstəmliLead
product
Nihad Mahmudzadə
business