Szerző: Vátáh Sándor

Kivétel nélkül minden levelező szolgáltatás üzemeltetője küzd a levélszeméttel. Mi is. Vannak időszakok, amikor a beérkező levelek 7-80%-a (!!) szemét. Mint minden szolgáltató, mi is önálló levélszemét szűrő rendszert alkalmazunk, ami elválasztja az ocsút a búzától. A nagy számok törvénye alapján elkerülhetetlen, hogy egy -egy spam átcsússzon a szűrőn, vagy épp ellenkezőleg: levélszemétnek nézzen egy legitim levelet.

Mindkettő egy formán bosszantó, de talán az utóbbi nagyobb hátránnyal járhat. Nem önzetlenül teszi a szolgáltató ezt: a szervereinken erőforrást, sávszélességet és tárhelyet is foglal a szemét, így minden szolgáltatónak jól felfogott érdeke, hogy minél hatékonyabb eszközökkel harcoljon a szemét ellen. Időről időre nekünk szegezik az ügyfelek a – jogos – kérdésüket: ez a levél mitől lett spam?

Itt az ideje tehát, hogy világossá tegyük, milyen szempontokat figyel a levélszemét szűrő rendszerünk. A levélszemét minősítés nem fekete vagy fehér: a rendszer pontokat osztogat az egyes „gyanús” jelekre. A rendszergazda által meghatározott pontszám elérése után minősül szemétnek a levél (heurisztikus módszer). A lista nem teljes, de a legfontosabbakat felsoroljuk. Figyelem: nem lesz rövid, de cserébe hosszú lesz.

1.) A levélhamisítás ellen: SPF rekord. Alapvetően bármely számítógép bármilyen feladó címmel küldhetett e-mail-t. Ennek következtében viszonylag egyszerű e-mailt hamisítani. Az SPF bejegyzést a domain adminisztrációjában módosíthatod, és abban domainenként meghatározható, hogy mely IP című szerver(ek) küldhet(nek) az adott tartományból legitim e-maileket. Ha az SPF rekordban az az IP cím nincs felsorolva amelyről érkezett a levél, az egy fekete pont.

2.) DMARC rekord (Domain-based Message Authentication, Reporting and Conformance) Az SPF rekord mellett a DMARC is egy e-mail hitelesítési módszer. Ha a fogadó e-mail szerver olyan levelet kap, ami nem felel meg az SPF rekord ellenőrzésen, akkor a DMARC beállítások határozzák meg, hogy mi legyen a levél sorsa. DMARC irányelvek: None: nincs művelet ebben az esetben, a levél feldolgozásra kerül. Reject: az üzenet el lesz utasítva. Quarantine: az üzenet spamként lesz megjelölve.

3.) Feketelista a visszaeső IP címekről. A bolygón sok szervezet foglalkozik azzal, hogy listát vezessen a csintalan IP címekről – azaz a túlnyomórészt levélszemetet küldő szerverekről. Amennyiben ilyen IP címről érkezik a levél, az egy rossz pont. Feketelistázós szervezetek pl: https://www.spamhaus.org/sbl, https://www.spamcop.net

4.) „Spam Trigger” szavak a levél tartalmában. Tipikusan ilyen szavak lehetnek a „pénz visszafizetési garancia”, „cselekedj gyorsan”, „100% elégedettség”, „viagra”, az „ingyenes” vagy a „vásároljon most”. Még rosszabb a kevert tartalom: egy e-mail, amely egy tartalomban említi a Rolex órákat, a Viagrát, a pornót és az adósságot, nagyobb valószínűséggel spam, még akkor is, ha minden más egyértelmű. Egy kis fekete pont jár érte, de ugyanúgy fekete pont jár a CSUPA NAGYBETŰS LEVELEKÉRT vagy a sok írásjel használatáért is!!!!!!!!!!!!!!!!

