Business automation consulting
Most companies do not have an automation problem. They have a process problem that automation then makes louder. We start with how the work actually moves through your company, put the repeatable parts into a defined process, and hand that process to an artificial employee who works inside your systems and answers to a named person on your team.
Consulting first, software second. The software runs on your server, not ours.
The method
Not chatbots bolted onto a website, not a pile of integrations nobody maintains. A process is described, an owner is named, and then a worker who never forgets it is put in charge of it.
We sit with the people doing the work and write down what actually happens, including the parts that live in someone's head, in a chat thread, or in a spreadsheet that only one person understands. The output is a written process map: inputs, decisions, hand-offs, and the point where a human has to stay in the loop.
Each process gets a role, described the way you would describe a job: what it receives, what it decides on its own, what it escalates, who it reports to, and what it is not allowed to touch. That description is the specification we build against.
The employee runs as a real agent on your infrastructure. It reads messages and answers them, works with your documents and knowledge, uses the tools you give it, and can act on a schedule rather than only when spoken to.
Every employee has a human owner and a boundary. Exceptions go to a person. You can suspend an employee at any moment and the work can go back to the way it was, because the process is written down independently of the software.
What this is for
If several of these are true, there is usually a process here worth setting up properly.
Requests arrive in Telegram, Viber, email and phone calls. Nothing has a status. Whether something got done depends on who happened to read the message.
A single employee knows how the ordering, the reporting or the client handover really works. Their holiday is a company risk.
Staff spend hours a week repeating the same explanations to clients or to each other, and the answers are inconsistent because they come from memory.
Invoices, orders and specifications get retyped from one system into another, and the errors show up a month later in the numbers.
Follow-ups, reminders and routine checks depend on someone remembering. What is not remembered is simply lost.
The only known way to handle more volume is another salary, and the new person needs three months of somebody else's time before they are useful.
This tends to fit companies with real operational routine and staff who are not technical: service businesses, retail and wholesale, clinics, logistics, small production. The rule of thumb: the more a process is shared between people, repeats itself, and should happen without being asked for, the more there is to gain.
The employees
Not a chat widget and not a script. It is an isolated worker running a real agent session, with its own instructions, its own access, its own knowledge, and its own conversation history with the people it works with.
A tool belongs to the person who opens it, and everything it knows leaves with them. An employee belongs to the process. Its memory is the company's, it survives restarts, weekends and resignations, and it is still there on Monday. So ask it this way: if the person who runs this process goes on holiday, should the knowledge of the process stay behind? If yes, it should be an employee.
An employee can be given standing duties, not only questions to answer. It checks what needs checking, prepares what needs preparing, and the result is waiting before anyone opens a laptop. The work that people postpone is exactly the work that gets handed over first.
These are process shapes, not a catalogue. What your company needs is decided in the audit.
The interface
Your employee is reached in Telegram, from a phone, by people who were never trained on it. That is a decision, not a compromise.
The people whose work this actually is, the storekeeper, the cashier, the person on reception, are not going to learn a new system. They will use the one already open on their phone. So the interface is a chat, and the first day needs no training.
What sits behind the chat is not a cut-down assistant. It is a full agent session with real tools and real access. You are not buying a weaker product because it lives in a messenger. You are putting a capable one behind the simplest door your team already knows how to open.
The engine is the same. We built a cab people can actually sit in.
The platform
The employee is not a tenant in somebody else's system. It runs on a server that belongs to you, and the conversations and the model traffic stay there.
Your company gets its own isolated node. The employee runs there as a container, with a local gateway, a local key vault and a local model proxy. Your day-to-day working data is not processed on shared infrastructure.
Chat content and model traffic leave the node only to reach the model provider you are paying. Our control side sees configuration, usage counters and encrypted knowledge snapshots, and nothing else is sent to it.
Each employee runs on your own model provider token, held in the vault on your box. You see and control the cost, and you can revoke it without asking us.
Support access is agreed in writing, limited by role, and written to an audit log you can read. Suspending the node ends that access, and that switch is yours.
Your server
Our control side
Your model provider
Chat content is not routed through our control side. The connection runs one way: the node connects out, and we do not reach in unless you have granted it.
How we work
The first stage is deliberately separable. You end it with a written process map that is useful to you whether or not you continue with us.
We map how the work moves today, with the people who do it. You get a written process map, the list of places where time is actually going, and an honest split into what is worth automating, what should be fixed organisationally first, and what should be left alone.
Deliverable: written process map and a fixed-scope proposal
For the processes worth doing, we write the role specification: responsibilities, boundaries, escalation rules, which systems it may touch, and what a successful week looks like. This is signed off before anything is built.
Deliverable: role specification, agreed in writing
We provision your node, install the employee, connect it to your channel and your knowledge, and run it alongside the current way of working until it is clearly doing the job. The people it works with are trained on it as a colleague, not as a tool.
Deliverable: a working employee your team is already using
An employee needs maintenance the way a process does: rules change, edge cases appear, the business moves. We keep it correct, review what it has been doing, and add the next process when the first one is genuinely stable.
Ongoing, on an agreed support arrangement
Before you write to us
Automating a process nobody agrees on multiplies the disagreement. Sometimes the correct answer is two meetings and a written rule, and we will say so.
If something happens four times a month and takes ten minutes, it should stay a person's job. We would rather lose that piece of scope than sell it.
Anything where being wrong is expensive and hard to reverse stays with a human. We build the preparation around it, not the decision itself.
Contact
Write in your own words: what your company does, and which piece of work is being done again and again by hand. That is enough for a first conversation. You will get a straight answer about whether there is something here worth doing.