ప్రతి నెలా పదవ తేదీ ప్రాంతంలో, అకౌంటింగ్ టీమ్ ఒకే రకమైన అభ్యర్థనను పంపిస్తుంది. వారికి ప్రతి క్లయింట్ నుండి ఐదు ఫైళ్లు అవసరం: బ్యాంక్ స్టేట్‌మెంట్, రసీదుల ఆర్కైవ్ (receipt archive), పేరోల్ రిపోర్ట్, సేల్స్ సమ్మరీ మరియు ఇన్వెంటరీ డాక్యుమెంట్. ఈ టెంప్లేట్ స్నేహపూర్వకంగా, ఖచ్చితంగా మరియు పరీక్షించబడినదిగా ఉంటుంది. ఇది క్లయింట్‌ను పేరుతో పలకరిస్తుంది, ఫైళ్లను జాబితా చేస్తుంది మరియు స్పష్టమైన గడువును తెలియజేస్తుంది. మొదటిసారి పంపినప్పుడు, ఇది బాగానే పనిచేస్తుంది. క్లయింట్ ఒక చక్కని జాబితాను చూసి స్పందిస్తారు.

అసలు సమస్య రెండో ఈమెయిల్ నుండి మొదలవుతుంది.

ఒక క్లయింట్ నాలుగు ఫైళ్లను పంపారని ఊహించుకోండి. ఐదవ బ్యాంక్ స్టేట్‌మెంట్ మాత్రం అందదు. రసీదుల ఆర్కైవ్ వస్తుంది కానీ, అది తప్పు నెలకు సంబంధించినది, కాబట్టి టీమ్ దానిని తిరస్కరిస్తుంది. పేరోల్ రిపోర్ట్ మూడు రోజుల క్రితమే Slack ద్వారా వచ్చిందని, ఎవరో ఇప్పటికే దానిని ఫైల్ చేశారని తెలుస్తుంది. ఇన్వెంటరీ డాక్యుమెంట్ ఆ క్లయింట్‌కు అసలు అవసరం లేదు, ఈ విషయం మొదటి మెసేజ్ పంపిన తర్వాతే మీకు తెలుస్తుంది. మీరు మళ్ళీ అదే పాత టెంప్లేట్‌ను పంపితే, మళ్ళీ ఐదు ఫైళ్ల కోసం అడుగుతారు. అందులో నాలుగు అభ్యర్థనలు ఇప్పుడు వృథా. ఒకటి తప్పుదారి పట్టించేలా ఉంది. అందులోని పదజాలం బాగుండవచ్చు, కానీ ఆ ఈమెయిల్‌కు ఎటువంటి 'మెమరీ' లేదు.

ఒక ఈమెయిల్ టెంప్లేట్ పేర్లు, తేదీలు మరియు సూచనలను బాగా హ్యాండిల్ చేస్తుంది. ఒక చిన్న, ఒకేసారి చేసే అభ్యర్థన కోసం అది సరిపోతుంది. ఒక వ్యక్తి మెయిల్ పంపుతారు, క్లయింట్ రిప్లై ఇస్తారు, మరియు అదే వ్యక్తి ఆ పనిని పూర్తి చేస్తారు. చరిత్ర అంతా ఒకే వ్యక్తి మెదడులో మరియు ఒకే ఇన్‌బాక్స్‌లో ఉంటుంది.

మొదటి ఈమెయిల్ తర్వాత జరిగిన సంఘటనల ఆధారంగా తదుపరి మెసేజ్ ఉండాల్సి వచ్చినప్పుడు సమస్యలు మొదలవుతాయి. టెంప్లేట్ ఇంకా పాత జాబితానే చూపిస్తుంది. నిన్న బ్యాంక్ స్టేట్‌మెంట్ వచ్చిందని దానికి తెలియదు. పేరోల్ రిపోర్ట్ తిరస్కరించబడిందని దానికి తెలియదు. ఆ డేటా ఒక ఇన్‌బాక్స్‌లో లేదా బహుశా అనేక ఇన్‌బాక్స్‌లలో ఉంటుంది, మరియు రిమైండర్‌ను పంపే అప్లికేషన్‌కు దానిని చదివే మార్గం ఉండదు.

"Open" అని పిలిస్తే సరిపోదు