5.) Linkek a levélben. Önmagában egy (két) linek elhelyezése a levélben nem baj, de ha sok benne a link, az gyanús. Még nagyobb probléma, ha az oldal ahova mutat, tele van szemétgyanús tartalommal, vagy már feketelistázott domain. (Igen, a levélszemét szűrők ilyen alaposak: átfutják a linkek tartalmát is.) Non-plus-ultra: ha egy link elnevezése nem egyezik azzal, amire mutat, azaz megtévesztő.

6.) Sok azonos tartalmú levél. Ha több egyező tartalmú levelet kap a levelezőszerver, az nagy kövér fekete pontot ér. Nyilván, 5-10 levélnek lehet azonos a tartalma, de hat több tucat (több száz…) levél érkezik egyező tartalommal, igen csekély az esély arra, hogy legitim levél legyen. (Az eltérő, random generált feladó e-mail címek nem tévesztik meg a szűrőt!). Ráadásul van olyan világméretű rendszer, ami szerverek között is lehetővé teszi az összehasonlítást.

7.) Küldő e-mail cím / domain jó híre. Bizony, az e-mail címeknek is vigyázniuk kell a jó hírükre, mert különben szájára veszi őket a falu levezőszerverek ájtatos társasága. Sok non-profit szervezet üzemeltet Spamházakat, ahol pontozzák az egyes domaineket. Ha egy domainről már nagyon sok Spam lett küldve, az egy rossz pont. (Igen, a levélszemét-szűrők „jelenik” a spammelő domaineket.)

8.) Egy kép többet ér ezer szónál. Ezt azonban a levélszemét-szűrők is pontosan tudják, így ha nincs (vagy nagyon kevés a) szöveges tartalom az e-mailben (de csatolmányt tartalmaz), már gurul is a fekete pont.

9.) Reverse-DNS, alias rDNS, alias PTR rekord. Nem túlbeszélve a fontos tényezőt, próbálom egyszerűen elmagyarázni a működését. A névfeloldás azt jelenti, hogy a domain névből IP cím lesz, ami a kiszolgáló szervert azonosítja. De az IP címet is vissza lehet „fordítani” domain névre, aminek a sikeres levélküldéshez egyeznie kell a levelezőszerver nevével. Ha nem található meg a levelezőszerver neve az IP cím bejegyzéseiben, az már elég régóta rossz pont.

10.) DKIM aláírás (DomainKeys Identified Mail). Megint egy betűszó. Egyszerűen: a DKIM arra való, hogy egy digitális aláírás kerüljön be az e-mailbe, ami alapján ellenőrizhető, hogy a megfelelő jogosultsággal rendelkező fél küldte-e. Ebből a felhasználó nem lát semmit, de a levél forrásában benne van, a levelezőszerverek ellenőrizhetik. A DKIM nyilvános kulcsú titkosítást (public key encryption) alkalmaz, ami két kulcsból áll, egy titkos (private), és egy nyilvános (public) kulcsból. Rendszerint a publikus kulcsot a feladó domainjének névszervere szolgáltatja, DNS rekordként. A titkos kulcs pedig az e-mail aláírásához szükséges. Az e-mailt feladó levelezőszerver az e-mailt a titkos kulcs segítségével aláírja, amit az e-mail fejlécében helyez el. A fogadó levelezőszerver pedig a domainhoz tartozó névszervertől megkapott publikus kulccsal ellenőrzi az aláírás valódiságát. Ezzel a megoldással egyrészt garantálható, hogy a legitim feladótól származik az e-mail, és hogy azt „útközben” sem módosították. Okos dolog. Ha hiányzik / nem stimmel, az jó nagy fekete pont.

11.) Tiltott / gyanús fájlok a csatolmányban. Ősidők óta tilos .exe, .pif, .bat stb kiterjesztésű, futtatható fájlokat küldözni e-mailben. Ha zip állományt tartalmaz a levél, a szerver kicsomagolja, és megnézi mi van benne. Ha nem tudja kicsomagolni, – pl. jelszó miatt – megy a fekete pont. Előfordulhat, hogy egy ártalmatlan makrót tartalmazó csatolt .xlsx vagy docx fájlt tartalmaz a levél, de ez is egy okkal több, hogy levélszemétnek nézze a szűrő.

