ಪ್ರತಿ ತಿಂಗಳು ಹತ್ತನೇ ತಾರೀಖಿನ ಸುಮಾರಿಗೆ, ಅಕೌಂಟಿಂಗ್ ತಂಡವು ಒಂದೇ ರೀತಿಯ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸುತ್ತದೆ. ಅವರಿಗೆ ಪ್ರತಿ ಗ್ರಾಹಕನಿಂದ ಐದು ಫೈಲ್ಗಳು ಬೇಕಾಗುತ್ತವೆ: ಬ್ಯಾಂಕ್ ಸ್ಟೇಟ್ಮೆಂಟ್ (bank statement), ರಸೀದಿ ಆರ್ಕೈವ್ (receipt archive), ವೇತನ ವರದಿ (payroll report), ಮಾರಾಟದ ಸಾರಾಂಶ (sales summary), ಮತ್ತು ದಾಸ್ತಾನು ದಾಖಲೆ (inventory document). ಈ ಟೆಂಪ್ಲೇಟ್ ಸ್ನೇಹಪರವಾಗಿದೆ, ನಿಖರವಾಗಿದೆ ಮತ್ತು ಪರೀಕ್ಷಿಸಲ್ಪಟ್ಟಿದೆ. ಇದು ಗ್ರಾಹಕನನ್ನು ಹೆಸರಿನಿಂದ ಸ್ವಾಗತಿಸುತ್ತದೆ, ಫೈಲ್ಗಳ ಪಟ್ಟಿಯನ್ನು ನೀಡುತ್ತದೆ ಮತ್ತು ಸ್ಪಷ್ಟವಾದ ಗಡುವನ್ನು (deadline) ಸೂಚಿಸುತ್ತದೆ. ಮೊದಲ ಬಾರಿ ಕಳುಹಿಸಿದಾಗ, ಇದು ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಗ್ರಾಹಕನು ಅಚ್ಚುಕಟ್ಟಾದ ಪಟ್ಟಿಯನ್ನು ನೋಡಿ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತಾನೆ.
ಸಮಸ್ಯೆ ಎರಡನೇ ಇಮೇಲ್ನೊಂದಿಗೆ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ.
ಒಬ್ಬ ಗ್ರಾಹಕನು ನಾಲ್ಕು ಫೈಲ್ಗಳನ್ನು ಕಳುಹಿಸುತ್ತಾನೆ ಎಂದು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ. ಐದನೇ ಬ್ಯಾಂಕ್ ಸ್ಟೇಟ್ಮೆಂಟ್ ಎಂದಿಗೂ ಬರುವುದಿಲ್ಲ. ರಸೀದಿ ಆರ್ಕೈವ್ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ, ಆದರೆ ಅದು ತಪ್ಪು ತಿಂಗಳದ್ದಾಗಿರುತ್ತದೆ, ಆದ್ದರಿಂದ ತಂಡವು ಅದನ್ನು ತಿರಸ್ಕರಿಸುತ್ತದೆ. ವೇತನ ವರದಿಯು ಈಗಾಗಲೇ ಮೂರು ದಿನಗಳ ಹಿಂದೆ Slack ಮೂಲಕ ಬಂದಿರುತ್ತದೆ ಮತ್ತು ಯಾರೋ ಅದನ್ನು ಈಗಾಗಲೇ ಫೈಲ್ ಮಾಡಿದ್ದಾರೆ. ದಾಸ್ತಾನು ದಾಖಲೆಯು ಈ ಗ್ರಾಹಕನಿಗೆ ಅನ್ವಯಿಸುವುದಿಲ್ಲ, ಈ ವಿವರವನ್ನು ನೀವು ಮೊದಲ ಸಂದೇಶ ಕಳುಹಿಸಿದ ನಂತರವೇ ತಿಳಿದುಕೊಳ್ಳುತ್ತೀರಿ. ನೀವು ಮೂಲ ಟೆಂಪ್ಲೇಟ್ ಅನ್ನು ಮತ್ತೆ ಕಳುಹಿಸಿದರೆ, ನೀವು ಮತ್ತೆ ಐದು ಫೈಲ್ಗಳನ್ನು ಕೇಳುತ್ತೀರಿ. ಆ ಐದು ವಿನಂತಿಗಳಲ್ಲಿ ನಾಲ್ಕು ಈಗ ವ್ಯರ್ಥವಾಗಿವೆ. ಒಂದು ವಿನಂತಿಯು ಸಕ್ರಿಯವಾಗಿ ದಾರಿ ತಪ್ಪಿಸುವಂತಿದೆ. ಪದಬಳಕೆ ಸರಿಯಾಗಿದೆ, ಆದರೆ ಇಮೇಲ್ನಲ್ಲಿ ಯಾವುದೇ ನೆನಪಿನ ಶಕ್ತಿ (memory) ಇಲ್ಲ.
ಇಮೇಲ್ ಟೆಂಪ್ಲೇಟ್ ಹೆಸರುಗಳು, ದಿನಾಂಕಗಳು ಮತ್ತು ಸೂಚನೆಗಳನ್ನು ಚೆನ್ನಾಗಿ ನಿರ್ವಹಿಸುತ್ತದೆ. ಒಂದು ಸಣ್ಣ, ಏಕೈಕ ವಿನಂತಿಗೆ, ಅದು ಸಾಮಾನ್ಯವಾಗಿ ಸಾಕಾಗುತ್ತದೆ. ಒಬ್ಬ ವ್ಯಕ್ತಿಯು ಮೇಲ್ ಕಳುಹಿಸುತ್ತಾನೆ, ಗ್ರಾಹಕನು ಉತ್ತರಿಸುತ್ತಾನೆ ಮತ್ತು ಅದೇ ವ್ಯಕ್ತಿಯು ಕಾರ್ಯವನ್ನು ಪೂರ್ಣಗೊಳಿಸುತ್ತಾನೆ. ಇತಿಹಾಸವು ಒಂದು ಮೆದುಳು ಮತ್ತು ಒಂದು ಇನ್ಬಾಕ್ಸ್ನಲ್ಲಿ ಇರುತ್ತದೆ.
ಮೊದಲ ಇಮೇಲ್ ನಂತರ ನಡೆದ ಘಟನೆಗಳ ಮೇಲೆ ಮುಂದಿನ ಸಂದೇಶವು ಅವಲಂಬಿತವಾಗಿದ್ದಾಗ ಸಮಸ್ಯೆಗಳು ಪ್ರಾರಂಭವಾಗುತ್ತವೆ. ಟೆಂಪ್ಲೇಟ್ ಇನ್ನೂ ಮೂಲ ಪಟ್ಟಿಯನ್ನೇ ತೋರಿಸುತ್ತದೆ. ನಿನ್ನೆ ಬ್ಯಾಂಕ್ ಸ್ಟೇಟ್ಮೆಂಟ್ ಬಂದಿದೆ ಎಂಬುದು ಅದಕ್ಕೆ ತಿಳಿದಿಲ್ಲ. ವೇತನ ವರದಿಯನ್ನು ತಿರಸ್ಕರಿಸಲಾಗಿದೆ ಎಂಬುದು ಅದಕ್ಕೆ ತಿಳಿದಿಲ್ಲ. ಆ ಡೇಟಾ ಇನ್ಬಾಕ್ಸ್ನಲ್ಲಿ, ಬಹುಶಃ ಹಲವಾರು ಇನ್ಬಾಕ್ಸ್ಗಳಲ್ಲಿ ಇರುತ್ತದೆ ಮತ್ತು ರಿಮೈಂಡರ್ ಅನ್ನು ಸೃಷ್ಟಿಸುವ ಅಪ್ಲಿಕೇಶನ್ಗೆ ಅದನ್ನು ಓದಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ.
"Open" ಎಂಬ ಸ್ಥಿತಿ ಸಾಕಾಗದಿದ್ದಾಗ
ನೀವು ಇಡೀ ವಿನಂತಿಯನ್ನು "open" ಎಂಬ ಒಂದೇ ಸ್ಥಿತಿಯಂತೆ ಟ್ರ್ಯಾಕ್ ಮಾಡಿದರೆ, ಮುಖ್ಯವಾದ ವಿವರಗಳನ್ನು ನೀವು ಕಳೆದುಕೊಳ್ಳುತ್ತೀರಿ. ಐಟಂಗಳು ಸ್ವತಂತ್ರವಾಗಿ ಚಲಿಸುತ್ತವೆ. ಮುಂದಿನ ಸಂವಹನವು ನಿಖರವಾಗಿರಲು ಪ್ರತಿಯೊಂದಕ್ಕೂ ತನ್ನದೇ ಆದ ಸ್ಥಿತಿ (state) ಅಗತ್ಯವಿದೆ:
- Bank statement: ಕಾಣೆಯಾಗಿದೆ. ಗ್ರಾಹಕನು ಅದನ್ನು ಕಳುಹಿಸಿಲ್ಲ.
- Receipt archive: ಅಪ್ಲೋಡ್ ಮಾಡಲಾಗಿದೆ ಆದರೆ ಪರಿಶೀಲಿಸಿಲ್ಲ. ಇದು ಆಂತರಿಕ ಪರಿಶೀಲನೆಗಾಗಿ ಫೋಲ್ಡರ್ನಲ್ಲಿ ಕಾಯುತ್ತಿದೆ.
- Payroll report: ತಿರಸ್ಕರಿಸಲಾಗಿದೆ. ಗ್ರಾಹಕನು ಏನನ್ನೋ ಕಳುಹಿಸಿದ್ದಾರೆ, ಆದರೆ ಅದು ತಪ್ಪು ಫಾರ್ಮ್ಯಾಟ್ ಅಥವಾ ತಪ್ಪು ವೇತನ ಅವಧಿಯದ್ದಾಗಿದೆ.
- Sales report: ಇನ್ನೊಂದು ಚಾನಲ್ ಮೂಲಕ ಸ್ವೀಕರಿಸಲಾಗಿದೆ. ಇದು Slack, ಫೋನ್ ಕರೆ ಅಥವಾ ಅಂಚೆ ಪ್ರತಿಯ ಮೂಲಕ ಬಂದಿದೆ ಮತ್ತು ನಿಮ್ಮ ತಂಡವು ಈಗಾಗಲೇ ಅದನ್ನು ದಾಖಲಿಸಿದೆ.
- Inventory document: ಅನ್ವಯಿಸುವುದಿಲ್ಲ. ಈ ಗ್ರಾಹಕನು ಇದನ್ನು ನೀಡುವ ಅಗತ್ಯವಿಲ್ಲ ಮತ್ತು ಸಿಸ್ಟಮ್ ಕೇಳುವುದನ್ನು ನಿಲ್ಲಿಸಬೇಕು.
ಈ ವಿಂಗಡಣೆಯಿಲ್ಲದೆ, ನಿಮ್ಮ ರಿಮೈಂಡರ್ ಕುರುಡಾಗಿರುತ್ತದೆ. ಇದು ಕಾಣೆಯಾದ ಫೈಲ್ ಮತ್ತು ತಿರಸ್ಕರಿಸಲ್ಪಟ್ಟ ಫೈಲ್ ಎರಡನ್ನೂ ಒಂದೇ ರೀತಿ ಪರಿಗಣಿಸುತ್ತದೆ. ಈಗಾಗಲೇ ಕೈಯಲ್ಲಿರುವ ಫೈಲ್ ಅನ್ನು ಎಂದಿಗೂ ಬರದಂತೆ ಪರಿಗಣಿಸುತ್ತದೆ. ಇದು ಗ್ರಾಹಕನ ಸಮಯವನ್ನು ವ್ಯರ್ಥ ಮಾಡುತ್ತದೆ ಮತ್ತು ನಂಬಿಕೆಯನ್ನು ಕುಗ್ಗಿಸುತ್ತದೆ. ಎರಡು ಅಥವಾ ಮೂರು ಅಪ್ರಸ್ತುತ ರಿಮೈಂಡರ್ಗಳ ನಂತರ, ಗ್ರಾಹಕರು ಅದನ್ನು ಕೇವಲ ಮೇಲ್ನೋಟಕ್ಕೆ ನೋಡುತ್ತಾರೆ. ನಿಮ್ಮ ಸಿಸ್ಟಮ್ ಕೆಟ್ಟಿದೆ ಎಂದು ಅವರು ಭಾವಿಸುತ್ತಾರೆ.
ನಿಮಗೆ ಬೇಕಾದುದನ್ನು ಮಾತ್ರ ನಿರ್ಮಿಸಿ
ಮೊದಲು ಬೃಹತ್ ನಿಯಮಗಳ ಇಂಜಿನ್ (rules engine) ಅನ್ನು ನಿರ್ಮಿಸಬೇಡಿ. ಮೊದಲ ದಿನವೇ ಇಪ್ಪತ್ತು ಕಂಡೀಷನಲ್ ಬ್ರಾಂಚ್ಗಳಿರುವ ವರ್ಕ್ಫ್ಲೋ ಆಟೊಮೇಷನ್ ನಿಮಗೆ ಅಗತ್ಯವಿಲ್ಲ. ಕೇವಲ ಒಂದು ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸಲು ಬೇಕಾದಷ್ಟು ಡೇಟಾವನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುವ ಮೂಲಕ ಪ್ರಾರಂಭಿಸಿ: ಗ್ರಾಹಕನಿಂದ ಇನ್ನು ಯಾವ ಕ್ರಮದ ಅಗತ್ಯವಿದೆ?
ಪ್ರತಿ ವಿನಂತಿಸಿದ ಐಟಂಗೆ ದೀರ್ಘಕಾಲದ ಫಲಿತಾಂಶ (durable result) ಬೇಕು. ಅಂದರೆ ಇಮೇಲ್ ಥ್ರೆಡ್ನ ಹೊರಗೆ, ಅಪ್ಲಿಕೇಶನ್ ಮುಂದಿನ ಸಂದೇಶವನ್ನು ಸಿದ್ಧಪಡಿಸುವಾಗ ಓದಬಲ್ಲ ಸ್ಥಳದಲ್ಲಿ ಒಂದು ದಾಖಲೆ ಇರಬೇಕು. ಆ ದಾಖಲೆಯು ಸಂಕೀರ್ಣವಾಗಿರಬೇಕಿಲ್ಲ. ಅದು ಐಟಂ ಹೆಸರು, ಅದರ ಪ್ರಸ್ತುತ ಸ್ಥಿತಿ, ಟೈಮ್ಸ್ಟ್ಯಾಂಪ್ ಮತ್ತು ಒಂದು ಸಣ್ಣ ಟಿಪ್ಪಣಿಯನ್ನು ಹೊಂದಿರುವ ಒಂದು ರಚನಾತ್ಮಕ ಟೇಬಲ್ ಆಗಿರಬಹುದು. ಡೇಟಾ ಇನ್ಬಾಕ್ಸ್ನಿಂದ ಮೀರಿದರೂ ಉಳಿಯುವುದು ಮುಖ್ಯವಾಗಿದೆ.
ಇದು ಇಮೇಲ್ನ ಪಾತ್ರವನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ. ಟೆಂಪ್ಲೇಟ್ ಇನ್ನೂ ಧ್ವನಿ ಮತ್ತು ರಚನೆಯನ್ನು ನಿಯಂತ್ರಿಸುತ್ತದೆ. ಸ್ವಾಗತವು ಆತ್ಮೀಯವಾಗಿರುತ್ತದೆ, ಸೂಚನೆಗಳು ಸ್ಪಷ್ಟವಾಗಿರುತ್ತವೆ. ಆದರೆ ದಾಖಲೆಗಳ ಪಟ್ಟಿಯು ವಿನಂತಿ ಡೇಟಾದಿಂದ ಬರಬೇಕು. ರಿಮೈಂಡರ್ ಒಂದು ಕ್ವೆರಿ (query) ಆಗುತ್ತದೆ. ಗ್ರಾಹಕನ ಕ್ರಮದ ಅಗತ್ಯವಿರುವ ಐಟಂಗಳನ್ನು ಮಾತ್ರ ತೋರಿಸಲು ನೀವು ಪಟ್ಟಿಯನ್ನು ಫಿಲ್ಟರ್ ಮಾಡುತ್ತೀರಿ. ಆಂತರಿಕ ಪರಿಶೀಲನೆಗಾಗಿ ಕಾಯುತ್ತಿರುವ ಐಟಂಗಳನ್ನು ನೀವು ಹೊರಗಿಡುತ್ತೀರಿ. ಈಗಾಗಲೇ ಸ್ವೀಕರಿಸಿದ ಐಟಂಗಳನ್ನು ನೀವು ಹೊರಗಿಡುತ್ತೀರಿ.
ಅಪ್ಲೋಡ್ ತಿರಸ್ಕರಿಸಲ್ಪಟ್ಟಿದ್ದರೆ, ರಿಮೈಂಡರ್ ಅದನ್ನು ಹೇಳಬೇಕು ಮತ್ತು ಏಕೆ ಎಂದು ವಿವರಿಸಬೇಕು. ಗ್ರಾಹಕನು ಕಳುಹಿಸಲು ಮರೆತಿದ್ದಾನೆ ಎಂಬಂತೆ ದಾಖಲೆಯನ್ನು ಸಾಮಾನ್ಯ ಪಟ್ಟಿಯಲ್ಲಿ ಮೌನವಾಗಿ ಮತ್ತೆ ಸೇರಿಸಬಾರದು. ಗ್ರಾಹಕನು ಏನನ್ನೋ ಅಪ್ಲೋಡ್ ಮಾಡಿದ್ದಾರೆ ಎಂಬುದು ಅವರಿಗೆ ತಿಳಿದಿದೆ; ಇಲ್ಲದಂತೆ ನಟಿಸುವುದು ನೀವು ಅಸ್ತವ್ಯಸ್ತವಾಗಿದ್ದೀರಿ ಎಂದು ತೋರಿಸುತ್ತದೆ.
ಹ್ಯಾಂಡ್ಆಫ್ ಟೆಸ್ಟ್ (The Handoff Test)
ನಿಮಗೆ ಈ ಹೆಚ್ಚುವರಿ ಡೇಟಾ ಮಾಡೆಲ್ ಅಗತ್ಯವಿದೆಯೇ ಎಂದು ತಿಳಿಯಲು ಒಂದು ಸರಳ ಮಾರ್ಗವಿದೆ. ಕೇಳಿ:
ಇಡೀ ಇಮೇಲ್ ಥ್ರೆಡ್ ಅನ್ನು ಓದದೆ ಇನ್ನೊಬ್ಬ ತಂಡದ ಸದಸ್ಯರು ಈ ವಿನಂತಿಯನ್ನು ಮುಂದುವರಿಸಲು ಸಾಧ್ಯವೇ?
ಒಂದೇ ಒಂದು ಫೈಲ್ಗೆ ಇದು ಮುಖ್ಯವಾಗದಿರಬಹುದು. ಆದರೆ ಅನೇಕ ಅಂಶಗಳನ್ನು ಒಳಗೊಂಡಿರುವ ಪ್ರತಿ ತಿಂಗಳ ಮರುಕಳಿಸುವ ವಿನಂತಿಗಳಿಗೆ ಇದು ಬಹಳ ಮುಖ್ಯವಾಗುತ್ತದೆ. ಮುಖ್ಯ ಸಂಪರ್ಕ ವ್ಯಕ್ತಿಯು ರಜೆಯಲ್ಲಿದ್ದರೆ, ಯಾವುದೋ ಒಂದು ಮಾಹಿತಿ ಕಾಣೆಯಾಗಿದೆ ಎಂದು ಸಹೋದ್ಯೋಗಿಯು ಕ್ಷಣಾರ್ಧದಲ್ಲಿ ಗುರುತಿಸಬಲ್ಲರೇ? ಹತ್ತು ಇಮೇಲ್ಗಳು ಮತ್ತು ಮೂರು ಹಂಚಿಕೆಯ ಫೋಲ್ಡರ್ಗಳನ್ನು ತೆರೆಯುವ ಅಗತ್ಯವಿಲ್ಲದೆ, ಗ್ರಾಹಕನು ಎಲ್ಲಾ ಕೆಲಸಗಳನ್ನು ಪೂರ್ಣಗೊಳಿಸಿದ್ದಾನೆಯೇ ಎಂದು ವ್ಯವಸ್ಥಾಪಕನಿಗೆ ತಿಳಿಯಲು ಸಾಧ್ಯವೇ? ಒಂದು ತಿರಸ್ಕಾರದ ಮಾಹಿತಿಯು ಸಹಿಗಳು ಮತ್ತು ಫಾರ್ವರ್ಡ್ಗಳ ಅಡಿಯಲ್ಲಿ ಹೂತುಹೋಗಿರುವ ಸಂದೇಶದ ಸರಪಳಿಯ (thread) ನಾಲ್ಕನೇ ಸಂದೇಶದಲ್ಲಿ ಮಾತ್ರ ದಾಖಲಿಸಲ್ಪಟ್ಟಿದ್ದರೆ, ನಿಮ್ಮ ವ್ಯವಸ್ಥೆಯು ಡೇಟಾಬೇಸ್ ಮಾಡಬೇಕಾದ ಕೆಲಸವನ್ನು ಮನುಷ್ಯರಿಂದ ಮಾಡಿಸುತ್ತಿದೆ ಎಂದರ್ಥ.
ಟೆಂಪ್ಲೇಟ್ಗಳು ಸಂದೇಶವನ್ನು ಉತ್ತಮಗೊಳಿಸುತ್ತವೆ. ಟ್ರ್ಯಾಕ್ ಮಾಡಲಾದ ವಿನಂತಿಯು ಇತಿಹಾಸವನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ. ಒಂದು ನೀವು ಹೇಗೆ ಮಾತನಾಡುತ್ತೀರಿ ಎಂಬುದನ್ನು ನಿರ್ವಹಿಸಿದರೆ, ಇನ್ನೊಂದು ನಿಮಗೆ ಏನು ತಿಳಿದಿದೆ ಎಂಬುದನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ.
ಸ್ಕ್ರಿಪ್ಟ್ಗಳಲ್ಲ, ಕ್ವೆರಿಗಳು
ಒಮ್ಮೆ ನಿಮ್ಮ ಬಳಿ ಐಟಂ-ಮಟ್ಟದ ಸ್ಥಿತಿಗಳು (item-level states) ಇದ್ದರೆ, ಇಮೇಲ್ ತಯಾರಿಸುವ ಪ್ರಕ್ರಿಯೆಯು ಸ್ಕ್ರಿಪ್ಟಿಂಗ್ನಿಂದ ಕ್ವೆರಿ ಮಾಡುವಿಕೆಗೆ ಬದಲಾಗುತ್ತದೆ. ಮೊದಲು, ನೀವು ಒಂದು ಪ್ಯಾರಾಗ್ರಾಫ್ ಬರೆಯುತ್ತಿದ್ದಿರಿ ಮತ್ತು ಅದು ಇನ್ನೂ ನಿಖರವಾಗಿದೆ ಎಂದು ಭಾವಿಸುತ್ತಿದ್ದಿರಿ. ಈಗ ನೀವು ನಿಮ್ಮ ಡೇಟಾಳನ್ನು ಕೇಳುತ್ತೀರಿ: ಈ ಐಟಂಗಳಲ್ಲಿ ಯಾವುವು ಇನ್ನೂ ಗ್ರಾಹಕನ ಕ್ರಮವನ್ನು ಬಯಸುತ್ತವೆ? ನೀವು ಆ ಫಿಲ್ಟರ್ ಮಾಡಲಾದ ಪಟ್ಟಿಯ ಆಧಾರದ ಮೇಲೆ ನೆನಪೋಲೆಯನ್ನು (reminder) ಸಿದ್ಧಪಡಿಸುತ್ತೀರಿ. ಯಾವುದೇ ಕ್ರಮದ ಅಗತ್ಯವಿಲ್ಲದಿದ್ದರೆ, ನೀವು ಯಾವುದೇ ನೆನಪೋಲೆಯನ್ನು ಕಳುಹಿಸುವುದಿಲ್ಲ. ಒಂದು ವೇಳೆ ಎರಡು ಐಟಂಗಳಿಗೆ ಕ್ರಮದ ಅಗತ್ಯವಿದ್ದು, ಒಂದು ನಿರ್ದಿಷ್ಟ ಕಾರಣಕ್ಕಾಗಿ ತಿರಸ್ಕರಿಸಲ್ಪಟ್ಟಿದ್ದರೆ, ಇಮೇಲ್ ಆ ಸತ್ಯಗಳ ಸುತ್ತ ತಾನಾಗಿಯೇ ನಿರ್ಮಾಣವಾಗುತ್ತದೆ.
ಇದು