The director approves payments
from WhatsApp, not from the system
A manufacturing company in Türkiye. Around twenty payment requests a day, each one needing the director's approval. We removed the narrowest part of that chain — having to open the corporate system at all.
Approvals came down
to one person
The process itself was in place: requests were created, cleared accounting and reached the director. It broke at the very last step.
Logging in for one button
To approve a payment the director opened the corporate system, found the request in a table, opened the record and clicked a button. A few minutes per payment, twenty times a day.
Payments waited for someone to reach a desk
The director is not always at a workstation. Requests piled up, and with them the questions from suppliers and accounting about when the money would move.
Everything automatable ran into the absence of an API
The system exposes no external interface. The built-in exchange module we had hoped for turned out to be meant only for moving data between modules inside the system itself.
A system you cannot
knock on from outside
This was the decisive technical fork of the project, and the reason the task had stayed unsolved for years.
We checked the official integration path first. The vendor specialist on the client side confirmed it: the exchange module moves data between internal modules, it is not a bridge to outside systems. Direct calls to the internal interface ran into an authorisation flow that cannot be reproduced from outside.
Instead of forcing a closed door, we took the same route a human takes. The robot opens the system in a browser, signs in with its own account and works through the interface exactly as an employee would: finds the right approval stage, reads the request data, opens the record, clicks the button.
One difference from a human: the robot does this every ten minutes, around the clock, and never forgets.
Four steps
with no human in between
The robot checks the system
Every ten minutes it signs in and looks for new requests at the relevant approval stage. Anything already sent is not picked up twice — each request is identified by its document number.
It collects the data and takes a snapshot
Every field needed for a decision is pulled from the request: paying company, recipient, amount, currency, invoice number, document number, project code, originator. It is laid out as a table and sent as an image into a WhatsApp work group.
The director answers in his own words
Not with buttons or codes. He writes the way he would to a colleague, in Turkish or English. The model reads the intent behind it: approve, send back for revision, or not a decision at all.
The decision lands back in the system
The robot returns to the system and clicks the same button the director would have clicked. A confirmation comes back that the operation went through. If something failed, the request stays in the queue and that is reported honestly.
This project moves money.
Safeguards are not optional
None of these decisions were made for elegance. They exist because the cost of an error is a real payment to a real supplier.
Commands are accepted from the director only
A message from any other group member is discarded before the robot even reads the text. It does not touch the system in that case, and the attempt goes into the log.
Bulk approval requires a confirmation
When requests arrive as a batch, a single "approve" does not push them through. The robot asks back: confirm all N requests for this total. An accidental "ok" does not cost the company money.
Sending back requires a reason
A request cannot be returned without a comment. The robot asks for the reason and passes it to whoever created the request.
A log of every action
Every send and every decision is recorded with a timestamp: which document, which decision, whether it went through, and if not, why. The log exports to a spreadsheet.
Ambiguity is never guessed
If the answer cannot be read unambiguously, the robot does not guess. It says it did not understand and asks again.
A reminder instead of silence
If there is no answer within an hour, the robot follows up. The reminder always refers to the request still open, never to one already decided.
Result
The director no longer opens the corporate system to approve anything. Requests come to him, in the messenger he already uses every day. Answering takes seconds instead of minutes.
A human still makes the decision. The robot approves nothing on its own — it delivers information and executes a decision already made. That is a deliberate position: where an error costs money, a person belongs between the system and the outside world.
The project was delivered and paid for in full in September 2026. It runs on a dedicated server, 24/7.
Stack
| Working with the system | Browser control — the robot walks the interface the same way a person does |
| Messenger | A separate business WhatsApp number connected to the group with the director |
| Reading the replies | A language model determines intent in free text, Turkish and English |
| State and logging | A record of sends and decisions, duplicate protection by document number |
| Hosting | The client's dedicated server, autostart, unattended operation |
Do you have a process
that bottlenecks on one person?
Tell us how it works today. In fifteen minutes we will find where it loses time and money, and say honestly whether automating it is worth it yet.