Nəbz
Nəbz (Azerbaijani for “pulse”) is built for contact-centre managers, quality and training teams, and the frontline agents they coach — at banks, telecoms and any company that serves customers by phone. Today, most companies only find out how an agent handled a difficult customer after something has already gone wrong and a complaint arrives. Quality checks are done by people listening to recorded calls, so only a small share of conversations is ever reviewed. It takes time, it costs money, and the result often depends on who happened to be listening. Agents, meanwhile, rarely get a safe place to practise the hardest moments of the job — an upset customer, a rushed request, pressure to skip a security check — before those moments happen for real. Nəbz changes this. An AI customer calls the agent with a realistic scenario, speaks Azerbaijani and reacts to what the agent says in real time. After the call, every part of the conversation is scored against the company’s own service standard, and each score points to the agent’s exact words, so it is easy to see why. A manager reviews the results and always makes the final decision. Agents get clear, specific feedback the same day, and managers can see where their team needs training — before customers feel it.
Preliminary score
- Value for the user19.5 / 25
A specific problem and a clear outcome from solving it.
- Prototype and use of AI24.0 / 30
A working core scenario, and what AI actually contributes to the result.
- Quality testing13.0 / 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.
What the judges wrote
- Claude Opus 5.5Preliminary77/100
- Strengths
- Your core loop runs end to end: an AI customer in Azerbaijani voice or text, a call scored against a rubric generated from the company's own standard, and a report where every score quotes the transcript. The engineering is unusually mature for a build day: server-side clamping and recomputation of scores, a low-confidence flag, ephemeral voice tokens, a transactional shared AI budget, and unit and integration tests. You described your failures honestly (Azerbaijani hallucinations, out-of-sync database writes) and turned the hallucination into a design rule: no quote means low confidence and a manager review. Your feasibility slide gives per-call costs, pricing and a concrete Baku pilot.
- To improve
- You ran a human-versus-AI scoring comparison but reported no results. Give the number of calls, per-criterion agreement, and how often the evidence rule caught a hallucination, so the quality claim has evidence behind it. Measure how well the system understands Azerbaijani, for example misheard or invented phrases per call, since this is your biggest stated risk. The track asks for an adoption metric, so name one and estimate it, such as QA minutes per call, the share of calls reviewed versus today, or time-to-feedback. Also fill in the '[ANY OTHER LIBRARIES OR TEMPLATES]' placeholder on the disclosure slide.
- GPT-6 AstraPreliminary75/100
- Strengths
- Your design connects company standards, Azerbaijani practice calls and evidence-linked coaching in a concrete training workflow, with managers retaining the final decision. Your README provides substantial implementation detail for persistence, voice fallback, score validation and shared-budget controls. Your specific language and database failures, together with the fixes described, make the testing account credible.
- To improve
- Your submission would be stronger with an actual call transcript and saved report, plus paired human-versus-AI scores across the scripted cases. Your quote requirement cannot catch words hallucinated into the transcript itself; validate evidence against audio and measure transcription and scoring errors separately. Your pilot should measure QA review time and missed security violations against current practice, and validate session costs using recorded API usage. Your open demo also needs authentication and role-based report access before real employee use.
The team
Ayşə Zurnayeva
developer
Sahib AlibabayevLead
developer
Əzizağa İmranzadə
product