Client part of the application collection and custom CRM for their processing

A parser needs to be created to collect competitor prices, with a catalog of over 40,000 products. Access to the prices is only available under authorization.

Good day, I need help with creating the logic and implementing an idea. A chat-bot for tracking the status of document production for an educational center.

Hello. Below is a conditional technical specification for the bot for our synagogue. We need not just a Telegram bot, but a convenient mini-application for the synagogue and community, through which a person can navigate the life of the synagogue, quickly get the necessary information, view the schedule, learn about events, register, and interact with us. In terms of style and logic, we can base it on the reference bot we showed, but we need a better version: more convenient, modern, useful, and with a clearer structure. If you have strong opinions on design, UX, and structure, and you see how to improve it, we are open to suggestions. The main idea: for a person to quickly navigate the life of the synagogue through the bot. What should be in the bot. 1. Main screen with specific buttons The main screen should have clear large buttons: Today Schedule Events Shabbat Jewish calendar My dates A-Yom Yom for today Synagogue services Contacts Donate Settings 2. "Today" section This is one of the main sections. A person enters and immediately sees what is happening today. What should be displayed: what is today's Jewish date what prayers are today what time they take place what events we have in the synagogue today important dates and events in the Jewish world if relevant — time for lighting candles and the end of Shabbat Buttons inside: Prayers today Events today Jewish date Shabbat / candles More details 3. "Schedule" section Through it, a person should conveniently view the schedule. Buttons: For today For tomorrow For the week For Shabbat For holidays What inside: Shacharit Mincha Maariv lessons meals holiday services other activities with time and, if necessary, location It is important that the administration can easily update this schedule. 4. "Events" section A full section on events is needed. What should be included: upcoming events all events card for each event registration In the event card: title date time location short description register button more details button Examples of events: Shabbat lesson youth meeting lecture charity lunch women's / men's meeting holiday outing 5. "Shabbat" section This should be a separate section, not just part of the schedule. What inside: time for lighting candles time for prayers time for meals time for the end of Shabbat weekly Torah portion brief information about the upcoming Shabbat registration for Shabbat Buttons: Upcoming Shabbat Shabbat schedule Weekly portion Register for Shabbat What you need to know 6. "Jewish calendar" section What should be included: today's Jewish date upcoming holidays Rosh Chodesh fasts memorial dates brief explanation of the day / holiday Buttons: Today Upcoming dates Holidays Rosh Chodesh Memorial dates 7. "My dates" section We take this idea from the reference, but want to make it useful. The user should be able to save: birthday Jewish birthday yahrzeit other important dates What the bot should do: store these dates remind about them allow setting notifications Buttons: Add date My dates Reminders Delete date 8. "A-Yom Yom for today" section What should be included: text for today convenient beautiful display ability to view the previous / next day share button Buttons: Today Yesterday Tomorrow Share 9. "Synagogue services" section This needs practical navigation. What can be included: registration for a lesson registration for Shabbat registration for an event ask a question volunteering charity programs other services / directions of the synagogue 10. "Contacts" section Should include: address phone Telegram Instagram YouTube email ways to contact us if necessary, geolocation Buttons: Call Write Open address Instagram Telegram YouTube 11. "Donate" section It needs to be done neatly and clearly. What should be included: donate button payment methods details / link brief explanation of what the funds are for contact for donation questions 12. "Settings" section The user should be able to configure: language daily notifications notification time Shabbat reminders holiday reminders reminders for personal dates Buttons: Language Notifications Shabbat Holidays My dates Enable / disable mailing 13. Daily mailing We need the bot to send people relevant information every day: what prayers are today what time they take place what events we have in the synagogue today what important dates and events are in the Jewish world today if relevant — time for candles / end of Shabbat That is, a person opens the bot in the morning or receives a message and immediately understands the picture of the day. 14. Registrations and sign-ups Through the bot, there should be an option to register for: Shabbat lessons events meetings other activities Logic: a person presses a button leaves their name phone / username if necessary, additional data the application goes to the administrator / to a table / to CRM 15. Admin section It is important for us that the bot is easy to manage. The admin should be able to: update the prayer schedule add and edit events change texts launch mailings see registrations and applications change contacts and links It is important that this is really convenient for maintenance, not too complicated. 16. Support and development At the first stage, it is not necessary to do everything at once; a strong first version can be launched, and then supplemented in the process. But it is important to immediately foresee: the possibility of expansion support and maintenance of the bot after launch bug fixes improvements during use 17. What is important in the end We need a bot that will become a mini-application for our synagogue and help a person navigate conveniently: what is today what prayers what events what will happen on Shabbat how to register how to contact where to view the Jewish schedule what is happening in our synagogue and in the Jewish world If you see how to make the structure, buttons, design, and logic better than in the reference bot, that is a plus. We need not a clone, but a stronger, more convenient, and modern version. https://www.hebcal.com/home/developer-apis Chabad.org

