દર મહિને દસ તારીખની આસપાસ, એકાઉન્ટિંગ ટીમ સમાન વિનંતી મોકલે છે. તેમને દરેક ક્લાયન્ટ પાસેથી પાંચ ફાઇલોની જરૂર હોય છે: એક બેંક સ્ટેટમેન્ટ, એક રસીદ આર્કાઇવ (receipt archive), એક પેરોલ રિપોર્ટ, એક વેચાણનો સારાંશ (sales summary), અને એક ઇન્વેન્ટરી દસ્તાવેજ. ટેમ્પલેટ મૈત્રીપૂર્ણ, સચોટ અને પરીક્ષિત છે. તે ક્લાયન્ટનું નામ લઈને અભિવાદન કરે છે, ફાઇલોની યાદી આપે છે અને સ્પષ્ટ સમયમર્યાદા આપે છે. પ્રથમ વખત મોકલવામાં આવે ત્યારે તે કામ કરે છે. ક્લાયન્ટ એક વ્યવસ્થિત યાદી જુએ છે અને જવાબ આપે છે.

મુશ્કેલી બીજા ઇમેઇલથી શરૂ થાય છે.

કલ્પના કરો કે એક ક્લાયન્ટ ચાર ફાઇલો મોકલે છે. પાંચમું બેંક સ્ટેટમેન્ટ ક્યારેય આવતું નથી. રસીદ આર્કાઇવ દેખાય છે, પરંતુ તે ખોટા મહિનાનું છે, તેથી ટીમ તેને નકારી દે છે. પેરોલ રિપોર્ટ ખરેખર ત્રણ દિવસ પહેલા Slack દ્વારા આવ્યો હતો, અને કોઈએ તેને પહેલેથી જ ફાઇલ કરી દીધો છે. ઇન્વેન્ટરી દસ્તાવેજ આ ક્લાયન્ટને બિલકુલ લાગુ પડતો નથી, જે વિગત તમને પ્રથમ સંદેશ મોકલ્યા પછી જ જાણવા મળી હતી. જો તમે મૂળ ટેમ્પલેટ ફરીથી મોકલો છો, તો તમે ફરીથી પાંચ ફાઇલોની માંગણી કરો છો. તેમાંથી ચાર વિનંતીઓ હવે નિરર્થક છે. એક સક્રિયપણે ગેરમાર્ગે દોરનારી છે. શબ્દો યોગ્ય છે. ઇમેઇલમાં ફક્ત કોઈ યાદશક્તિ નથી.

ઇમેઇલ ટેમ્પલેટ નામ, તારીખ અને સૂચનાઓને સારી રીતે સંભાળે છે. નાની, એક વખતની વિનંતી માટે, તે સામાન્ય રીતે પૂરતું છે. એક વ્યક્તિ મેઇલ મોકલે છે, ક્લાયન્ટ જવાબ આપે છે, અને તે જ વ્યક્તિ કાર્ય પૂર્ણ કરે છે. ઇતિહાસ એક મગજ અને એક ઇનબોક્સમાં રહેલો હોય છે.

સમસ્યાઓ ત્યારે શરૂ થાય છે જ્યારે આગામી સંદેશ એ ઘટનાઓ પર આધારિત હોય જે પ્રથમ ઇમેઇલ પછી બની હોય. ટેમ્પલેટ હજુ પણ મૂળ યાદી બતાવે છે. તેને ખબર નથી કે ગઈકાલે બેંક સ્ટેટમેન્ટ આવ્યું હતું. તેને ખબર નથી કે પેરોલ રિપોર્ટ નકારવામાં આવ્યો હતો. તે ડેટા એક ઇનબોક્સમાં, કદાચ ઘણા ઇનબોક્સમાં રહેલો હોય છે, અને રિમાઇન્ડર જનરેટ કરતી એપ્લિકેશન પાસે તેને વાંચવાનો કોઈ રસ્તો નથી.

જ્યારે 'Open' હોવું પૂરતું નથી

