AI implementation services, chosen by the symptom in front of you
Nobody wakes up wanting an integration. They wake up because the invoice figures were retyped wrong again, or because an enquiry sat unanswered over a weekend. The service you need is downstream of that.
So this page sorts symptoms into services: what a given symptom usually means, which of the five it points to, what order the work tends to run in, and where that order changes. JNET.support is Apefo Ltd's trading name. The person writing the diagnosis is the one who then does the work, which is why the argument here is about sequencing rather than capability.
Start from the symptom, not the service
The middle column is the part that matters. Buying mistakes tend to happen because the symptom and the cause sit in different places. You buy an assistant to answer questions when the real problem is that two documents disagree, and now the assistant quotes the wrong one with confidence.
| What you are seeing | What it usually turns out to be | Where to start |
|---|---|---|
| What you are seeingThe same figures are retyped into three places each month | What it usually turns out to beThere is no agreed source record. Each system holds a slightly different version, and the retyping is how they get reconciled. Removing the typing without settling which system is authoritative just moves the disagreement. | Where to startIntegrations |
| What you are seeingNew enquiries sit unanswered overnight | What it usually turns out to beThe form posts to a shared inbox that nobody owns after 17:00. This is a routing and ownership gap, and a faster tool will not fix it. | Where to startProcess automation |
| What you are seeingTwo people give customers different answers to the same question | What it usually turns out to beThe answer exists in two places and one of them was never updated. That is a documentation problem first; an assistant built on both sources will reproduce the contradiction. | Where to startReadiness assessment, then assistant |
| What you are seeingA spreadsheet has become a system of record and nobody trusts it | What it usually turns out to beSeveral people have write access, no column is validated, and the last person to save wins. What people distrust is the uncontrolled writes. | Where to startIntegrations |
| What you are seeingStaff use ChatGPT but nobody knows what they paste into it | What it usually turns out to beThere is no shared definition of what counts as client data, so each person applies their own. Nothing has visibly gone wrong yet, which is exactly why nobody has raised it. | Where to startTraining |
| What you are seeingThe monthly report takes two days to put together | What it usually turns out to beMost of those two days is collecting and reformatting. The actual analysis is usually the last hour. Automating the analysis saves the hour and leaves the two days. | Where to startProcess automation |
| What you are seeingEvery quote is built by copying last month's quote | What it usually turns out to beThe template has drifted. Each copy carries forward the previous job's assumptions, including the ones that were wrong, and nobody can say which version is current. | Where to startProcess automation |
| What you are seeingThe CRM is full of duplicate contacts | What it usually turns out to beTwo entry points create records and they do not agree on what identifies a person. The website form matches on email, manual entry matches on name, so the same customer lands twice. | Where to startIntegrations |
| What you are seeingYou bought an AI tool and usage dropped off after week three | What it usually turns out to beIt was introduced as a tool and never attached to a task someone is accountable for. Adoption stalls wherever the tool sits alongside the old step instead of replacing it. | Where to startTraining |
| What you are seeingA process breaks whenever one specific person is on holiday | What it usually turns out to beThere is an undocumented manual step in the middle. It is usually a judgement call, a login, or an approval that only they have. | Where to startReadiness assessment |
If your symptom is not on this list, the pattern still holds. Describe what you saw last week and the service follows from that.
The five services
Short descriptions on purpose. Each has its own page with the detail.
- AI readiness assessmentMapping what happens versus what people believe happens, then deciding what should change first. It produces a written workflow map, a list of candidate changes with the reasons they are ranked that way, and a note on what should stay manual.
- Process automationBuilding the rules and handoffs so a repeated task runs without someone shepherding it: intake routing, recurring report assembly, status notifications, document preparation. A good deal of this involves no AI at all, because deterministic rules are easier to test and easier to hand over. See how the process automation work runs.
- Internal assistantsA scoped assistant over approved internal material (policies, product notes, past answers), with a defined user group and a named person who keeps the source current. Assistants fail on maintenance more often than on capability. More on internal assistants for teams.
- TrainingPractical sessions for people already using AI without shared rules: what goes in, what does not, how to check an output before anyone acts on it, and role-specific examples using your own documents. This is the service that most often belongs first. Detail on AI training for companies.
- IntegrationsGetting systems to hand records to each other: website form to CRM, CRM to reporting sheet, email to task, document template to output. This is where most business process automation companies spend their time, whatever the pitch says. See connecting existing systems.
What order these usually go in
Most of what gets sold as AI implementation consulting is this one sequencing decision, made properly, before anyone spends money on a build. The default is audit, then one narrow pilot, then a decision about whether to extend. The pilot stays deliberately small: one workflow, one owner, one measurable before-and-after that the owner can check without a report. That order exists because the expensive mistake is automating a process that was about to be redesigned anyway.
- When we skip the auditIf the workflow is already written down, has a single owner, one trigger and one output, there is nothing to assess. A website form that needs to create a CRM record does not need three weeks of discovery. The same applies if you have had a decent process review recently. Bring the document and we will work from it. Training almost never needs an audit in front of it either, because the problem there is behaviour.
- When integration comes before automationIf the automation would need to read data that lives in two systems which currently disagree, the integration has to be settled first. Otherwise the automation encodes the disagreement and runs it faster. The tell is when someone says "well, the real number is in the spreadsheet, the CRM is out of date." Same thing when the trigger event is not visible to any system yet; you cannot automate a response to something nothing records.
- When training jumps the queueIf people are already pasting customer material into public AI tools with no agreed line about what is acceptable, that gets handled before any build. It is cheap, it takes hours rather than weeks, and it changes what is safe to build afterwards.
- When the answer is to stopA process can turn out to be fine, with the real problem being that two people were never told which of them owns the handoff. That gets written down and the engagement ends there. It is a worse outcome commercially and a better one for you.
- When the problem sits under the applicationIf the diagnosis is an undersized server, backups that are not verified, or a database that has become the bottleneck, no workflow change will help. That work goes to our sister brand YNVAR for managed hosting rather than being bodged at the workflow layer.
What we turn down
- Replace the team with a bot
"Replace the support team with a bot" is declined. A request like that needs a body of written answers for the bot to draw on, and where those do not exist the first month goes on documentation nobody budgeted for. Start with the documentation instead and see how much of the problem it solves on its own.
- Active reorganisation
Anything under active reorganisation gets postponed. If the department is being restructured, the CRM is being replaced next quarter, or the process owner is leaving, automation built now is scrap. That is worth establishing at the first call rather than three weeks in.
- No process owner
We do not take on processes that currently have no owner. If nobody is accountable for the outcome today, nobody will be accountable for the automation the week it starts producing subtly wrong output, and eventually it will. A named owner is a precondition.
- Mission-critical decisions
Mission-critical or safety-relevant decisions do not get automated without a review step in front of them, and if a client wants the review removed to save time, that is where the engagement ends. We are also not the people to sign off data protection or security questions. Those need someone qualified and insured to answer them, and that is not a role a workflow supplier should be improvising.
- A savings figure in the proposal
We will not put a savings figure in a proposal, whether as a percentage or as hours per week. A figure invented at proposal stage exists to close the sale, and it has a habit of coming back later as a target you never agreed to. What a proposal can hold is the scope, the systems it touches, and how the result behaves when it fails.
Where a page on this site describes something going wrong in a specific way, it usually went wrong here first.