What JNET.support is
An AI automation agency and consultancy working at the application layer. The forms, spreadsheets, inboxes, CRMs, documents and reports your team touches during the working day. Adrians Petrovs does the discovery, the build and the handover.
Five kinds of work come out of that. The last column is where projects stall.
| The work | What comes out of it | What has to be true first |
|---|---|---|
| The workReadiness assessment | What comes out of itA written decision on whether to build at all, with the reasoning attached | What has to be true firstSomebody willing to be watched doing the task, on the real files |
| The workProcess automation | What comes out of itRoutine cases running without anyone typing, odd ones flagged before they do damage | What has to be true firstAn owner named before the build rather than found afterwards |
| The workInternal assistants | What comes out of itAnswers drawn from documents you have approved, with the passage shown | What has to be true firstSomeone who will say which documents are current, and keep saying it |
| The workIntegrations | What comes out of itTwo systems passing data directly, with field mapping and duplicate rules agreed | What has to be true firstSomeone who will say which system wins when the two disagree |
| The workTraining | What comes out of itA team using AI on their own work, under a rule about what must never be pasted in | What has to be true firstEnough tool access that nobody needs a personal account |
JNET.support does not run your servers, host your models or manage your databases. Work that needs that goes to YNVAR instead. Most of this runs on tools you already pay for, and the full service breakdown compares all five.
The problems this is built for
Someone starts the day in the form inbox. A person opens each overnight enquiry, copies the details into the CRM, sets an owner and forwards the interesting ones to sales. The best part of an hour, every morning, and nobody has counted how many of those enquiries duplicate a contact that already exists.
The monthly report is rebuilt by hand from four exports. They go into a master workbook, the lookups get repaired because a column moved again, and the numbers are formatted for the board pack. Most of a day, once a month, and one person knows the order of the steps.
Support replies get written from scratch every time. The approved wording for refunds and cancellation terms sits in a document nobody has opened in months, so three agents produce three readings of the same policy and one is wrong about the notice period.
The common thread is that the process was never written down, so nobody can say which parts are rules and which parts are judgement. That distinction decides what the fix has to be.
Start with a readiness assessment
What decides the cost of an automation is the exception nobody mentions, the manual patch, and the step somebody added last year and never told anyone about. Those come out of watching the work.
The assessment is a fixed-scope review of one or two processes. A short scoping call, evidence you send over, then 60 to 90 minutes on a screen share where you do the task while I watch and ask questions. The written output follows within five working days.
What the session collects:
- The trigger. What starts the task, and who notices when it does not.
- The inputs. Real files, merged header rows and missing fields included.
- The decisions. Every point where a person picks between two paths.
- The exceptions. Cases handled by hand, and roughly how often.
- The output. Where it goes, who reads it, and what they do when it is wrong.
- The sensitive data. Which fields would be a problem outside your systems.
What comes back is a written scope. The process drawn as steps, each marked rules, model-assisted or human-only. The exceptions listed with a decision for each, the access a build would need, and a recommended first piece of work with what it covers.
An assessment can also conclude that the process should not be automated yet. Source data too inconsistent to act on, a process about to change anyway, or a bottleneck that turns out to be an approval sitting with one person. You get that answer in writing, the document is yours either way, and there is no obligation to build anything.
If you already know what you want built, say so and we can scope that instead. Full detail is on the readiness assessment page.