જો તમે આખી વિનંતીને "open" જેવી સિંગલ સ્ટેટસ તરીકે ટ્રેક કરો છો, તો તમે મહત્વની વિગતો ગુમાવો છો. વસ્તુઓ સ્વતંત્ર રીતે આગળ વધે છે. દરેક વસ્તુને તેની પોતાની સ્થિતિ (state) ની જરૂર છે જેથી આગામી સંદેશાવ્યવહાર સચોટ હોઈ શકે:

  • Bank statement: ખૂટતું છે. ક્લાયન્ટે તે મોકલ્યું નથી.
  • Receipt archive: અપલોડ કરવામાં આવ્યું છે પરંતુ રિવ્યુ કરવામાં આવ્યું નથી. તે આંતરિક તપાસની રાહ જોતા ફોલ્ડરમાં પડ્યું છે.
  • Payroll report: નકારવામાં આવ્યું છે. ક્લાયન્ટે કંઈક મોકલ્યું હતું, પરંતુ તે ખોટા ફોર્મેટમાં અથવા ખોટા પે-પીરિયડનું હતું.
  • Sales report: અન્ય માધ્યમ દ્વારા પ્રાપ્ત થયું છે. તે Slack, ફોન કોલ અથવા પોસ્ટલ કોપી દ્વારા આવ્યું હતું, અને તમારી ટીમે તેને પહેલેથી જ લોગ કરી દીધું છે.
  • Inventory document: લાગુ પડતું નથી. આ ક્લાયન્ટે તે આપવાની જરૂર નથી, અને સિસ્ટમે પૂછવાનું બંધ કરી દેવું જોઈએ.

આ વિભાજન વિના, તમારું રિમાઇન્ડર અંધ છે. તે ખૂટતી ફાઇલ અને નકારવામાં આવેલી ફાઇલ સાથે એકસરખું વર્તન કરે છે. તે પહેલેથી જ હાથમાં હોય તેવી ફાઇલ સાથે એવું વર્તન કરે છે જાણે તે ક્યારેય આવી જ ન હોય. તે ક્લાયન્ટનો સમય બગાડે છે અને વિશ્વાસ ઘટાડે છે. બે કે ત્રણ બિનજરૂરી રિમાઇન્ડર્સ પછી, ક્લાયન્ટ્સ તેને ઉપરછલ્લી રીતે જુએ છે. તેઓ માની લે છે કે તમારી સિસ્ટમ બગડી ગઈ છે.

ફક્ત જરૂર હોય તે જ બનાવો

સૌ પ્રથમ વિશાળ રૂલ્સ એન્જિન બનાવશો નહીં. તમારે પહેલા દિવસથી વીસ કન્ડિશનલ બ્રાન્ચ્સ સાથે વર્કફ્લો ઓટોમેશનની જરૂર નથી. ફક્ત એક પ્રશ્નનો જવાબ આપવા માટે પૂરતો ડેટા ટ્રેક કરીને શરૂઆત કરો: ક્લાયન્ટ તરફથી હજુ કયા પગલાં લેવાની જરૂર છે?

દરેક વિનંતી કરેલી વસ્તુ માટે ટકાઉ પરિણામની જરૂર છે. તેનો અર્થ એ છે કે એક એવો રેકોર્ડ જે ઇમેઇલ થ્રેડની બહાર રહે, એવી જગ્યાએ જેને એપ્લિકેશન આગામી સંદેશ ડ્રાફ્ટ કરતી વખતે વાંચી શકે. રેકોર્ડ જટિલ હોવું જરૂરી નથી. તે આઇટમનું નામ, તેની વર્તમાન સ્થિતિ, ટાઇમસ્ટેમ્પ અને ટૂંકી નોંધ ધરાવતા સ્ટ્રક્ચર્ડ ટેબલ જેટલું સરળ હોઈ શકે છે. મહત્વનું એ છે કે ડેટા ઇનબોક્સની બહાર ટકી રહે.

આ ઇમેઇલની ભૂમિકા બદલી નાખે છે. ટેમ્પલેટ હજુ પણ ટોન અને સ્ટ્રક્ચરને નિયંત્રિત કરે છે. અભિવાદન હૂંફાળું રહે છે, સૂચનાઓ સ્પષ્ટ રહે છે. પરંતુ દસ્તાવેજોની યાદી વિનંતીના ડેટામાંથી આવવી જોઈએ. રિમાઇન્ડર એક ક્વેરી (query) બની જાય છે. તમે યાદીને ફિલ્ટર કરો છો જેથી ફક્ત તે વસ્તુઓ જ દેખાય જેના માટે ક્લાયન્ટના પગલાંની જરૂર છે. તમે આંતરિક રિવ્યુની રાહ જોતી વસ્તુઓને બાકાત રાખો છો. તમે પહેલેથી જ સ્વીકૃત વસ્તુઓને બાકાત રાખો છો.

