Monitor pytań o produkty (IdoSell)

Pytanie zadane przy produkcie w sklepie internetowym nie generuje powiadomienia w sposób, który da się przeoczyć — leży w panelu i czeka. Klient, który nie dostaje odpowiedzi przez dwa dni, kupuje gdzie indziej.

Program działający w tle, który regularnie odpytuje API, wykrywa nowe pytania i wysyła e-mail. Do tego możliwość odpowiedzi wprost z aplikacji, żeby reakcja nie wymagała logowania do panelu i szukania właściwego produktu.

Cykl jest prosty i zamknięty: odpytanie API, porównanie ze stanem lokalnym, filtracja duplikatów, powiadomienie, odpowiedź operatora, wysyłka do sklepu, potwierdzenie. Kluczowy jest krok trzeci — bez zapamiętywania, co już zostało zgłoszone, program przy każdym cyklu wysyłałby te same pytania od nowa.

Powiadomienia idą przez SMTP z SSL, dane dostępowe leżą w pliku konfiguracyjnym. Interfejs to Tkinter — narzędzie ma działać w tle i pokazywać się tylko wtedy, gdy jest coś do zrobienia.

Pytania publiczne przy produkcie mają jedną cechę odróżniającą je od zwykłej korespondencji: odpowiedź widzą wszyscy kolejni klienci. Dobrze napisana odpowiedź działa więc jak uzupełnienie opisu produktu i zdejmuje kolejne pytania, zanim padną — co czyni szybką reakcję opłacalną podwójnie.

Program powstał na bazie wcześniejszej aplikacji do dokumentów zamówień, co widać w strukturze kodu — ta sama warstwa konfiguracji, ta sama obsługa API. Ponowne użycie sprawdzonego szkieletu było tu tańsze niż pisanie od zera.

Obsługiwany endpoint to API administracyjne w wersji ósmej, z pełną obsługą zarówno odczytu pytań, jak i publikowania odpowiedzi.

Program zapisuje stan lokalnie w pliku konfiguracyjnym, bez bazy danych. Przy narzędziu obsługującym kilkanaście zdarzeń dziennie byłaby ona nadmiarem — a brak zależności oznacza, że aplikacja uruchamia się wszędzie, gdzie jest Python.

Czas reakcji na pytanie klienta spadł z „kiedy ktoś zajrzy do panelu” do kilkunastu minut. Program jest na tyle mały, że nie wymaga utrzymania — działa albo zgłasza błąd połączenia.