12.) Hirtelen sok e-mail egy IP címről. Ha egyszerre több száz vagy több ezer e-mail érkezik (pláne hasonló tartalommal), akkor nagyon valószínűtlen, hogy legitim levelek lennének. Gurul a fekete pont.

13.) Valaki(k) megjelölték levélszemétként a domaint / IP címet. Ez akkor fordul elő, ha egy nagyobb vállalat ugyanarról a domainről és / vagy IP címről küldi a hírleveleket (esetenként kéretlenül), mint amelyikről az üzleti levelezést bonyolítja. Ilyenkor a konkrét e-mail talán nem spam, de a domaint / IP címet már „bemocskolták” más küldött levelek, amiket a felhasználók „jelentették” (pl. azzal, hogy behúzták a levélszemét mappába).

14.) Sok a visszapattanó levél. Rossz hírű lehet a domain / IP cím attól is, ha nagyon magas a visszapattanó e-mailek aránya. A magas visszapattanó-arány arra utal, hogy a küldő nem biztos abban hogy a címzett létezik, csak lövöldöz vaktában. Már 1%-ért is repül a rossz pont.

15.) Túlzott HTML kód használat. A levélszemétszűrőket kaotikus és nagy számú szimbólumok, extra címkék vagy a Microsoft Word másolás-beillesztett kódja is aktiválhatja. Non-plus-ultra: ha a HTML kóddal láthatatlanná teszünk szövegrészeket. Néhány darab szmájlival nem lesz gond, de ha az emojik aránya eléri a betű-karakterek számát, azt a levélszemét-szűrő nem nézi jó szemmel. 🙂

16.) Területi / nyelvi különbségek. Az átlag felhasználó leveleinek a 99% saját országába irányul, és leginkább onnan érkezik. Nem katasztrófa ha más országból (pontosabban: más nyelvterületről) érkezik, de egy mákszemnyi fekete pontot azért kaphat. Ha egy levélben különböző nyelvi kódú szakaszok vannak, az rosszabb egy árnyalattal.

17.) Látványosan hosszú, generált vagy ominózus szavak az e-mail címben. Az álmoskönyv szerint sem jelent jót ha a feladó címében bounce@…, 3fgh5n4cgh51g6zh8f4z6h8f4hz3f5h@… , newsletter@, hirlevel@, marketing@… vagy valami hasonló van. Ezekért gurul a fekete pont.

Konklúzió

Nagyon fontos kihangsúlyozni: önmagában egyik kritérium teljesülésétől nem lesz szemétnek minősítve a levél. Mindig több kritériumnak kell teljesülnie. (Persze, nem minden kritérium kerül azonos súllyal beszámításra.) Mint mindenki a szakmában, mi is folyamatosan csiszolgatjuk, finomhangoljuk a rendszerünket.

Ezt a cikket azoknak az újságíró kollégáknak a segítségére írom, akiknek át kell szokniuk a print alapú újságírásról a webesre. A legtöbb kisebb magazin, webes blog vagy egyéb hasonló média WordPress-t motort használ (WP), ezért ilyen szemüvegen keresztül fogom én is pontokba szedni, hogy mire ügyeljenek,  milyen buktatókkal találkozhatnak a mindennapi cikkezés során. Egy kitűnő, témába vágó cikket olvashattok angol nyelven itt.

