Thinking strategically about the most reliable systems in our organization today, email is probably at the top of the list. I feel like there is a semi-auto magic thing email is still missing for a lot of businesses. Many things can be managed within the latency constraints of email. All of the hardest & most complex things almost certainly can be. For instance, on-boarding a new employee could be totally driven by some back-end service that simply sends & interprets emails all day to ensure that all of the required activities are executed.
Now I am wondering if I can rewrite our B2B product interface to just be email. The more I think about this the more it starts to make a ridiculous amount of sense...
User=>Server (Email 1):
Subject: Get Workflow List
Server=>User (Email 2):
Subject: Workflow List [hash code]
Body: <all workflows by name and id>
User=>Server (Email 3):
Subject: Start Workflow #21
Server=>User (Email 4):
Subject: Workflow #12345532
Body: <First page of onboarding questions the user needs to fill out>
User=>Server (Email 4 - reply):
Subject: Re: Workflow #12345532
Body: <First page of questions with responses>
Server=>User (Email 4 - reply):
Subject: Workflow #12345532
Body: <Second page of questions, or error regarding first page responses>
...
Server=>User (Email 4 - reply):
Subject: Workflow #12345532 [COMPLETED]
Body: <Completion summary with whatever final artifacts attached>
I know our users would totally reject this proposal if it were made to be the only way to interact with our product, but if it were an additional way to interact, they might grow accustomed over time.
Think about the technical advantages of the above. If you keep it plaintext, anyone with a computer made within the last 3 decades could access your business system unconditionally. Developer productivity is likely excellent. I can't imagine you would be able to get very distracted with plain text emails.
The email server is very reliable, in the same way that an Apache web server or MySQL database is reliable.
It's the script pulling data over the network, parsing it, developers updating it, etc, where the instability comes in. And don't forget the edge cases where somebody uses weird encoding, a large email with attachments, a client that formats it in weird ways, etc.
As it happens we have an onboarding platform which certainly emits quite a few emails.
We use online forms for data capture, but funnily enough things sometimes pan out like you say.
It seems that if you send someone an email saying "You forgot to upload your drivers licence, please click _HERE_ to upload it", a good 50% of the time they will simply reply to your email, attaching the document. And why not really. We used to try again to direct them to the online system, but eventually started handling these things outside the usual flow.
Why not chat interface? This kind of communication you just described feels unnatural for email, but something people would do over chat/messenger in a heartbeat.
Now I am wondering if I can rewrite our B2B product interface to just be email. The more I think about this the more it starts to make a ridiculous amount of sense...
I know our users would totally reject this proposal if it were made to be the only way to interact with our product, but if it were an additional way to interact, they might grow accustomed over time.Think about the technical advantages of the above. If you keep it plaintext, anyone with a computer made within the last 3 decades could access your business system unconditionally. Developer productivity is likely excellent. I can't imagine you would be able to get very distracted with plain text emails.