Services
Two kinds of work, and both are handed over complete.
Looma does two kinds of work: internal AI for companies, and business web apps. Both end with a system handed over complete: documented, trained on, and used.
01 · Internal AI for companies
The primary line: described in the most detail.
What the work looks like
- Document and rules assistants: ask in everyday language, answered from the company's official documents.
- Internal chatbots over policies, SOPs, and workplace safety rules.
- Automation of repeated processes that are still manual.
- Integration into systems already in use.
The problem this solves
Rules are scattered across dozens of documents, people ask colleagues instead of reading procedures, and answers vary depending on who you ask. Good internal systems remove all three: the answer is one, consistent, and checkable.
Why these implementations fail
Three common failures: answers that make things up, no source citations, and no way to check answer quality. We handle them with three rules: answers must be traceable to a source, every answer carries a citation to the clause or document, and the system must be able to say “not in the documents”: that is a feature, not a shortcoming.
Timeline and end result
4-12 weeks depending on document volume and integration depth. The end result is a system the team uses every day, with documentation and brief training.
02 · Business web apps
Briefer, but still finished.
What the work looks like
- Catalogues and showrooms: goods or services people can see, search, and filter.
- Record-keeping systems: a replacement for spreadsheets that have outgrown their job.
- Company sites that are actually finished.
What sets this apart
The scope is closed at the start, including a written list of what is not built. That is what keeps a project from ballooning and never being delivered.
01 · Internal AI for companies
Internal company chatbot: when it helps, and what separates a working one
An internal chatbot is an assistant that answers employee questions from the company's official documents: policies, SOPs, and workplace safety rules: in everyday language, not from a pre-programmed menu. It helps when rules are scattered across many documents, when answers vary between colleagues, and when employees would rather ask than read a procedure. It does not help when the problem is not document access but data that does not exist yet, decisions that should be made by people, or processes that are not written down at all. Three things separate a working internal chatbot from a demo. First, every answer is traceable to a source: a clause or document name is cited, so anyone can check it. Second, it is willing to say “not in the documents” for out-of-scope questions; that is a feature, not a shortcoming, because it does not make things up. Third, unanswered questions are logged and reviewed, so the system gets better every month. Cost and timeline depend on document volume and integration depth, not on question count. The problem-mapping session: including judging whether a chatbot is even the right answer: is free.
01 · Internal AI for companies
AI document assistant for company SOPs
An AI document assistant for SOPs works by reading the company's approved SOPs: the signed-off versions, not drafts: then answering procedural questions in everyday language with citations back to the original clause or page. SOPs are among the best material for this, because of their nature: written once, rarely changed, and their content is what gets re-asked most often. What can be realistically expected: new employees stop guessing procedures, repeated questions to relevant departments drop, and mistakes from following an old version disappear. What is not promised: the assistant does not replace human decisions, does not answer from employee data, and is not used for documents that have not been approved. To judge whether this assistant fits, we start by mapping the problem: which documents get asked about most, by whom, and what the right answer is today. That mapping is free and ends in a recommendation, not a sales pitch.
Maintenance retainer
Systems that are not maintained slowly stop being used.
- Monitoring, fixes, and small updates.
- A monthly allowance of development hours for adjustments.
The retainer is offered, never required. Clients keep full access to the code and may leave at any time: we say this openly, because that honesty is exactly why people take it up.
How we work
Four stages, in detail.
01
Map the problem
Outcome: a list of real problems and their priorities. Free of charge.
From the client: access to documents and the people who can explain the process.
02
Written scope
Outcome: a scope document naming what will be built and what will deliberately not be built.
From the client: decisions and written approval.
03
Build with regular review
Outcome: a running system reviewed regularly, not a surprise at the end.
From the client: timely feedback at each review.
04
Full handover
Outcome: the system, documentation, brief training, and full access to the code.
From the client: time for training and a list of users.
Pricing
No numbers here, and that is deliberate.
Price is set by scope, timeline, and integration needs. A written proposal is given after the problem-mapping session, and that mapping is free.
Discuss your needs