1.) Írjatok folyó szöveggel, nem kellenek a sortörések. Aki a cikket publikálja, majd bekezdésekre bontja, és beformázza. Egy átlag cikk kb. 3-5000 karakter, de legalább 2000, legfeljebb 10 000 karakter legyen. Alcímekkel érdemes 1000-1500 karakterenként elválasztani a gondolatokat. Csak H2-H6 címeket használjatok bekezdés címként, H1-ből csak egy lehet, az pedig a cikk címe lesz. A webes cikkekben rövidebb, egyszerűbb mondatszerkezetek használjunk mint az újságban. Kerüljük a barokk körmondatokat.

2.) A képek ne legyenek nagyobbak mint 1MB. Felesleges olyan képeket feltölteni, amelyeket az olvasó képernyője nem tud megjeleníteni. A képekhez rendeljetek „Helyettesítő szöveget” (alt tag) és „Címet” is, ezek kapcsolódjanak a képhez. Ha a képen Kabos Gyula látható, akkor a kép címe Kabos Gyula legyen, vagy „Kabos Gyula ellenőrzi az e-mail fiókját”. Ez SEO szempontból is fontos. Legjobb a webp vagy jpg kiterjesztésű kép, kerüljük a git és a png képeket. Ne felejtsd el a „Kiemelt kép” beállítását sem. A Kiemelt kép lehet a cikk egyik képe, de lehet olyan kép is, ami nem szerepel a cikkben.

3.) Használjatok hivatkozásokat más cikkekre! Ez a lehetőség nem adott a papíron de weben igen, éljünk vele! Keressünk a tartalomhoz kapcsolódó cikkeket / forrásokat, és linkeljük be őket. Sokkal hitelesebb a cikk, ha hivatkozik más releváns tartalomra. (Az sem feltétlenül baj, ha eltérő nyelvű a linkelt tartalom.) Kb. 1000 karakterenként egy linket helyezz el! A legjobb, ha vegyesen vannak külső (más weboldalakra) és belső (ugyanezen oldal másik cikkére) linkek.

4.) Használjátok a „More” szeparátort a bevezető szöveg (header) elválasztására. A „More” szeparátor feletti részt több helyen is használja a WP. A header 3-500 karakternél ne legyen hosszabb. Ha lehet, töltsétek ki a „Kivonat” („excerpt”) mezőt is. A kivonat (excerpt) mezőbe csak tisztán szöveget írhatunk, a html formázásokat a WP kiszedi. Ha más dokumentumban írjátok meg a cikket (pl. Wordben), majd másolással teszitek be a WP szerkesztőjébe, ügyeljetek rá, hogy a formázást ne hozza magával a cikk! Formázás nélküli beillesztés Windows alatt: Ctrl + Shift + V, Mac alatt: Shift + Option + CMD + V

5.) A papír alapú médiában nincs jelentősége, de a weben törekednünk kell a SEO szempontok figyelembe vételére. Törekedjünk rá, hogy a cikk lényegi mondanivalója (a „kulcskifejezés”) szerepeljen a cikkben legalább 3-5 alkalommal (bekezdésenként legalább egyszer). Ellenben kerüljétek a kulcsszavak zsúfolását, tehát minden mondatban ne szerepeljen a kulcskifejezés. Példa: ha a cikk témája a Cannes Nemzetközi Filmfesztivál, akkor a „Cannes Nemzetközi Filmfesztivál” szerepeljen kb. 1000 karakterenként egy alkalommal (azaz: egy átlagos 3000 karakteres cikkben 3 alkalommal). Lehetőleg a cikk fő témája (kulcskifejezés) szerepeljen a cikk címében.

6.) Minden cikkek címkézzünk! Ha valaki rákeres, a WP rendszerében egy kulcsszóra, a címkék segítenek a találatokban. Törekedjünk a weboldal belül a címkék közötti konzisztenciára. Ehhez a cikkhez pl. passzolna a „WordPress”, „útmutató”, „cikkírás” címke.