మీరు మొత్తం అభ్యర్థనను కేవలం "open" వంటి ఒకే ఒక స్టేటస్‌గా ట్రాక్ చేస్తే, ముఖ్యమైన వివరాలను కోల్పోతారు. అంశాలు స్వతంత్రంగా మారుతుంటాయి. తదుపరి కమ్యూనికేషన్ ఖచ్చితంగా ఉండాలంటే, ప్రతి అంశానికి దాని స్వంత స్టేటస్ ఉండాలి:

  • Bank statement: మిస్ అయింది. క్లయింట్ ఇంకా పంపలేదు.
  • Receipt archive: అప్‌లోడ్ చేయబడింది కానీ ఇంకా రివ్యూ చేయలేదు. ఇది అంతర్గత తనిఖీ కోసం ఒక ఫోల్డర్‌లో వేచి ఉంది.
  • Payroll report: తిరస్కరించబడింది. క్లయింట్ ఏదో పంపారు, కానీ అది తప్పు ఫార్మాట్‌లో లేదా తప్పు పే పీరియడ్‌కు సంబంధించినది.
  • Sales report: మరొక ఛానెల్ ద్వారా అందింది. ఇది Slack, ఫోన్ కాల్ లేదా పోస్టల్ కాపీ ద్వారా వచ్చి ఉండవచ్చు మరియు మీ టీమ్ ఇప్పటికే దానిని లాగ్ చేసింది.
  • Inventory document: వర్తించదు (Not applicable). ఈ క్లయింట్ దీనిని అందించాల్సిన అవసరం లేదు, మరియు సిస్టమ్ ఇకపై దీని గురించి అడగడం ఆపివేయాలి.

ఈ విభజన లేకపోతే, మీ రిమైండర్ గుడ్డిగా ఉంటుంది. అది మిస్ అయిన ఫైల్‌ను మరియు తిరస్కరించబడిన ఫైల్‌ను ఒకేలా చూస్తుంది. ఇప్పటికే చేతిలో ఉన్న ఫైల్‌ను కూడా అది ఎప్పుడూ రాలేదని భావిస్తుంది. ఇది క్లయింట్ సమయాన్ని వృథా చేయడమే కాకుండా, నమ్మకాన్ని కూడా తగ్గిస్తుంది. రెండు మూడు అనవసరమైన రిమైండర్‌ల తర్వాత, క్లయింట్లు వాటిని పట్టించుకోవడం మానేస్తారు. మీ సిస్టమ్ పాడైపోయిందని వారు భావిస్తారు.

మీకు అవసరమైన దానిని మాత్రమే నిర్మించండి

మొదటగా ఒక భారీ రూల్స్ ఇంజిన్‌ను నిర్మించకండి. మొదటి రోజే ఇరవై కండిషనల్ బ్రాంచ్‌లతో కూడిన వర్క్‌ఫ్లో ఆటోమేషన్ మీకు అవసరం లేదు. కేవలం ఒకే ఒక ప్రశ్నకు సమాధానం ఇవ్వడానికి సరిపడా డేటాను ట్రాక్ చేయడం ద్వారా ప్రారంభించండి: క్లయింట్ నుండి ఇంకా ఏ చర్యలు అవసరం?

ప్రతి అభ్యర్థించబడిన అంశానికి ఒక శాశ్వత ఫలితం (durable result) ఉండాలి. అంటే, అప్లికేషన్ తదుపరి మెసేజ్‌ను డ్రాఫ్ట్ చేసేటప్పుడు చదవగలిగే విధంగా, ఈమెయిల్ త్రెడ్ వెలుపల ఒక చోట రికార్డు ఉండాలి. ఆ రికార్డు సంక్లిష్టంగా ఉండాల్సిన అవసరం లేదు. అది ఐటమ్ పేరు, దాని ప్రస్తుత స్టేటస్, టైమ్‌స్టాంప్ మరియు ఒక చిన్న నోట్‌ను కలిగి ఉన్న ఒక స్ట్రక్చర్డ్ టేబుల్ లాగా కూడా ఉండవచ్చు. ముఖ్యమైన విషయం ఏమిటంటే, ఆ డేటా ఇన్‌బాక్స్ దాటి కూడా నిలిచి ఉండాలి.

ఇది ఈమెయిల్ పాత్రను మారుస్తుంది. టెంప్లేట్ ఇంకా టోన్ మరియు నిర్మాణాన్ని నియంత్రిస్తుంది. గ్రీటింగ్ వెచ్చగా ఉంటుంది, సూచనలు స్పష్టంగా ఉంటాయి. కానీ డాక్యుమెంట్ జాబితా అభ్యర్థన డేటా (request data) నుండి రావాలి. రిమైండర్ ఒక క్వెరీ (query) లాగా మారుతుంది. క్లయింట్ చర్యలు అవసరమయ్యే అంశాలను మాత్రమే చూపించడానికి మీరు జాబితాను ఫిల్టర్ చేస్తారు. అంతర్గత రివ్యూ కోసం వేచి ఉన్న అంశాలను మీరు మినహాయిస్తారు. ఇప్పటికే అంగీకరించిన అంశాలను కూడా మినహాయిస్తారు.

