PRO-KOM Serwis System
System do zarządzania procesem napraw sprzętu elektronicznego — od przyjęcia zgłoszenia, przez diagnozę i statusy, aż po odbiór przez klienta. Projekt inspirowany 2,5-letnim doświadczeniem w realnym środowisku serwisowym.
3
panele użytkownika
RBAC
system uprawnień
8+
zadań Celery async
HTTPS
Let's Encrypt
DEMO
System w praktyce
Najważniejsze widoki panelu pracownika i administratora pokazujące realny workflow serwisu: obsługę zgłoszeń, Kanban, szczegóły naprawy, historię zmian, dashboard oraz zarządzanie procesem.
Ze względu na poufność danych firmowych i danych klientów nie udostępniam publicznego logowania do panelu pracownika oraz administratora. Zamiast tego przygotowałem zanonimizowane widoki systemu, które pokazują najważniejsze elementy workflow: obsługę zgłoszeń, Kanban pracownika, szczegóły naprawy, historię zmian, dashboard administratora i zarządzanie procesem serwisowym.
Podczas rozmowy technicznej mogę przejść przez architekturę systemu, kod oraz wybrane widoki panelu w formie prezentacji lub screen share.
Mam przygotowaną pełną galerię ponad 30 widoków panelu pracownika i administratora — od zgłoszenia naprawy po dashboard, historię zmian i zarządzanie serwisem.
Zobacz pełną galerię widokówGENEZA
Problem, który rozwiązuję
Ten projekt zbudowałem z perspektywy osoby, która przez 2,5 roku pracowała w serwisie elektroniki. Dzięki temu dobrze rozumiałem, gdzie w codziennym procesie napraw ginie informacja, co spowalnia obsługę i czego realnie potrzebuje klient, pracownik oraz właściciel.
Brak samoobsługowego statusu naprawy
Klient musiał kontaktować się telefonicznie, żeby dowiedzieć się, co dzieje się z jego urządzeniem. System rozwiązuje to przez panel statusu, powiadomienia i przejrzystą historię zgłoszenia.
Ręczne zarządzanie pracą serwisu
Proces opierał się na notatkach, arkuszach i ręcznym pilnowaniu priorytetów. Panel pracownika porządkuje naprawy w widoku Kanban, pokazuje statusy, przypisania i zadania wymagające reakcji.
Brak jednego widoku danych operacyjnych
Właściciel potrzebuje szybkiego dostępu do danych: czasu napraw, obciążenia pracowników, popularnych usterek, przychodów i stanu magazynu. Panel admina zbiera te informacje w jednym miejscu.
ZAKRES
Moja rola w projekcie
Projekt indywidualny. Pomysł, architektura, implementacja — całość samodzielnie.
Modelowanie domeny
Przełożyłem realny proces serwisowy na model danych Django: zgłoszenia, urządzenia, klienci, statusy, wyceny, części, historia zmian i lifecycle naprawy.
Trzy panele użytkownika
Zaprojektowałem osobne przepływy dla klienta, pracownika i administratora: self-service dla klienta, Kanban dla staffu oraz panel zarządczy dla admina.
Zadania async i powiadomienia
Wykorzystałem Celery i Redis do obsługi powiadomień, automatycznych przypomnień, backupów oraz zadań wykonywanych poza głównym request-response cycle.
Bezpieczeństwo i audyt
Zaimplementowałem system ról i uprawnień, JWT auth, historię zmian, audit log oraz mechanizmy wspierające kontrolę dostępu do danych.
DESIGN
Architektura systemu
Architektura została zaprojektowana wokół trzech paneli użytkownika: klienta, pracownika i administratora. Frontend Next.js komunikuje się z backendem Django/DRF, a zadania tła obsługuje Celery z Redis.
Users
Trzy różne typy użytkowników z osobnymi potrzebami i uprawnieniami.
Frontend
Interfejs systemu, widoki paneli, stan aplikacji i komunikacja z API.
Backend
REST API, logika domenowa, autoryzacja i obsluga requestow.
Domain Modules
Moduły odpowiadające za główne obszary procesu serwisowego.
Data & Async
Baza danych, cache, kolejka zadań i operacje wykonywane w tle.
Security & Deploy
Kontrola dostępu, historia zmian, reverse proxy i bezpieczne wdrożenie.
Dlaczego taka architektura?
Trzy osobne przepływy użytkownika
Klient, pracownik i administrator widzą ten sam proces naprawy z różnych perspektyw i mają różne potrzeby.
Modułowy backend Django
Naprawy, klienci, magazyn, analityka i auth są rozdzielone na osobne moduły z jasną odpowiedzialnością.
Celery dla zadań w tle
Powiadomienia, przypomnienia, backupy i raporty nie blokują głównego request-response cycle.
RBAC i audit log
System wymaga kontroli dostępu, historii zmian i możliwości odtworzenia przebiegu obsługi zgłoszenia.
Pokaż techniczny diagram ASCII
┌─────────────────────────────────────────┐
│ Nginx (Reverse Proxy + HTTPS/TLS) │
│ Port 80/443 │
└───────────┬─────────────┬───────────────┘
│ │
┌───────────▼───┐ ┌──────▼──────────────┐
│ Next.js 14 │ │ Django 5.1 + DRF │
│ Port 3000 │ │ Gunicorn │
│ │ │ Port 8000 │
│ ├ Panel Klienta│ │ ├ Auth API │
│ ├ Panel Staff │ │ ├ Repairs API │
│ ├ Panel Admin │ │ ├ Inventory API │
│ └ Public Site │ │ └ Analytics API │
└───────────────┘ └──────┬──────────────┘
│
┌───────────────┼──────────────┐
│ │ │
┌─────────▼──────┐ ┌─────▼───┐ ┌──────▼──────┐
│ PostgreSQL 16 │ │ Redis 7 │ │ Celery │
│ Primary DB │ │ Cache/ │ │ Workers │
│ │ │ Queue │ │ │
│ ├ Repairs │ │ │ │ ├ Emails │
│ ├ Clients │ │ │ │ ├ Reminders│
│ ├ Inventory │ │ │ │ ├ Backups │
│ └ Audit Log │ │ │ │ └ Reports │
└────────────────┘ └─────────┘ └────────────┘FUNKCJE
Kluczowe funkcje techniczne
Kanban Board dla pracowników
Drag-and-drop zmiana statusów napraw. Kolumny: Przyjęte → W trakcie → Gotowe → Odebrane. Widok priorytetów, przypisań i zgłoszeń wymagających reakcji.
Automatyczne powiadomienia
Celery Beat uruchamia zadania związane ze zmianą statusów, przypomnieniami i komunikacją z klientem. Klient może śledzić naprawę bez telefonowania do serwisu.
RBAC + Audit Log
Role: klient, pracownik, administrator. System zapisuje historię zmian statusów, edycji zgłoszeń i działań użytkowników, co ułatwia kontrolę oraz audyt.
Zarządzanie magazynem
Katalog części zamiennych, rezerwacja części pod naprawę, stany magazynowe, zamówienia hurtowni oraz powiadomienia o niskim stanie.
Analityka i raporty
Dashboard admina pokazuje czas napraw, obciążenie pracowników, przychody, najpopularniejsze usterki i dane potrzebne do podejmowania decyzji.
Bezpieczeństwo i wdrożenie
HTTPS przez Let's Encrypt, ochrona CSRF/XSS, rate limiting, walidacja danych, autoryzacja po rolach oraz hashowanie haseł po stronie Django.
WYZWANIA
Najtrudniejsze problemy
Miejsca, w których projekt wymagał najwięcej decyzji architektonicznych.
Modelowanie lifecycle naprawy
Naprawa przechodzi przez wiele stanów, a każdy status może uruchamiać inne akcje: powiadomienia, przypomnienia, zmianę widoczności dla klienta lub aktualizację kolejki pracownika.
→ Enum-based status field, jawna logika dozwolonych przejść oraz zadania Celery uruchamiane przy zmianach statusu.
RBAC z trzema różnymi UX flows
Klient, pracownik i administrator mają różne potrzeby, uprawnienia i widoki tego samego zasobu. Ten sam obiekt naprawy musi być prezentowany inaczej zależnie od roli.
→ Custom permission classes w DRF, osobne serializery i kontrolowana reprezentacja danych dla każdej roli.
Implementacja bez gotowego wzorca
To był mój pierwszy duży projekt z pełnym stackiem Django + Next.js + Docker, dlatego wiele decyzji architektonicznych musiałem podjąć samodzielnie.
→ Modularna architektura, wydzielenie logiki do services/selectors/serializers oraz regularny code review z wykorzystaniem AI jako wsparcia.
WNIOSKI
Czego się nauczyłem
Jak przełożyć realne procesy biznesowe na model danych i lifecycle statusów
Modułowa architektura Django — każda app ma jedną odpowiedzialność
Clean Architecture w praktyce: selectors, services, serializers
Docker + Nginx + Certbot — pełny proces wdrożenia aplikacji webowej
Zarządzanie złożonymi uprawnieniami RBAC w DRF
Budowanie z perspektywy użytkownika — doświadczenie w serwisie dało mi realny kontekst
DEMO
Co możesz sprawdzić w demo
zgłoszenie naprawy jako klient
panel statusu naprawy
Kanban board dla pracownika
zmianę statusów i przypisań
panel administratora
historię zmian i audit log
dokumentację API w repo / w kodzie
Zaciekawił Cię ten projekt?
Chętnie opowiem więcej o architekturze, procesie serwisowym i decyzjach technicznych, które podjąłem podczas budowy.