7.) SOHA NE HASZNÁLJUNK CSUPA NAGYBETŰT, vagy feleslegesen vastagított betűt. A legtöbb modern böngészőben már van helyesírás-ellenőrző, jellemzően nem téved. Vegyük figyelembe az ajánlásait. A webes cikkeknél nem probléma, ha hozzányúltok helyesbítési céllal a cikk publikálása után. Inkább javítsuk a pontatlanságot, mintsem ott maradjon örökre. Egyetlen dolgot ne módosítsatok publikálás után: a cikk címét. Ez ugyanis a cikk elérési útjának (URL-jének) a módosulását jelenti, aminek az lesz a következménye, hogy kívülről nem lesz elérhető a cikk ugyanazon a címen.

Sok oldalon sokféle praktikát írnak a WP alapú oldalak sebességének növelésére. Alább összeszedem a nekünk bevált gyakorlatot. Ha nem az első weboldalad építed, valószínűleg találsz majd ismert tippeket a listában, de remélem találsz néhány újat is. Egy gyorsabb weboldal nem csak a keresők organikus listáján visz előbbre, de jobb felhasználói élményt is nyújtasz vele az ügyfeleidnek.

Ha egyáltalán semmi fogalmad nincs arról amit csinálnod kellene, akkor légy óvatos: egy félresikerült módosítással elérhetetlenné válhat az oldal, vagy – jobb esetben – csak lassabb lesz mint előtte. Lesznek olyan javaslatok, amelyek végrehajtásához a webtárhelyedet üzemeltető cég rendszergazdájának a közreműködésére is szükség lesz.

A sebességérzés néha szubjektív, így érdemes internetes weboldal sebesség mérőket használni. Én az alábbi kettőt használom (mert mindkettő másban jó):

https://pagespeed.web.dev/

https://gtmetrix.com/

A Pagespeed esetében a cél: mobilon 70+, asztali gépen 95+ pont elérésre. A GTmetrix esetében a cél az „A” kategória, és 95+ pont megszerzése. Alább többször használni fogom a „kulcsszavak” kifejezést, amivel arra szeretnék utalni, hogy ezek a kulcsszavakat érdemes keresgélned az interneten.

1.) Válasszunk olyan szolgáltatót, aki gyors (SSD alapú) tárhelyet kínál. Tudom hogy ez közhely, de egy lassú, elavult szerveren hiába optimalizálod szét az oldalad, lesz egy plafon amit nem tudsz áttörni. Tehát inkább szánj rá egy kicsivel több pénzt, és olyan tárhelyet vásárolj, ahol tisztán SSD-n fut a weboldalad, és legalább 256MB memóriát adnak a fiókodhoz. (Az SSD-n és a memórián kívül ezer más dolog befolyásolhatja a sebességet. A lényeg, hogy tárhely és tárhely között nagy különbségek lehetnek.)

2.) Használd a legfrissebb WP verziót, sablon (templét) verziót és PHP verziót. Ha a sablonod nem támogatja a legfrissebb PHP verziót, akkor fontold meg a sablon cseréjét.

3.) Csak a valóban szükséges pluginokat telepítsd, és azokat is tartsd frissen. (Nincs nehéz dolgod – van automatikus frissítés.)

4.) A webszerver használjon HTTP/2-t. Nem sok szerver van már ahol nem így van, de egy kérdést megér. Könnyű ellenőrizni, csak írd be a weboldalad címét a keresőbe: https://tools.keycdn.com/http2-test Csak a tárhelyszolgáltatód tudja ezt módosítani.

5.) Használj gyors névszervereket! Az első byte megérkezésig számított időt („TTFB” = Time To First Byte) akár jelentősen befolyásolhatja egy kimaradozó, lassú névszerver. (Meg sok minden más is.) A jelenlegi névszervered (a feloldás) sebességét pl. itt is ellenőrizheted a „DNS Check” funkcióval: https://mxtoolbox.com/SuperTool.aspx Ha gyors a névszervered, akkor 20-25 msec alatt lesz a feloldás. Ha efölött van, akkor cselekedni kell, vegyél igénybe ingyenes, gyors névszervereket (a domain regisztrátorodnál tudod módosítani a névszervereid). Javasolt névszerver pl: Google DNS, Cloudflare, stb. Ha a TTFB 200ms alatt van, az jó, ha 200-500ms között, az átlagos, ha 500ms fölött, akkor munkád van vele. A teljes betöltési idő lehetőleg maradjon 1sec alatt, és az oldal teljes méreted 1MB alatt. A TTFB csökkentésében korlátozott a mozgástered. Ha nagyon magas és elfogytak az eszközeid, fontold meg a tárhely váltást.

