Taking care of busines

• Uue toote konfigureerimise juhend nii ühekordsetele kui ka igakuistele tasudele.
  Juhend sai koostatud koos ekraanikuvade ja selgitava tekstiga ning laetud üles sisevõrgu wikisse.
• Valmistada ette päring, mille alusel saaks kliendi kogu arve krediteerida.
  Läti klienditeenindus soovis teatud klientidele(60tk) krediteerida aprillis kogu arve. Lisatingimus oli, et kui kliendil on mõni kampaania hetkel aktiivne, siis see pikeneb 1 kuu võrra. Kahjuks seda tingimust meil ei ole võimalik rahuldada ja klienditeenindus leppis sellega.
• Leedu klienditeenindus avastas, et ühes olemasolevas raportis on teatud tootegrupp puudu.
  Grupp lisatud, tellija rahul.
• Kui mõne probleemi kallal liialt kaua töötada siis tekib nö 'tunnel-nägemine' ja aju keeldub elementaarseid lahendusi nägemast. Oli vaja lahendada üks sql-i probleem ära ja olin sellega hädas. Sellisel juhul tuleks võtta mingi teine teema käsile ja hiljem probleemi juurde tagasi tulla aga kahjuks ei saanud seda ülesannet edasi lükata ja lahendust oli kohe vaja. Palusin meie osakonna kõige noorema liikme(kogemust vähem kui 4 kuud) värsket pilku ja ta pakkus töötava lahenduse välja vähem kui 10 minutiga.

• Väline teenusepakkuja migreeris müügisüsteemi uuele serverile. Kuigi pöördumise aadress jäi samaks, siis migratsioonile järgneval päeval mitmed raportid ei töötanud. Kuna kogemus on näidanud, et raportite mitte jooksmisel võib olla erinevaid põhjuseid, siis ei saanud nii sama teenusepakkujale öelda, et raport X ei jooksnud ära, vaid tuli iga intsidenti uurida sügavuti ja välistada meiepoolsed vead ning alles siis anda teenusepakkujale konkreetset informatsiooni, milles probleem on. Teensuepakkuja vead taandusid kasutajaõigustesse - ei olnud lubatud SELECT lause ja teatud kaustad ei olnud kättesaadavad.
• Arvetetrüki teenusepakkuja teenusleping oli sõlmimise järgus ning ootas kinnitust, et tehniliselt parameetrid selles vastavad meie nõuetele ja vajadustele. Sai 2 muudatust tehtud.
• Seoses SEPA kasutuselevõtuga oli ühe kampaania konfiguratsiooni viga sisse jäänud ning ca 200 klienti said suurema arve kui oleks pidanud. Klienditeeninduse abiga sai koostatud vabandav sms ning klientidele saadetud samal päeval kui viga avastatud.

Kickoff

Probleem: Arveldussüsteem aktsepteerib ainult kindlas formaadis makesetefaili sisendit. Maksekanaleid, kust maksed tulevad, on mitmeid ja nad kõik omavad erinevaid failistruktuure. Hetkel on iga kanali jaoks tehtud oma 'programm', mis oskab vastava kanali faili lugeda ja seda arveldussüsteemi jaoks õigesse formaati konverteerida. Hetkel puudub kontrollmehhanism, mis välistaks juba töödeldud failide teistkorde töötlemise.Plaan: Jaanusega panime pead kokku ja otsustasime disainida universaalse lahenduse, millega saaks suvalisi faile liigutada ühest kohast teise, neid töödelda/konverteerida nii nagu vaja ja pidade järge juba töödeldud failidest.

Kokkuvõte: Jõudsime mõtetega sinnamaani:

· Sniffer tuuseldab ringi ja otsib erinevatest kohtadest faile ning käivitab vajalikke jobe
· Job kontrollib faili, loeb ridasid, valmistab faili ette ja söödab baasi
· Baasis on väike mehike, mis filtreerib ja sorteerib väljasid ning joonstab kõik ühe struktuuri järgi
· Tuleb sirge ja õhuke kettle, limselt CRM-i (kindlasti confitav), mis käib kolistab baasis ning otsib makseid, mida sisse kanda
· CRM kettle võtab batchide kaupa CRM-i sisse

Küsimuskohad

· Kuidas kontrollida, et meile tulevad ikka kõik maksed, mitte ei jää poolikuks kuskilt
· Kuidas määrame ära baasis töödeldavade failide staatused, kui palju neid tuleb
· Juhul kui teeme CRM-i välise kettle’i, siis hakkab tööle REPiga ja kuidas lahendame aegviitest tulenevad blöäbid

Praegu ootame hetkel, et CRm ütleks, milleks teevad nad maksete puhul custnumi-triki

Kui otsustame CRM-i sisese kettle’i kasuks, peame väga hästi läbi mõtlema, mida tahame edastada ja näha, et järgmised 10 a enam seda muutma ei peaks.