botfromzero.
English
Tell us

Reports · Alerts · Approvals

Team operations bots: reports, alerts and approvals in Telegram, Lark or Slack

Numbers from a store admin, a sheet or a system arrive on a schedule or when a threshold is crossed, in a chat the team already opens. An approval writes back and leaves a record. Custom development from US$500. We’ll assess the need for free, then give a clear quote.

A bot for the people who run the work

Some bots face customers. This one faces the team. The problem is the same shape in a shop, a service desk or a small operation: someone logs into several admin screens every day to see whether stock is low, an order looks wrong, a report is ready, or an approval is waiting. The bot reads the sources you approve and posts the result into Telegram, Lark, Slack or a similar chat the team already opens.

It is not a customer-service assistant. If the job is answering buyers, start from AI customer service and orders. The two can share a data source later, but they are different conversations and different permissions.

Uses that show up first

The first version should be one report or one alert, not every dashboard you have. These are the shapes we scope. They are examples, not a claim that a particular shop platform is already connected.

  • A sales or orders summary at a set time, with the numbers you actually use, sent to the group that acts on them.
  • A low-stock or threshold alert when a figure crosses a line you set, instead of a person refreshing a page.
  • An odd-order alert: duplicates, a total outside the usual range, or a status that has sat too long.
  • An approval button for a named person. The tap is written back to the sheet or the system, with who did it and when.
  • A duty or incident alert when a process you already monitor stops or a queue grows past a limit.

Where the numbers come from

The bot can read a store admin, a spreadsheet, or an ERP or CRM, when that system exposes an API or a documented export and you can grant access. Which fields, how often, and what happens if the source is down or returns an error, are part of the acceptance checklist. A logo on a settings screen is not an integration.

We do not ask for a password to a personal account when an API or a service account would do. Access is limited to the reports the bot needs. If the only available path is a shared login with no API, that limitation is written down before anyone promises a reliable alert.

Who can see it, and what is recorded

A daily sales figure and a button that approves a refund are not the same audience. The scope names who is in the chat, who may press the button, and what the button is allowed to change. Every action the bot takes, and every approval a person taps, is written to a log the team can open: what changed, who did it, and when.

Customer-facing replies are out of this page's job. The bot should not become a way to message buyers in bulk. Internal alerts stay in the internal chat. If a customer must be told something, that is a separate, agreed message, not a side effect of an approval.

Keeping the bot running after launch is monthly hosting: the process stays up, failures are handled, the source API is watched for breaking changes, and small edits to a threshold or a label fit inside an allowance. Hosting and maintenance is a monthly fee, priced by complexity. If hosting stops, you get the code, the data and the deployment notes.

Price, and starting smaller

Custom development starts at US$500. One report, several sources, write-back or more than one approval all change the quote. Price depends on how many features you need, which platforms and external systems it connects to, whether it takes payment, and whether it includes a Mini App. The quote follows the checklist. About one to three weeks is a planning range once access to the source system is actually available.

There is no public demo of an operator's daily report. The inquiry notification on the home page is the nearest internal relative: a saved event notifies a person. It uses sample data in the illustration and it is not a client case. We will not invent a screenshot of a report we do not run.

Work we do not take

We do not take gambling, adult content, fake engagement or account farming, spam, or scraping that bypasses captchas or logins.

Questions about an internal bot

Can it read our internal system?
If the system has an API or a documented export and you can grant access, we assess the fields, the schedule and the failures. Without that, a reliable alert is not promised.
Where does the data live?
In the systems you already use, plus the bot's own log of what it read and what people approved. Hosting does not move ownership of the business data. If hosting ends, you get an export and the deployment notes.
Can we start with a single report?
Yes. One scheduled report into one chat is a complete first version. Alerts and approval buttons can be a later change once that report is accepted.

Start from the screen you open every day.

One report you already read is more useful than a full specification.

Discuss an ops bot