6.) Tömörítsd a javascript és a CSS fájlokat. A legtöbb cache plugin tudja a tömörítést, mint pl a Total Cache, WP Super Cache, stb. (Nem az a lényeg hogy melyik plugint használod, hanem hogy értsd, hogy mit csinálsz vele.) Tömörítéskor kikerülnek a szóközök, kommentek, üres sorok. Kisebb fájl 7 gyorsabb betöltés. A kicsi (2-3kB-nál kisebb) CSS fájlokat inkább inline illesztesd be, ha van ilyen lehetőség. Kulcsszavaid: minification, minifying, JS compress, CSS compress

7.) Használj memória alapú cache-t a szerveren, mint pl: Redis, APC/APCu, Memcached (php-memcached), eAccelerator, PHP-Opcache (php-opcache), XCache stb. (Nem kell mindet egyszerre, mindegyik másra jó!) Ha nincs, kérd meg a tárhely üzemeltetőd hogy telepítse. (A Total Cache pluginnal könnyű megtalálni az optimálist.)

8.) Apache webszerver alá javaslom telepíteni a Google-féle Pagespeed modult. (mod_pagespeed) Ezt csak a webszervert üzemeltető rendszergazda tudja megcsinálni, ha teheted kérd meg rá. Számtalan kitűnő lehetőséget kínál: https://www.modpagespeed.com/ Érdemes globálisan kikapcsolva tartani, és a .htaccess fájlból be lehet kapcsolni a szükséges funkcióit: https://www.modpagespeed.com/doc/config_filters

Példakód a .htaccess-be:

<IfModule pagespeed_module>
	ModPagespeed On
	ModPagespeedRewriteLevel OptimizeForBandwidth
	ModPagespeedEnableFilters collapse_whitespace,remove_comments,prioritize_critical_css,defer_javascript
</IfModule>

9.) Használj korszerű formátumú, kis méretű képeket. Javaslom a webp vagy a jpg használatát, és egy átlag kép ne legyen 500kB-nál nagyobb. (Inkább kisebb.) Online konverter is van, pl: https://cloudconvert.com/webp-converter

10.) Ne felejtsd el méretezni és optimalizálni a képeket. (width=”xx” height=”xx”) A böngésző a képek betöltése előtt már elkezdi az oldal renderelését (felépítését). A képméretek megadása segíti a képi elemek méretének kijelölését. Ha nincsenek megadva méretek, lassítja a megjelenítést. A kevésbé fontos képeket (ha a sablon lehetővé teszi) ne is jelenítsd meg mobil nézetben.

11.) Ha nem standard fontokat használsz, akkor ne real-time betöltéskor illeszd beőket. Számtalan plugin képes letölteni egy könyvtárba, és onnan használni. (Pl. OGMF). Használj helyi fontokat!

12.) Ha nincs ellenérv, használj valamilyen CDN-t! (A Cloudflare-nek pl. van budapesti szervere is, mi is ezt használjuk.) A CDN használatának számos előnye van: a gyorsabb betöltés mellé kapsz DDOS védelmet, gyors névszervereket, és csökkented a webszerver terhelését. Vannak ingyenes szolgáltatók is, csak nyerhetsz vele.

