It’s always worth taking the time to analyze the landing page of new services. Recently, I discovered recurrr.com, launched by Cristian Tăbăcitu, the owner of the very good Laravel Backpack admin panel.
After sending to Cristian a few personal comments and hopefully constructive critics about the homepage, I took the time to analyze this idea, smelling good future opportunities.
Pros & cons of recurrr.com idea
First, I think that this service is simply nice and the chosen angle is interesting. The value proposition that appears immediately on the homepage is that a good automated email can replace many meetings in companies. Which is true. In French we talk about the “reunionite” syndrom, like it’s a medical issue. Meetings are slow and costly, and it’s certainly obvious that many of them can be replaced by a good structured email collecting the feedback of everyone.
Surprisingly and as stated in the homepage of recurrr.com, recurring scheduled emails are not so easy to do natively in email clients. I was doubtful about this statement initially, but Cristian is right.
As almost all companies are using Microsoft Outlook, a quick check confirmed it: there is no native solution. However, some Outlook plugins propose this feature.
The branding of such a solution as a “meeting-killer” is audacious. I don’t know if it could convince widely (do companies really want to kill meetings?), but this angle is smart to try.
My first conclusion is that this simple and “obvious” service is nice as it “patches” a feature flaw of many email clients.
Then, an idea came from nowhere. A kind of marketing twist in the form of one headline: “Transform your processes to emails”. I found that funny to have this idea in mind (Yes, we don’t control our thinking). In companies, we fought for years to shift from emails to applications to get structured data, we may live the opposite movement now with AI.
At this stage it was only a kind of intuition following my reading of recurrr’s homepage.
The next days I tried to formalize this idea in my head.
Brainstorming about email in companies
This is why it’s always good to read deeply the landing page of startups: it’s a permanent factory of new ideas.
But let’s start by the basics.
The status of corporate emails
Email (web) clients are probably the most used software in companies. At the start it was nice and practical. Then, progressively, there was a trend in Executive Committees to reduce the number of emails for multiple reasons, especially since the rise of smartphones (starting with the old but excellent Blackberry device):
- They powered burnouts as employees always read them
- They are sometimes unproductive as they lead to misunderstandings between employees, especially in multi-cultural environments
- They are “anti-social”.
This quickly became a HR issue to manage.
Also, at one moment – when the emails were stored in the company’s datacenters – the question of the cost of all these old useless emails has been raised in multiple companies.
Nowadays, the ecological cost of corporate emails is also commonly raised by HSE departments.
Although emails have often been under attack in companies, they are still used as the main communication system. Even live chat systems didn’t succeed to replace them. In Microsoft environments, Microsoft Teams is widely used, but it is used jointly with Outlook. So, despite they are attacked regularly, emails are here to stay, despite the various attempts to implement partly an alternative.
The emergence of LLMs
Emails are free text. Like the text area of ChatGPT.
It lead me think that emails might be the most relevant UI to integrate AI efficiently in companies. As emails remain the main way to communicate inside and outside a company, why AIs are not directly plugged to the corporate email system?
Of course, Microsoft did it… But very very partly. More, companies are tight to the Microsoft AI ecosystem, and therefore to the slow pace of Microsoft when it comes to improve its existing products.
I don’t get the full picture yet, but I smell a potential revolution here.
Should an AI be a normal employee, having its own job title, mailbox and files?
Personally, I LOVE this idea. I found this is the right way to implement AI in companies without disturbing users with new interfaces, complex systems and URLs to bookmark.
And it’s quite logical. Each seat in a company provides a specific service. The fact that this seat is occupied by a human or by a machine is not so important. Are human employees contacted by an URL? Huh, no!
Need to do some charts from an Excel file? Just send an email to chartman.robot@company.com, saying what you want and your file attached.
A more complex example and “natural” example:
From: CEO@company.com
To: pierre.human@company.com; paul.human@company.com; jack.robot@company.com; joe.robot@company.com
Hi guys,
Pierre, Paul, please send me your numbers for the 2024 report.
Jack, consolidate these numbers to produce the annual report. Once done, get it approved by Joe and send the final version to all of us.
Thanks to all
CEOImplement such a process should be feasible with the existing technologies, and it has many advantages:
- No specific UIs to deploy. Emails remain the main UI ;
- Easy to introduce a new artificial-employee to others, no learning curve ;
- Management of all AI agents within a company is easy as they are managed like all others employees (except that they are not paid, ah ah).
Could this be implemented as a startup?
This idea is not new as this is exactly the concept of AI agents. What is new (at least to me) is that AI agents should probably be normal employees answering their emails and chats (in Microsoft Teams for companies). They should use the corporate tools like all other employees.
It’s not clear to me yet how this could be implemented as a indie hacking startup.
Looping back to recurrr.com
Stuck, I looked again at this screenshot to refresh my ideas.
The first think I noted is that this form is perfectly useless in an AI context. If I want to send an email – even delayed and recurring – I would prefer to use my email client.
A technical pivot would be to put online a robot@recurrr.com, so the user would be able to do that:
To: robot@recurrr.com
Subject: What's your plan for today?
Robot, send this email on behalf of me to everyone@digitallyhappy.com every weekday at 8am.
Hey,
(message body)
Thanks!At the marketing level, it’s more complex tough. It’s unlikely that medium / big companies would accept to let users send emails to an external service due to potential confidentiality/legal breaches.
But still, it would be a good technical pivot I think, probably not too difficult to implement, and easier to sell, to use, and to extend it.
The birth of EmailAgents.com?
With recurrr.com, we have our first email agent. A potential development is to implement MANY agents, all available through normal emails.
- recur@emailagents.com to schedule an email
- summarizetotables@emailagents.com to get all replies to an email, summarize them, and send back a nice formatted table with all answers
- etc.
I honestly like the infinite extensibility of this idea. Such a startup can quickly have hundreds of agents, sometimes working together to get better results.
It also offers two immediate ways of monetization:
- Subscription or
- Ads added in the signature of each email sent by the agents
What I like the most in this idea is that it’s a direct workaround of the existing limitations of *any* email clients. You just need to see what is missing from one client to grab market shares without developing a full email client or a plugin, by finding the right AI prompt. Astonishing.
Finally, this idea seems good to me because it’s B-to-C and B-to-B, offering various ways to sell it.
Targeting big corps
Targeting big companies is complex and I don’t have a clear view about it. Those companies have big legal requirements and it would be difficult to brand this offer as a SaaS, because employees would sent internal/confidential emails to this service.
If I list the mandatory things from the point of view of a big company, I would say:
| Use the Microsoft AI as “we already have a contract with them, and it’s our trusted main partner”. | Preferable |
| Email addresses like @company.com or @robot.company.com or name.robot@company.com or similar | Preferable |
| AI emails stored where our emails are stored. Idem for files received. | Preferable |
| GDPR / Compliance stuff | Mandatory |
By taking into account this table, the following architecture comes into my mind:
So, the company would create the agents mailboxes. Messages are read by EmailAgents SaaS through the IMAP protocol and directly transmitted to Azure AI with the right prompt. The email response is then sent through the SMTP (TLS) of the customer. No data is stored on the EmailAgents server as everything is done in memory.
A better alternative – instead of IMAP and SMTP connection – is to use the REST API of Office 365.
Even if it breaks the “legal chain” between the customer and his Office 365 instance, it might be enough to get the trust of the customer as strictly nothing is stored, and if it is, it will be in Azure AI.
To be continued?
I like so much this idea that I noted it in my “ideas” Obsidian note.
I don’t think that companies will deploy 150 UI for all their AI needs, a common medium has to be found, and I don’t see what would be better than company’s email accounts.
I’ll probably continue to think about this idea a few days to see if it fades away in my mind.
Days passing are often the grave of wonderful ideas 😉
Leave a Reply