જો અપલોડ નકારવામાં આવ્યું હોય, તો રિમાઇન્ડરમાં તે જણાવવું જોઈએ અને શા માટે તે સમજાવવું જોઈએ. તે દસ્તાવેજને શાંતિથી સામાન્ય યાદીમાં ફરીથી મૂકવો જોઈએ નહીં, જાણે કે ક્લાયન્ટ તેને મોકલવાનું ભૂલી ગયો હોય. ક્લાયન્ટ જાણે છે કે તેઓએ કંઈક અપલોડ કર્યું છે; તેમ ન હોવાનો ડોળ કરવો તમને અસ્તવ્યસ્ત દેખાડે છે.

The Handoff Test

તમારે આ વધારાના ડેટા મોડેલની જરૂર છે કે નહીં તે જાણવાની એક સરળ રીત છે. પૂછો:

શું બીજો કોઈ ટીમ મેમ્બર આખો ઇમેઇલ થ્રેડ વાંચ્યા વગર આ વિનંતી સંભાળી શકે છે?

એક સિંગલ ફાઇલ માટે, જવાબ મહત્વનો નથી. પરંતુ ઘણી જટિલ પ્રક્રિયાઓ ધરાવતી વારંવાર આવતી માસિક વિનંતીઓ માટે, તે ખૂબ જ મહત્વપૂર્ણ છે. જો મુખ્ય સંપર્ક વ્યક્તિ રજા પર હોય, તો શું તેનો સાથીદાર સેકન્ડોમાં જોઈ શકે છે કે શું ખૂટે છે? શું મેનેજર દસ ઇમેઇલ્સ અને ત્રણ શેર કરેલા ફોલ્ડર્સ ખોલ્યા વગર કહી શકે છે કે ક્લાયન્ટનું બધું કામ પૂરું થઈ ગયું છે? જો રિજેક્શન નોંધવાનો એકમાત્ર સ્થાન થ્રેડમાં ચોથો મેસેજ હોય, જે સિગ્નેચર અને ફોરવર્ડ્સ નીચે દબાયેલો હોય, તો તમારી સિસ્ટમ મનુષ્યોને એ કામ કરવા માટે મજબૂર કરી રહી છે જે ડેટાબેઝે કરવું જોઈએ.

ટેમ્પલેટ્સ સંદેશમાં સુધારો કરે છે. ટ્રેક્ડ વિનંતી ઇતિહાસ જાળવી રાખે છે. એક એ સંભાળે છે કે તમે કેવી રીતે વાત કરો છો. બીજું એ સંભાળે છે કે તમે શું જાણો છો.

ક્વેરીઝ, સ્ક્રિપ્ટ્સ નહીં

એકવાર તમારી પાસે આઇટમ-લેવલ સ્ટેટ્સ આવી જાય, પછી ઇમેઇલ બનાવવાની પ્રક્રિયા સ્ક્રિપ્ટિંગમાંથી ક્વેરીઇંગમાં બદલાઈ જાય છે. અગાઉ, તમે એક ફકરો લખતા અને આશા રાખતા કે તે હજુ પણ સચોટ છે. હવે તમે તમારા ડેટાને પૂછો છો: આમાંથી કઈ વસ્તુઓ માટે હજુ પણ ક્લાયન્ટની કાર્યવાહીની જરૂર છે? તમે તે ફિલ્ટર કરેલી યાદીના આધારે રિમાઇન્ડર તૈયાર કરો છો. જો કોઈ કાર્યવાહીની જરૂર ન હોય, તો તમે રિમાઇન્ડર મોકલતા નથી. જો બે વસ્તુઓ માટે કાર્યવાહીની જરૂર હોય અને એક ચોક્કસ કારણસર રિજેક્ટ કરવામાં આવી હોય, તો ઇમેઇલ તે તથ્યોના આધારે આપમેળે તૈયાર થઈ જાય છે.

આ