ఒక అప్‌లోడ్ తిరస్కరించబడితే, రిమైండర్ దాని గురించి చెప్పాలి మరియు ఎందుకు అనేది వివరించాలి. క్లయింట్ పంపడం మర్చిపోయారని భావించి, ఆ డాక్యుమెంట్‌ను మళ్ళీ సాధారణ జాబితాలో నిశ్శబ్దంగా ఉంచకూడదు. క్లయింట్ ఏదో అప్‌లోడ్ చేశారని వారికి తెలుసు; లేదన్నట్లు నటించడం వల్ల మీరు అస్తవ్యస్తంగా ఉన్నట్లు కనిపిస్తారు.

హ్యాండోఫ్ టెస్ట్ (The Handoff Test)

మీకు ఈ అదనపు డేటా మోడల్ అవసరమో లేదో తెలుసుకోవడానికి ఒక సులభమైన మార్గం ఉంది. ఇలా అడగండి:

మొత్తం ఈమెయిల్ త్రెడ్‌ను చదవకుండానే మరొక టీమ్ మెంబర్ ఈ అభ్యర్థనను ముందుకు తీసుకెళ్లగలరా?

ఒకే ఒక ఫైల్ విషయంలో అయితే, సమాధానం ముఖ్యం కాదు. అనేక అంశాలతో కూడిన ప్రతి నెలా పునరావృతమయ్యే అభ్యర్థనల విషయంలో, ఇది చాలా ముఖ్యం. ఒకవేళ ప్రధాన సంప్రదింపు వ్యక్తి సెలవులో ఉంటే, ఏది మిస్ అయిందో ఒక సహోద్యోగి సెకన్లలో చూడగలడా? పది ఈమెయిల్‌లు మరియు మూడు షేర్డ్ ఫోల్డర్‌లను తెరవకుండానే, క్లయింట్ పనులన్నీ పూర్తి చేశారో లేదో ఒక మేనేజర్ చెప్పగలడా? ఒక తిరస్కరణ అనేది కేవలం ఒక త్రెడ్‌లోని నాలుగవ మెసేజ్‌లో, సంతకాలు మరియు ఫార్వార్డ్‌ల కింద కలిసిపోయి ఉంటే, అప్పుడు మీ సిస్టమ్ డేటాబేస్ చేయాల్సిన పనిని మనుషుల ద్వారా చేయిస్తోంది అని అర్థం.

టెంప్లేట్లు సందేశాన్ని మెరుగుపరుస్తాయి. ట్రాక్ చేయబడిన అభ్యర్థన (tracked request) చరిత్రను భద్రపరుస్తుంది. ఒకటి మీరు ఎలా మాట్లాడుతున్నారో చూసుకుంటే, మరొకటి మీకు తెలిసిన విషయాలను చూసుకుంటుంది.

స్క్రిప్ట్‌లు కాదు, క్వెరీలే

మీరు ఐటెమ్-లెవల్ స్టేట్స్‌ను (item-level states) కలిగి ఉన్నప్పుడు, ఈమెయిల్ రూపొందించడం అనేది స్క్రిప్టింగ్ నుండి క్వెరీయింగ్ వైపు మారుతుంది. ఇంతకుముందు, మీరు ఒక పేరా రాసి అది ఇంకా ఖచ్చితంగా ఉందేమో అని ఆశించేవారు. ఇప్పుడు మీరు మీ డేటాను అడుగుతారు: ఈ అంశాలలో ఏవి ఇంకా క్లయింట్ చర్య (client action) కోసం వేచి ఉన్నాయి? మీరు ఆ ఫిల్టర్ చేయబడిన జాబితా ఆధారంగా రిమైండర్‌ను రూపొందిస్తారు. ఒకవేళ ఏదీ అవసరం లేకపోతే, మీరు అసలు రిమైండర్ పంపరు. ఒకవేళ రెండు అంశాలపై చర్య అవసరమై, అందులో ఒకటి ఒక నిర్దిష్ట కారణం వల్ల తిరస్కరించబడితే, ఆ వాస్తవాల ఆధారంగా ఈమెయిల్ ఆటోమేటిక్‌గా తయారవుతుంది.

ఇది