AfterCall AI: Telecom CRM Assistant
Who this is for: Customer support agents and call center team leads at mobile network operators (e.g., Azercell, Bakcell, Nar) and other telecom providers. What goes wrong today: After every customer call, agents spend an average of 3–5 minutes manually typing up the call summary, filling out the CRM form, assigning a priority (P0–P3), and figuring out which internal department (Roaming, Billing, Network) should handle the ticket. This manual process causes four major problems: Slow resolution times: Agents waste time on admin instead of solving the next customer's issue. Human error: Urgent issues (P0/P1) are often misclassified as low priority, and tickets are frequently misrouted to the wrong department. Frustrated customers: Long hold times caused by "After Call Work" delay responses. Blind management: Team leads have no real-time data to see if 20 people are suddenly calling about the same network outage. Our solution reads the call transcript, automatically extracts the data, assigns the correct priority/department, and saves it to the CRM in under 10 seconds.
Preliminary score
- Value for the user19.5 / 25
A specific problem and a clear outcome from solving it.
- Prototype and use of AI19.0 / 30
A working core scenario, and what AI actually contributes to the result.
- Quality testing12.0 / 20
Tests, examples of failures, and comparison with the current approach.
- Feasibility7.5 / 15
Data requirements, running costs and a clear next step.
- Originality5.0 / 10
A meaningful difference from common solutions.
What the judges wrote
- Claude Opus 5.5Preliminary62/100
- Strengths
- You target a specific user (telecom call-center agents and team leads in Azerbaijan) and a specific pain: after-call work. You anchor it with Azercell call volumes and your own timing measurement. Your prototype covers a real workflow: an Azerbaijani transcript goes in, the LLM extracts 8 fields with priority and department, the operator approves, and the case is saved to a CRM. Repeat-caller escalation and mass-issue alerts sit on top, all deployed on Streamlit. Your testing write-up is honest and specific. You name the vague-roaming failure (T4), explain the deliberate null Contact Info choice, and describe the priority-escalation bug you caught and fixed.
- To improve
- Your test set of 8 synthetic transcripts is too small to support the 94% and 88% figures. Your manual baselines (85% field accuracy, 70% priority accuracy) have no source. Test on 30–50 varied or real anonymised transcripts and time real agents for comparison. Reconcile your numbers too: the deck says 95 seconds of manual work while the submission says 3–5 minutes, and 45/48 fields does not match 8 transcripts × 8 fields. Add running costs (Groq tokens per call times monthly call volume) and a concrete pilot step with an operator. Explain how you would handle Azerbaijani speech-to-text, since the prototype currently starts from a ready-made text transcript.
- GPT-6 AstraPreliminary64/100
- Strengths
- Your workflow addresses a concrete telecom support burden, combining structured extraction, department routing and operator approval rather than offering a generic chatbot. Your reported eight-case annotated evaluation identifies useful failures, including ambiguous roaming descriptions and a corrected priority-escalation bug. Your explicit limitations around transcript-only input and temporary SQLite storage make the prototype's scope clear.
- To improve
- Show a reproducible end-to-end example covering transcript input, extracted fields, operator approval, storage and an alert. Expand testing beyond eight synthetic transcripts, define which fields contribute to the 45/48 accuracy figure, and include operator-reviewed examples. Reconcile the deck's 95-second manual baseline with the submission's 3–5 minutes, substantiate the manual accuracy estimates, and measure review-and-save time rather than inference alone. Document per-ticket running costs, customer-data protections and a concrete pilot using persistent CRM storage.
The team
Suleyman Hebibli
developer
Elvin BayramliLead
data
Qəndab Mikayılova
data