How it works

What you show us, and what we build

You show us the process once. Someone who actually does the work walks through it in the browser, and we record that. From the recording we write instructions in plain language: log in, open the outstanding lines, compare against the price list. Not a script of mouse clicks on fixed buttons; that kind breaks the moment the portal moves one. Credentials go into a vault: they are not in the instructions and they do not reach the log. Before anything runs for real we test the instructions against your own environment with test values. Which steps may not proceed without approval, and what counts as an exception, we agree with you up front, before we build anything. If you have already written the process down somewhere, we can start from that instead of from a recording. Whatever it starts from, it passes the same check before it goes into use.

Where there is a connection, we use it

Some of your systems have a proper connection. Others have a login screen and nothing else. That difference need not be your problem: one job can go both ways: through the connection where there is one, and through the screen where there is not. To you it is one job with one outcome.

A connection allowed to change anything is released per action, in advance. Without that release the job does not go through it: it would rather stop than try anyway.

One outcome, and one trail with both routes in it. If the other system does not answer clearly, the job records that as undecided, not as done. You see that it is unresolved, instead of it quietly passing for finished.

It does not build a connection that is not there. If a system has none, that part of the work goes through the screen: slower, and recorded just as fully.

How the work arrives

A job does not have to be scheduled. If the work comes in by email, the system picks that message up, works out which process it belongs to, and puts it in front of one of us. Only then does it run. Ask a question instead of setting a job, such as what price the contract with a supplier states, and the system looks the answer up in your own documents. Reading only, never changing. The answer is prepared as a draft, one of us checks it and sends it. No answer ever goes out by itself, and it always goes back to whoever asked. If the system is not certain, it says so. It does not invent an answer.

How long it takes

That depends on the process, and we name a timescale only after we have seen it. What drives the time is rarely the building; it is the exceptions. One route through one system has few variants. A process that runs through three systems, with two-factor along the way and a handful of cases that go differently from normal, takes longer, mostly because we have to meet those cases first. The order is fixed, though: watch, record, test against your environment, and the first real runs with us alongside. Only after that does it run at the agreed moment with nobody watching.

Why there is an approval in the middle

During setup we mark the steps that may not simply proceed: sending something, ordering something, paying something, making something final. At such a step the run stops and asks for approval. Its status genuinely becomes waiting for approval rather than quietly staying running, and the question reaches you. Say yes and it continues. Say no and it stops there. Until there is an approval the step does not go through: it does not proceed merely because nobody responded. If the answer stays out too long, the job ends as failed and we come and find you. Which steps need an approval is fixed in the process up front: the system cannot skip one. It can add a stop of its own: if a job reaches its cost ceiling, or the system cannot work something out, it pauses and asks anyway. It may always go that way; never the other.

When a run breaks at 03:00

It stops. It does not keep trying until something works: where we have set a retry, the number of attempts is fixed, and every attempt goes into the log. On the last attempt it may look for a different route to the same outcome inside that same step: it never invents a different goal, and that attempt goes into the log too. Everything up to that moment is kept, including a screenshot of the point where it went wrong; a failed run is precisely the one you want to be able to read back. We see the failure on our side, and on your overview the job reads as failed. You hear it from us, not from your customer. And then the part that belongs here too: a step that had already gone through has gone through: the system undoes nothing. What happens next we agree per process: starting it again once we have fixed the cause, or doing that one occasion by hand. The system also watches whether a page changes shape. If it sees a different layout on the same page across two separate jobs, that raises a flag. That is usually when we update the route: before something breaks, not after.

Afterwards we check that it is really there

Once the work is finished, most processes get a second check over the top of them that is only allowed to look. It compares what is on the screen with what should have been there. If it demonstrably does not match, the job counts as failed. If the check cannot establish it, it says so: the system does not pretend, and we look at it. A trail is left of every job: every step, every timestamp, and the screenshots that go with them. What is not in the trail did not happen.

What you get back

First the work itself: the file or the report, delivered where we agreed, by email or into a Drive folder we create for you, and always downloadable from your own overview as well. You reach that overview through a link from us; there is no account for you to create. You do not work in our system. You open a link and land on one page with your automations. Per automation you see the most recent jobs and the files they produced, and behind that the full history of that process. Per job you see where it stands: done, failed, running, waiting for approval, or cancelled. Looking for one particular job, you type in part of the invoice number, for example, and land straight on that one. Of every run we also keep the screenshots of what the system saw; if you want to look at those for a particular run, we open them up for you.

What the system sees of you, and what it does not

Your credentials go into a vault. They are not in the instructions, not in the log, and not in the files a job produces, and they never reach the language model that carries out the steps. When a password is filled, the system records only that the field was filled: not what was in it, and not how long it was. On screenshots it is masked at the moment of capture. The tooling we use internally to string processes together never sees your credentials. The page you see is separate from our own working screen: from there, no technical logs, no approvals and nothing belonging to another customer can be reached. And which websites a job may visit is set down in advance: with a recording, those are the sites it passed through. A job may not go outside that. If a link points somewhere else, the job does not follow it; it stops instead.