I use amoCRM every day as a small business owner. We do not have a large sales department or a complex hierarchy, but we still rely on pipelines, deals, and tasks. Very quickly I noticed that a significant part of my time was spent not on decision-making, but on repetitive manual checks inside the CRM.
Every morning looked almost the same. Open pipelines. Check if there are any unassigned leads. See whether active deals have tasks. Look for overdue tasks where nothing has happened for a while. None of this is difficult, but it is routine. And when you skip it or postpone it, the problem usually surfaces later, when the lead is already cold or the opportunity is lost.
At some point, it became obvious that automating these checks was easier than forcing myself to repeat them manually every day.
That is how LeadsAlarm started.
The project is already live: https://leadsalarm.ru/
Using it is intentionally simple. You just message the Telegram bot at https://t.me/LeadsAlarmBot go through the official amoCRM OAuth flow, select pipelines, and that is it. The service runs in the background and sends notifications when something in your deals requires attention.
Why Alerts Instead of Reports
CRM reports and analytics are useful, but they solve a different problem. They are great for weekly or monthly reviews.
In daily operations, what matters more is not an overview but a timely signal. I did not want to constantly open the CRM UI, filter deals, and manually check timestamps. I wanted the system to tell me when something went wrong.
That is why alerts turned out to be the most convenient format.
Why Telegram
The answer is simple. Telegram is always open.
A separate dashboard is just another place you need to remember to visit. A message in a messenger appears exactly where attention already is and does not turn monitoring into a separate task.
The bot does not spam. It sends short, contextual messages only when it makes sense. If everything is fine, it stays silent.
What the Signals Look Like
When an actual issue appears, the bot sends a clear and focused signal. No long tables, no excessive details.
For example, if a deal has an overdue task, the message contains the pipeline name and deal ID. This is enough to decide whether you need to react immediately or can look at it later.
For unassigned leads, the logic is slightly different. The bot does not notify on every new lead. It waits for a configured time window and sends an aggregated alert only if the problem persists. This significantly reduces noise.
Data Safety by Design
From the beginning, I decided that the service should not work with deal contents.
LeadsAlarm uses only metadata: deal and task statuses, pipeline stages, timestamps, and responsible users. Contacts, notes, comments, and message texts are neither fetched nor stored.
This was a conscious design choice. It minimizes data leakage risks simply by excluding sensitive data from storage. It also keeps the architecture simpler and more predictable. On top of that, full deal content would generate too much data for a stable and economically reasonable analysis, especially within a low-cost subscription model.
Why No Working Hours or Calendars
Initially, I considered building checks around schedules: business hours, weekends, holidays, vacations.
Very quickly it became clear that this approach adds complexity while still producing false positives. Every team works differently, and there is no universal calendar that fits everyone.
Instead, I switched to a simpler activity-based model. The system does not care about days of the week or hours. It only looks at facts: whether there were any events related to a deal within a given time window.
If there was activity, it is considered working time.
This approach has limitations. If a manager has zero activity during the day, a signal might not trigger. In practice, such cases are rare, and if there is no activity at all, the problem is usually obvious even without automated alerts.
Tech Stack and Architecture Choices
I also used this project as an opportunity to work with PHP more intentionally. Before that, my experience with PHP was mostly limited to WordPress projects. Here, I wanted to take a popular and modern framework and go through the full cycle from idea to production.
I chose Laravel 12, which at the time was the latest and most up-to-date release. It turned out to be a good fit for this type of service. Clear structure, built-in queues, solid database tooling. Everything needed for a small SaaS is already there.
Development felt a bit slower compared to my usual Node.js stack, but that was expected and not a real issue. Predictability and ease of maintenance were more important. Over time, I expect this choice to pay off.
On the frontend side, I deliberately avoided complexity. The service has only a few public pages whose purpose is to explain what the tool does and how it works. I implemented them as simple static HTML pages without introducing a separate frontend stack. This allowed me to focus entirely on core logic and notifications.
A Production Issue I Did Not Expect
One interesting problem appeared after the system was already running.
At some point, I noticed that background workers occasionally stopped processing jobs, while the jobs themselves were still marked as successfully completed. From the outside, everything looked fine, but in reality some checks were silently skipped.
It took some time to understand what was happening, review logs, and adjust how workers were supervised and restarted. This was not a Laravel-specific issue. Similar problems can happen in Node.js systems as well. It was a good reminder that background processing in production needs proper monitoring and defensive design, regardless of the stack.
AI and Future Direction
At the moment, LeadsAlarm checks only basic situations that I previously monitored manually. The service has a free tier and a paid tier, which I continue to extend gradually.
In parallel, I am already experimenting with AI-based analysis to reduce noise and highlight deals that deserve attention first. This is not about surveillance or employee control. The goal is to build a prioritization assistant, not a judge.
I do not expect AI to be 100 percent accurate. Its role is to help focus attention, not to make decisions.
I also plan to port the service to Kommo CRM, which has a very similar API to amoCRM. This should make the transition mostly architectural rather than conceptual.
Conclusion
For me, this project started as a way to remove routine from daily CRM usage and focus on things that actually matter. If you use amoCRM and find yourself repeatedly checking the same things manually, this alert-based approach might be useful for you as well.
Project: https://leadsalarm.ru/
Telegram bot: https://t.me/LeadsAlarmBot
Top comments (0)