Príklady a architektúry v tejto sérii vznikajú ako moje osobné vzdelávacie a nekomerčné experimenty; nejde o ponuku IT alebo poradenských služieb.
Príspevok #11 bol o peniazoch, ktoré firma odosiela, a v akom poradí. Tento je o peniazoch, ktoré majú prísť dovnútra — a väčšinou aj prídu, kým ticho neprestanú, z dôvodov, ktoré nikto nikde nezapísal.
Zákazníci, sumy aj poradie vymáhania nižšie sú kompozitnou ilustráciou postavenou na vzorcoch, ktoré som opakovane videl u finančných tímov v priebehu rokov; nepopisujú konkrétnu spoločnosť, zákazníka ani konkrétny beh vymáhania.
Jedna kontrola pohľadávok, osemnásť faktúr po splatnosti, jedno poradie, ktoré nikto vedome nerozhodol
Čo ukazuje prehľad pohľadávok podľa splatnosti, a čo neukazuje
Počet dní po splatnosti nie je nikde skrytý. Je to prvý stĺpec na každom prehľade pohľadávok, nanovo zoradený každý týždeň pre každého, kto si chce pozrieť. Chýba iný záznam — ktoré upomienky skutočne priniesli peniaze, a ako zriedka to sedí s tým, ktoré faktúry sú jednoducho najstaršie.
| Ako to vyzerá | Ako to naozaj je |
|---|---|
| Upomienky vyberú peniaze v poradí, v akom boli odoslané | Vyberú peniaze podľa toho, čo upomienka skutočne ohrozuje — nie podľa toho, kedy odišla |
| Najstaršia faktúra sa vymáha najhoršie | Čerstvá faktúra od pomaly platiaceho zákazníka sa môže vymáhať horšie než stará faktúra od spoľahlivého platcu |
| Väčšie faktúry sa vymáhajú dôraznejšie | Podľa mojej skúsenosti sa menšie faktúry často vyberú rýchlejšie, pretože nikto nechce kvôli peniazom riskovať väčší vzťah |
| Počet dní po splatnosti predpovedá, koľko pozornosti faktúra dostane | Počet dní po splatnosti väčšinou len určuje, ako vyzerá v prehľade — nie to, čo sa stane ďalej |
Prečo poradie nie je počet dní po splatnosti
Zvyčajne nič z toho nie je preto, že by niekto nerozumel platobným podmienkam. Deje sa to preto, že „rozhodnúť, ktorého zákazníka tento týždeň upomenúť" zvyčajne nie je jeden konkrétny, niekým vlastnený krok — je to výsledný efekt toho, kto si náhodou všimol pohľadávku, a toho, či sa jej vymáhanie zdalo stáť za riziko pre vzťah. Zákazník, ktorému je blokovaná nová objednávka, sa zvykne upomenúť do hodiny, pretože blokácia je páka už dnes; tichý, väčší účet s deväťdesiatimi dňami po splatnosti ostane nedotknutý ešte mesiac, pretože nikto nechce byť ten, kto to vyhrotí.
Počet dní po splatnosti je fakt o faktúre. Či peniaze naozaj prídu, je fakt o tom, kto sa pýta a čo pri tom žiada.
Čo v skutočnosti rozhoduje o tom, ktorá upomienka zaberie
| Signál | Čo to spraví s poradím |
|---|---|
| Aktívna blokácia kreditu, ktorá bráni novej objednávke zákazníka | Preskočí frontu, bez ohľadu na to, ako stará je pohľadávka |
| Veľkosť účtu | Podľa mojej skúsenosti najväčší zákazníci často dostávajú najmiernejšie a najnekonzistentnejšie upomienky — nikto nechce byť ten, kto tlačí |
| Kto upomienku odosiela | Upomienka od obchodníka, ktorý účet vlastní, zaberie inak než automatická upomienka z pohľadávok |
| Osobná upomienka, ktorá odkazuje na skutočný vzťah | Zvykne dostať odpoveď častejšie než šablónová |
| Vytlačený počet dní po splatnosti | Väčšinou určuje len miesto faktúry v prehľade. Zriedka určuje, čo sa stane ďalej |
Ide o vzorce, ktoré som videl, nie o namerané benchmarky.
Čo by kontrola priority vymáhania musela reálne robiť
Potrebuje rovnaký typ mechanizmu ako kontrola priority platieb z minulého príspevku, len namierený na druhú stranu súvahy: súbor signálov na porovnanie s pravidlom a výstup, ktorý zoradí, koho upomenúť, namiesto toho, aby len vypísal, kto je po splatnosti. Tu sú signálmi počet dní po splatnosti, aktívna blokácia kreditu a to, koľko upomienok už bolo odoslaných bez odpovede — a pravidlom je, ktorý z týchto signálov, ak vôbec niektorý, má zákazníka posunúť pred staršiu pohľadávku.
Pripravil som si na to malý skript, ktorý presne toto robí nad vzorovými dátami: načíta zoznam otvorených pohľadávok, skontroluje pri každej blokáciu kreditu a počet upomienok a vypíše navrhované poradie vymáhania — nič naviazané na reálny zoznam zákazníkov, žiadny živý prístup k CRM či banke, len samotná logika zoraďovania. Je v tom istom osobnom, nekomerčnom repozitári ako predchádzajúce demá z tejto série.
Existuje na to malý prototyp
collections_priority_agent.py načíta CSV s otvorenými pohľadávkami a vypíše navrhované poradie vymáhania, ktoré nie je zoradené len podľa počtu dní po splatnosti — rovnaká logika ako vyššie, spustená nad vzorovými dátami.
Sledujte sériu
Príspevok #13 sa odpojí od jednotlivej položky v knihe a pýta sa na ťažšiu otázku: keď sú obe strany hotovosti — čo firma dlhuje, aj čo jej dlhujú — viditeľné v rovnakom čase, čo sa naozaj zmení na tom, ako finančný tím trávi svoj týždeň?