Programele obișnuite de tichete sunt gândite pentru suportul făcut de la birou: cineva scrie, altcineva răspunde. O firmă care repară lifturi, centrale termice, instalații frigorifice sau echipamente de birou are nevoie de altceva. O aplicație de ticketing pentru teren urmărește un om care pleacă fizic la o adresă, cu piese în mașină, și se întoarce cu un raport semnat.
De aceea are trei fețe: dispeceratul, care primește și împarte solicitările; telefonul tehnicianului, unde se consemnează lucrarea; și fișa echipamentului, cu tot istoricul lui.
Aplicație ticketing pentru echipe care lucrează la client, nu la birou
Fără un sistem, solicitarea trece prin prea multe mâini. Clientul sună, dispecerul notează, tehnicianul primește adresa într-un mesaj, iar raportul se scrie pe un formular de hârtie care ajunge la birou odată cu mașina. Între timp nimeni nu poate spune sigur dacă intervenția s-a încheiat, ce piese au plecat din stoc și ce se poate factura.
Tichetul le leagă pe toate. Se deschide din orice canal (apel preluat de dispecer, email citit automat, formular sau portal pentru cei cu contract) și poartă cu el, până la închidere, tot ce s-a consemnat pe drum.
Dispeceratul: cine merge, unde și cu ce prioritate
Ecranul dispecerului arată tichetele deschise, ordonate după urgență și după timpul rămas până la termenul din contract. Alocarea ține seama de zona în care se află fiecare tehnician, de ce știe să repare și de cât are deja de lucru. Aplicația propune, omul hotărăște.
O hartă cu intervențiile zilei ajută la gruparea drumurilor. Poziția tehnicienilor se afișează doar dacă hotărăști asta, după informarea lor, și doar cât timp aplicația web e deschisă pe telefon; urmărirea angajaților are reguli proprii, pe care le lămurești cu juristul și cu responsabilul cu protecția datelor.
- Prioritate: stabilită din tipul defectului și din contract, nu din insistența celui care sună.
- Realocare: tichetul se mută la alt tehnician cu tot istoricul.
- Stări limpezi: nou, alocat, pe drum, în lucru, așteaptă piesă, rezolvat, închis.
- Revizii planificate: contractele de mentenanță generează singure tichete la intervalele stabilite.
Telefonul tehnicianului: poze, piese, semnătură
Tehnicianul nu instalează nimic din magazinul de aplicații. Folosește o aplicație web progresivă (PWA), adică un site care se poartă ca o aplicație: deschide camera și păstrează datele esențiale pe telefon când semnalul dispare, într-un subsol sau într-o cameră tehnică, apoi le trimite la revenirea conexiunii.
Lucrul fără semnal are limite, pe care le stabilim de la început: ce se poate completa deconectat și ce se întâmplă dacă tichetul e modificat între timp la birou. Limitele diferă între Android și iPhone, unde aplicațiile web au mai multe restricții (de pildă la trimiterea datelor în fundal), așa că încercăm pe telefoanele echipei. Semnătura trasată cu degetul confirmă primirea lucrării; nu este o semnătură electronică calificată, iar valoarea ei ca dovadă o stabilești cu juristul.
- Lista zilei: intervențiile în ordine, cu adresa deschisă direct în aplicația de navigație.
- Fotografii: înainte și după, cu ora atașată, legate de tichet.
- Piese și manoperă: ce s-a montat, din ce stoc (mașină sau depozit), cât a durat.
- Raportul de intervenție: generat ca PDF și trimis pe email imediat după semnare.
Timpii de răspuns din contract și istoricul pe echipament
Contractele de mentenanță prevăd de obicei în cât timp răspunzi și în cât timp remediezi. Trecem aceste praguri pe fiecare contract, iar tichetul primește un ceas. Ceasul ține cont de programul de lucru convenit și se oprește în stările care nu depind de tine, de pildă când aștepți acordul beneficiarului pentru o piesă. Înainte de depășire, dispecerul e avertizat.
Fiecare echipament are fișa lui: model, serie, locație, contract. Un cod QR lipit pe aparat o deschide direct din telefon, cu intervențiile anterioare și piesele schimbate, așa că tehnicianul care vine prima oară nu o ia de la zero.
Tehnologia folosită și intrarea aplicației în rutina echipei
Pe server rulează o aplicație PHP construită cu Laravel, peste o bază de date relațională. Fotografiile stau într-un spațiu de stocare separat, ca volumul lor să nu încetinească aplicația. Dacă piesele se țin într-un program de gestiune, legăm consumul din tichet de acesta, în măsura în care programul oferă o cale de schimb de date.
Rezistența vine de obicei de la oamenii din teren. Scade când raportul pe telefon durează mai puțin decât cel pe hârtie, lucru pe care îl verificăm cronometrând împreună cu ei.
- Datele de pornire: echipamente și contracte importate din tabelele existente, după o curățare făcută de voi.
- Dispeceratul: tichete, stări și alocare, folosite întâi doar la birou.
- Echipa de probă: câțiva tehnicieni lucrează de pe telefon și spun ce îi încurcă.
- Contractele: timpii de răspuns, alertele și rapoartele, adăugate la urmă.
Întrebări frecvente
De ce nu folosim un program de tichete gata făcut?
Dacă lucrezi mai ales de la birou, un serviciu existent e alegerea rezonabilă, iar produsele dedicate lucrului în teren merită încercate înaintea oricărei dezvoltări. Construcția la comandă are sens când contractele, tipurile de echipamente sau legătura cu gestiunea ta nu încap în ele.
Clienții pot deschide singuri tichete și pot vedea stadiul lor?
Da, printr-un portal cu autentificare, unde văd echipamentele din contract, tichetele deschise și rapoartele anterioare. Telefonul rămâne, dar dispecerul trece apelul în același sistem.
Aplicația ține și stocul de piese?
Ține evidența pieselor consumate pe fiecare tichet și, dacă vrei, a stocului din mașina fiecărui tehnician. Gestiunea contabilă a pieselor rămâne în programul de gestiune.
Aceasta este o descriere de proiect-tip: arată cum abordăm de obicei o astfel de lucrare și nu prezintă un proiect făcut pentru un client anume. Fiecare proiect real pornește de la situația firmei tale, iar etapele, termenele și prețul se stabilesc după discuția de început.