13.) Kerüld a nagy külsős JS könyvtárak betöltését, mint pl a Facebook plugin, stb. Inkább tegyél ki egy linket, de ne ágyazd be. A CSS fájlok általánosságban az oldal tetején, a JS fájlok az oldal alján legyenek (ha nincs ellenérv). Több plugin is van ami ezt lehetővé teszi, a kulcsszavak: „async”, „defer”. (A kettő egy picit más, de bármelyik jobb mint a semmi.)

14.) Használj tömörítést! A legegyszerűbb a gzip vagy a deflate, a legjobb a Brotli. Itt tudod ellenőrizni, hogy tömörítés működik-e az oldaladon: https://www.giftofspeed.com/gzip-test

15.) Használd ki a böngésző gyorsítótárazását! A böngészőkben is vagy cache (gyorsítótár), ráadásul ezért semmit sem kell tenni, csak engedélyezni kell a használatát. A látogatók számára annál gyorsabb nincs is, mintha a saját gépükön van tárolva a file. Itt tudod precízen ellenőrizni fájltípusok szerint: https://www.giftofspeed.com/cache-checker/

A munka úgy zajlik, hogy módosítasz valamit, aztán a fenti sebességmérő eszközökkel megnézed, hogy jobb lett-e vagy rosszabb. Egy mérés nem mérés, mérj kettőt, és átlagold. Ha CDN-t használsz, akkor a reszelgetés idejére kapcsold ki, hogy a valós eredményt lásd. Remélem, segítettem. 🙂

Van néhány trükk amit ha megtanultok, olyan hibajegyet fogtok írni, amivel sokkal gyorsabban megoldhatjuk a problémákat. De nem csak mi, bármilyen szolgáltató. A tanácsaink – amit alább megosztok veletek – általános érvényűek.

1.) Megfogalmazás

Ha a hibajegy szövegéből munkatársunk nem tudja kibogozni hogy mi a hiba, akkor könnyen lehet hogy félreérti vagy egyáltalán nem érti meg a problémát. Elképzelhető, hogy munkatársunk nem ugyanazt látja mint Ön, ezért a „Nem látni semmit” szövegből nem tud helyes következtetést levonni. A jól megírt ticket töredékére csökkentheti a hibakeresésre fordított időt, ami Önnek is jobb. A helyesen megírt ticket az alábbi ismérvekkel rendelkezik:

1. Megtalálható benne a hiba keletkezésének a pontos helye. (Pl: A „Listák” menüpont alatt a „Fontos listák” almenüpontban szerettem volna „Napi listát” nyomtatni.)
2. Tartalmazza, hogy mi az elvárt működés. (Pl: Leszűrtem a mai munkalapokra, majd rákattintottam az alul lévő „PDF letöltése” gombra.)
3. Tartalmazza a hibát. (A PDF-et letöltöttem, de a 4. sor 6, oszlopában hibás az adat. Itt 142Ft-nak kellene lennie, és 123Ft van.)

Ha a munkatársunk nem érti a problémát, akkor válaszban kérdezni fog, ami késlelteti a megoldást.

2.) Reprodukálhatóság

A munkatársunk a hibajegy feldolgozását általában a hiba reprodukálásával kezdi ezért bonyolultabb probléma esetén sokat segít, ha a reprodukálás lépéseit is leírjuk. Ha a hiba egy konkrét fájl feldolgozásához kapcsolódik (pl nem nyitható meg, illetve nem importálható), akkor csatolva kérjük szépen az adott fájlt is. Ha a munkatársunk nem tudja reprodukálni a hibát, akkor „Nem reprodukálható” státusszal le fogja zárni a hibajegyet. Ha lehetséges, akkor ne generálisan jelezze a hibát (pl. „Nem lehet Excelt generálni”) mert akkor Munkatársunk az első helyen ami kézre esik neki megpróbál egy Excelt generálni, és ha sikerül akkor „Nem reprodukálható” státusszal szintén le fogja zárni a hibajegyet (hiszen nem tudja hogy hol fordult elő a hiba, ezért azt gondolja, hogy mindenhol fennáll a probléma). Nem válható el életszerűen a munkatársunktól, hogy egy generálisan jelzett hiba esteén (pl. „Nem lehet Excelt generálni”) minden lehetséges helyet végigpróbáljon, ahol Excel fájlt lehet generálni.

