FAQ
The questions asked before anything is signed.
Answered the way we would answer them on a call. If your question is not here, ask it — the reply comes from one of the two founders.
Starting an engagement.
With one process, mapped. The audit has a fixed scope: the process as it runs today in BPMN, a ranked list of what can be automated, and draft success criteria naming the metric, its baseline and how it will be measured after go-live. Those documents are yours whether or not we build anything afterwards.
We publish no prices, because the audit is quoted per process — mapping a three-step approval is not the same work as mapping an order-to-cash chain, and a published figure would be wrong in both directions. You get a fixed figure in writing before you commit to anything.
Four documents: the process as it runs today, the ranked automation candidates with the systems each one touches, the draft success criteria, and a written recommendation on what not to automate. If the next step is not with us, they are complete enough to hand to whoever does the work.
The audit, and nothing beyond it. The build is a separate decision, taken once you hold the map, the ranking and the criteria — which is what defining success in advance is for.
How the work runs.
In yours. The automation runs in the ERP, CRM, commerce and mail systems already in production, and the integration work is documented as part of delivery. There is no Arkhon platform to license and nothing that stops working the day an engagement ends.
The two founders. One of them reads the submission, runs the scoping call and reviews everything that leaves the company — there is no account manager between you and the person building the automation. Freelance specialists we have worked with before join for defined pieces of work, and accountability for what is delivered stays with the founders.
It is handed over documented: what it does, where it runs, what breaks it and who to call. The people who operate the process are trained on it. Ongoing maintenance is a separate agreement you decide on afterwards, not a condition of the build.
You hear it from us. The criteria are agreed in writing before the build and measured after go-live, so a miss is reported as a miss — with what it would take to close the gap, or with the recommendation to stop. That is why success is written down first.
Whether this fits.
Repeatable ones, with rules somebody can state, enough volume for the effort to pay back, and a clear beginning and end. A process that changes shape every month is a process problem first. The audit ranks candidates rather than assuming the one you arrived with is the right place to start.
Frequently the answer is integration, rules and clean data rather than a model — and when it is, we say so. A model is proposed where it does something rules cannot: classifying free text, enriching a catalogue, reading documents nobody has structured.
For the mapping workshops, yes — in Romania and across the DACH region. The rest of an engagement runs remotely, in German, Romanian or English.
Data, regulation and language.
As few people as the work requires. We work inside your systems, under access you grant and can withdraw, and production data leaves them when there is a reason for it that is agreed in writing. What that means for a specific engagement belongs in the scope, not in a promise.
It depends on what the system does, and an honest answer needs the process in front of us. Some obligations bind today and others were deferred by the amending regulation — the advisory, training and governance page says which is which and links the regulation itself. We tell you where your case sits rather than selling urgency.
German, Romanian and English. Process maps, success criteria and documentation are written in the language you work in, and the commercial conversation and the technical one happen in the same language.
Your question is not on this page.
Describe the process you are trying to fix. If the audit is not the right next step, we will say so.