The problem
Student services are often split across a portal's menus, result tables, and document views. For a student who only needs an assessment result or a transcript, repeatedly finding the right page adds friction. I explored how the same services could be reached through a familiar messaging interface.
The ASTU E-Student Assistant connects Telegram conversations to the existing university student portal. It covers student profiles, assessment results, transcripts, temporary identification documents, registration information, and upcoming events. The project developed across three related implementations during 2021 and 2022.
A guided conversation
The bot uses python-telegram-bot handlers to turn portal navigation into a sequence of explicit choices. A student signs in, selects a service, and follows the relevant menu. Assessment workflows narrow the request through semester and course selection before returning the result. Transcript workflows similarly keep the selection steps separate from document delivery.
Back navigation, invalid-input handling, and sign-out paths are part of the conversational structure. These details matter because a bot receives individual messages rather than a complete form: each response has to be interpreted in the context of the current step.
SQLite stores application state, while administrator handlers support maintenance tasks such as managing administrators, sending announcements, and controlling access to temporary-ID generation.
Connecting the portal to Telegram
The later implementation separates three responsibilities:
- Conversation handling: Telegram commands, menus, callbacks, and the transitions between student-service workflows.
- Portal integration: Requests-based functions for profiles, course identifiers, assessments, transcripts, registration, and events.
- Document rendering: Pillow-based helpers that turn structured results into legible images for delivery inside the chat.
Keeping document layout outside the message handlers makes it easier to change how a result is presented without rewriting the portal connection. The rendering layer handles academic tables and identification layouts, including text, images, and barcode elements where the document requires them.
Evolution and outcome
The earlier version placed much of the interaction and rendering logic in a single application file. Later versions extracted connection and document helpers, giving the same student-service experience a clearer internal structure. These are iterations of one integration project, rather than separate products.
The outcome was an implemented conversational interface spanning several everyday academic tasks. It demonstrated how to adapt an existing service to a new channel while keeping retrieval, interaction, and presentation distinct.
This case study describes the historical implementation; it does not imply current availability or compatibility with today's university portal. The lasting engineering lesson is that a useful integration depends on the small transitions as much as the endpoint calls: selecting the right record, recovering from an unexpected input, and returning information in a form the student can actually read.