Skip to content
Firmspace
Back to blog

Robot Office in the CRM: How AI Employees Take Over Routine Work in a Small Business

Ask the owner of a small or mid-sized business what actually fills the week and the answer is rarely strategy. It is the same list of small jobs: an invoice that went out three weeks ago and still has not been paid, a stock item that quietly ran out, an inbox where a customer question is buried between supplier confirmations, and a task list where half the entries are older than the customer waiting on them. Hiring another person for that work is slow and expensive, and the jobs are too small to fill a full position anyway. That is the gap the Robot Office is built for: routine work that has to happen inside the CRM, reliably, without anyone remembering to start it.

The Robot Office is not one universal chatbot that is asked to do everything. It is a small office of narrow specialists. Each of them has a title, a written job description, a strictly limited set of tools and its own task list that the owner can see. The office sits in the Automation section of the CRM, on the Robot Office screen, and it has a head: Ayris, the built-in AI assistant. She is not an employee with a catalog role. She is the one who takes a request from the owner, decides who should do what and keeps the office in order, while the robots do the actual work in the sections where the data lives. Artificial intelligence in business processes looks like this: a small office, not one clever answer.

The owner does not fill in forms. The task is written in plain words, the way it would be said to a colleague: check which invoices are overdue and prepare the reminders, or tell me what has run out in the warehouse and what has to be reordered. Ayris works in boss mode. She splits the request into parts and delegates every part that fits a robot with the delegate_task tool, one self-contained instruction per robot, in the language of the owner. Small or cross-cutting things she does herself with her own tools. Then she stops: she does not wait for the robots to finish. They report on their own, on the same screen where the office lives.

Two rules keep the office honest. If no robot fits a task, Ayris says so plainly and offers to hire one from the catalog. And when a robot receives a task outside its duties, it does not improvise: it answers in one sentence which kind of robot should do that work instead. A warehouse robot will not quietly start issuing invoices, and an inbox robot will not decide on its own to pay a supplier. That is the practical difference between a general chat window and a team whose responsibilities are written down and whose tools cannot reach beyond them.

Robots are hired from a catalog of ready roles. For a German or Ukrainian firm the catalog holds thirteen of them: sales with Lena, orders with Jonas, accounting with Max, dunning with Nora, controlling with Clara, warehouse with Tom, purchasing with Paul, production with Ben, task management with Mia, inbox with Eva, personnel with Finn, marketing with Leo and customer service with Ida. Four more roles are offered only on the Uzbekistan market. Three further robots belong to the platform itself, watching errors, site optimization and blog drafts, and they are not part of the hire catalog. The first time the section is opened, the office hires a starter team of six roles on its own. The owner can also create a robot on the screen, with its own title and its own instructions, and the office keeps up to 24 robots per firm.

Nora, the dunning role, shows how narrow a role is meant to be. She looks for overdue and soon-due invoices, groups them by customer and prepares polite, factual payment reminders, a first reminder or a firmer second one. She does not threaten, she gives no legal advice, and she always shows the draft first: e-mails leave the building only when the task says to send them. For every reminder she adds a note or a follow-up task so that the customer history stays complete. Her skills are invoices, mail, the CRM, tasks, finance and read access to the data, and nothing else in the system is reachable for her.

Max takes care of accounting. He creates invoices, records expenses, marks an invoice as paid when the payment is confirmed, sends invoices when the task says to send them, and summarises open and paid amounts for a period. He does not rewrite history: an issued invoice is legally protected, so he asks before changing one. And no robot deletes anything, in any mode, because delete tools are not part of any skill that can be handed to a robot. A whole category of accidents is therefore closed by design rather than by careful prompting, which is the only kind of guarantee that survives a busy Monday.

Skills are the other half of the safety model. A skill is a group of the assistant's tools: crm, quotes, invoices, finance, stock, purchasing, production, tasks, mail, documents, blog, hr and data, the last one letting a robot browse any section of the CRM in read-only mode. Two further skills exist only for the platform's own service robots and are never offered for hire. A robot sees and can use only the tools of its skills, and only within the rights of the firm owner, because the tools still pass the same permission check as the assistant's. Giving the warehouse robot the invoice skill is a deliberate decision on the screen, not something a robot acquires by itself.