Development of a Telegram bot: a closed platform-marketplace for experts I am looking for a developer (or a small team) to create a Telegram bot — a closed platform that connects verified experts and clients for solving professional tasks. The model is similar to a service marketplace with a supervising administrator, rather than a fully automated service. What is ready: A detailed technical specification (30+ pages) — user roles, step-by-step UX flows with button texts, status models for Requests/Cases, data model, payment status model, admin panel. Key functionality: - Two user roles (client / expert) with the possibility of combination - Verification of experts through the administrator (without automatic decision approval) - Selection and moderation of requests by the curator - Internal communication space within the bot (without disclosing contacts between parties) - Payment status model: escrow, confirmation of funds receipt, payments - Referral system with bonuses - Administrative panel with extended access rights Expected stack: at the discretion of the developer (Python/Node.js), the main thing is — experience with Telegram Bot API, working with states (FSM), databases, and payment integrations. Collaboration format: work based on the ready technical specification, discussion of deadlines and budget after reviewing the document. What to send: examples of implemented Telegram bots (preferably — with complex state logic or payments), an estimated timeline and cost.

Technical assignment for the client search automation system in Telegram Development 1. General task It is required to create an MVP system for automatic client search in Telegram chats with the provision of found users to sales department operators. The system should consist of: user bots based on Telethon; Telegram bot for operators; Telegram bot (or a separate administrative section within the bot) for the administrator; PostgreSQL database; Docker configuration for deployment in configuration. A web panel is not required at this stage. 2. Working with multiple Telegram accounts The system must not be limited to one Telegram account. It is necessary to ensure support for multiple accounts (for example, 5 or more) with the ability to increase their number without changing the configuration. For each account, there should be the ability to: authorize via Telethon; maintain its own session; connect a new account; disconnect an account; replace an account without losing the database. The administrator should be able to independently connect new Telegram accounts. 3. Distribution of chats among accounts The system will use a large number of Telegram chats (approximately 800 or more). All chats are included in a single system. The system should automatically: manage chats among connected accounts; observe Telegram restrictions; Handle the need to transfer a chat to another account; Prevent duplication of one chat by multiple accounts (unless specifically included). It is desirable to ensure load balancing among accounts. 4. Managing the chat list The administrator should be able to do this without the developer's involvement: connect a chat; delete a chat; import a list of chats from a file; bulk upload chat costs; enable or disable monitoring of individual chats; restart history collection for a selected chat. After adding a new chat, the system automatically includes it in one of the key accounts. 5. Data collection For each connected account, it is necessary to implement: Initial parsing After adding a chat: loading message history for the specified period; saving all available information. Monitoring After the initial loading is completed: constant tracking of new messages; saving new users; saving new activity of existing users. 6. Handling Telegram blocking requires proper handling: FloodWait; PeerFlood; temporary Telegram restrictions; erroneous connections; connection breaks; possible reconnections; temporary unavailability of the account. If one account is temporarily blocked by a restriction, the rest of the work continues. 7. User data storage. For each user, the following should be saved: Telegram ID; first name; last name (if available); username; profile link; list of all chats; message text; date and time of the message; link to the message (if obtainable from Telegram). User merging is performed exclusively by Telegram ID. If a user has written in 20 chats — they display one card. 8. User card The operator should see: first name; username; Telegram ID; profile link; list of all chats; messages; activity date. Example: User: Ivan Ivanov ID user : 123456789 Chat "Business": Message: "Good day, interested in advertising" Date: 01.03.2026 12:15 Chat "Marketing": Message: "Who is handling promotion?" Date: 05.03.2026 18:42 9. Operator work The system should automatically form a queue of clients. After receiving a client: the user is assigned to an operator; the second operator cannot receive the same client; maintain a history of actions. Statuses: Took the client; Unavailable; Could not reach; Refusal; In progress; Call back; Delete. After selecting a parameter, the next client will automatically open. 10. Reissuing users There should be an option to configure user reissuance. For example: never; after 30 days; after 60 days; after 90 days; arbitrary period. 11. Administrative section The administrator should be able to: Account management add an account; delete an account; view account status; view account restrictions; replace an account. Chat management add; delete; import; export; disable monitoring; disable monitoring. Operator management add; delete; block; change rights. Parser management start collection; stop collection; rebuild history; view current status. Statistics View: number of users; number of messages; number of processed clients; number of active operators; number of connected accounts; number of active chats. 12. Database Use PostgreSQL. It is necessary to store: users; messages; chats; activity; Telegram accounts; operators; processing statuses; processing history; distribution of chats among accounts. 13. Scalability The architecture should provide the ability to: connect 10, 20 or more Telegram accounts; connect thousands of Telegram chats; handle load; export data; work with CRM; connect new features without a complete project overhaul. 14. Docker The executor should set up: docker-compose.yml; Dockerfile; launch instructions; update instructions; database backup instructions. The system should manage the command as one.