3.) Képernyőkép, ha van

Általában segít, ha a hibajegyhez képernyőképet is csatolunk, azonban a képernyőkép ÖNMAGÁBAN nem tekinthető releváns információnak kollégáink számára. Csak akkor segít, ha szövegesen is leírjuk hogy mi a hiba, és – ha van relevanciája – alátámasztunk egy vagy több képernyőfelvétellel.

4.) Szeparálva jobb

Ha egyszerre több témában is van mondandója, nagy a késztetés hogy egy ticketben írja meg. Ezt a módszert azonban mégsem ajánljuk, mert a feldolgozáskor kiderülhet hogy nem összefüggésben lévő témákról van szó, így az egyes részproblémák más és más eljárást igényelnek. (Pl. az egyik rendellenes használat következménye, de a másik valóban bug.) Ezért munkatársunknak nehéz visszajeleznie a „csomagra”. Emiatt kérjük, hogy minden egyes problémát külön ticketben küldjön be részünkre, így mindegyikre a megfelelő módon tudunk reagálni.

5.) Körülmények, eszkaláció

Ha van rá mód kérdezze meg a kollégáit is, hogy náluk is előfordul-e ugyanez a hiba. Összetettebb hiba esetén sokat segít, ha tudjuk, hogy mi volt az előző mozzanat (Pl. frissítettük a böngészőt, vagy az operációs rendszert.) Amennyiben e-mailben küldi a hibajegyet, ügyeljen rá hogy benne legyen az Ön elérhetősége (pl. mobil telefonszám) is. Amennyiben Ön a nálunk regisztrált e-mail címével küldi be a hibajegyet, munkatársunk látni fogja, hogy Ön milyen szolgáltatásainkat veszi igénybe. Amennyiben nem ilyen email címről küldi (akár azért mert épp azzal van a hiba), akkor a hibajegyben tüntesse fel az Ön nevét, és a vállalkozás nevét.

6.) Egy esetet csak egyszer!

Nagy a kísértés, hogy ugyanazt az esetet az ember több példával, több ticketben a több előfordulást is alátámassza. Ez nem segít, inkább csak plusz időt emészt fel, hogy felismerjük: ugyanaz a probléma van leírva egy másik szemszögből, másik példával. Ugyanígy hátráltat minket, ha több eset beküldése után kapunk egy „összegző” ticketet, amiben sorba szedve megkapjuk az előző három ticket tartalmát („Tehát akkor összefoglalva az alábbi problémák vannak még…”). Egy esetet tehát egy ticketben kérünk akkor is, ha több esetben fordul elő ugyanaz a jelenség, és összegző hibajegyre sincs szükség.

Az új szoftverek bevezetésének csupán kb. 50%-a lesz sikeres a KKV szektorban.

De miért ez a borzalmas arány? Megmondom. Elárulom, mi az a 5 (+1) fontos szabály, amit ha betartasz, elkerülöd a szoftver bevezetés legáltalánosabban elkövetett buktatóit. Lehet, hogy te is tapasztalt, elkötelezett cégvezető és tulajdonos vagy, de te sem látod a céged „kívülről”. Többek között ezért is hasznos a coaching, de ne kalandozzunk el. Az a 20 éves tapasztalatom, hogy a közepes, és a közepesnél nagyobb vállalkozások aránytalanul sikeresebben vezetnek be új rendszereket a cégnél mint a kicsik. A teljesség igény nélkül az alábbi 5 (+1) tippen van, amire általánosságban ügyelni kell, hogy ne csússz el ugyanazon a banánhéjon mint a többiek.

1. szabály: alaposan próbáld ki a rendszert!