Every robot has an autonomy switch. In ask mode each change of data waits for the owner's confirmation: the robot prepares the action and stops. In auto mode the robot executes changes itself, which is what makes routines worth having, because nobody wants to confirm the same stock correction every morning. Two things do not change with the switch. A robot cannot delete anything in either mode, and edits of an already issued invoice always wait for confirmation. Auto mode therefore does not mean uncontrolled. It means the owner has decided in advance which robot may act alone, and every executed action stays attached to the task afterwards.

In practice, a task from a robot in ask mode often ends in the waiting status. The screen shows exactly which actions are proposed, and the owner can confirm all pending actions at once or only the ones he agrees with, and reject the rest. Confirmed actions are executed with the owner's own rights, which matters for approvals: the robot proposes, the person decides. Rejecting closes the task and nothing is executed. This is how the office earns trust step by step, on real documents, instead of asking the owner to believe in advance that an autonomous agent will behave.

Every task on the Robot Office screen carries a status: queued, running, waiting, done, failed or cancelled. Queued means it is in the robot's queue and has not started yet, and only a task in that state can be cancelled. Waiting means it needs the owner. Running means a robot is working on it right now. Failed always comes with a short reason, for example that the daily limit for AI work was used up or that the task was interrupted. The office keeps the recent history, the last few hundred tasks per firm; older finished entries are pruned so that the screen stays readable instead of turning into an archive.

One failure mode is worth naming honestly. If the server restarts while a robot is working, the work is interrupted. The office does not leave such a task looking busy forever: it marks it as failed with a note that it was interrupted by a restart and should be started again. The owner sees that on the screen and can repeat the task in one line. The trade is deliberate: a visible failure is better than a silent half-finished change in the books, and the whole design of the office prefers the visible option, even when it is the less flattering one.

Robots do not share a single queue, and that is deliberate. Each robot has its own: several tasks given to one robot run one after another, never at the same time, which keeps a specialist from doing two contradictory things to the same record. Tasks given to different robots run independently, so the inbox robot can sort mail while the warehouse robot checks stock levels and the dunning robot prepares reminders. The list_robots tool reports who is busy at the moment and who is waiting for the owner, and this is the same overview Ayris uses when she decides which parts of a request belong to which robot.

Regular work does not have to be requested every morning. Each robot can carry up to five routines: every day, on working days, weekly on a chosen weekday, or monthly on a chosen day of the month, each with a time of day. Times are kept in the firm's own time zone, which is why the German, Ukrainian and Uzbek markets each see their own morning. The server checks once a minute, and a routine runs at most once a day. If the server was unavailable at the appointed minute, the routine is executed up to six hours late instead of being skipped, so a restart does not silently erase the daily check.

One resource is shared by the whole office. Every robot task spends the firm's daily limit for AI work, the same counter that the assistant chat, the automatic AI step of automation rules, receipt scanning and spend analysis draw on. When that limit is used up, a queued task fails with a clear message that the daily limit is exhausted and resets tomorrow, and the office waits instead of pretending to work. What the robots never need is an open browser tab. They work in the background: the owner can close the CRM window, and the task continues and leaves its result on the Robot Office screen.

Each robot answers in the language of the task, so a German instruction comes back in German and a Ukrainian one in Ukrainian. Every answer ends with a short report instead of a wall of text: what was done, with document numbers, amounts and names, what still waits for confirmation and what is missing. No filler, and no invented figures, because the job description requires reading the real data with the tools before acting. If something cannot be established from the available data, the report says so, which is far more useful to an owner than a confident sentence that has to be checked line by line afterwards.

What the office does not do is decide for the owner. Someone has to choose which roles are hired, which autonomy each robot runs in and what a custom role is allowed to do. Robots act only within the rights of the firm owner, so anything the owner cannot reach in the CRM stays out of reach for them, and a robot will report a missing access rather than work around it. Some things are simply not covered and will be named as such instead of promised. And the free plan contains neither the AI assistant nor the Automation section where the Robot Office lives. The sensible start is small: open the section, let the starter team appear, hand over one real task in plain words, then set the first routine for the check that is always forgotten, and decide about further roles afterwards.

Let us automate your next process together.

Describe a recurring workflow to us. Together we will check whether and how it can be automated sensibly.