Business systems · AI automation
We connect agreed enquiry sources—such as website forms, supported call records, Instagram, WhatsApp and email—after checking account access and integration limits. The system checks your calendar and price list, drafts the reply, and a person approves it. Custom quotes, payments and complaint resolution require human approval. Built per business, from €500 per process.
Supported enquiry sources feed one list with the available source, customer record and history. The scope identifies connected channels, missing data, ownership and failure alerts.
to: Ola · website form
The system prepares the reply from your calendar, price list and past answers. A person approves it with one click. Only then it goes out, marked as coming from an assistant where the law asks for it.
Custom quotes, payments, complaints and sensitive advice sit outside the default autonomous scope. Written rules, permissions and approval steps define what must reach a person and how failures are handled.
How it works
The same path for every enquiry, whatever channel it came from. Hover a step to hold it.
Form, call, message or email. The system reads it and finds the customer record.
Calendar, price list, past conversations. Custom quotes and complaints are routed for review.
Written in the customer's language, with the slot or the price already in it.
One click in the inbox. Edit, send, or take over. Nothing leaves without this step.
The reply goes out, the CRM record is updated, a follow-up is scheduled if there is no answer.
Who this is for
Real questions these businesses get every day. Each card shows the kind of enquiry the system answers first.
Booking enquiries and reminder drafts prepared from a connected calendar, with availability checked and confirmation rules agreed before launch.
Viewing requests matched to the property and available times, with the source and responsible person recorded where the connected systems provide them.
Quote requests get a draft response with the details your team needs before estimating: location, dimensions, photos and the requested schedule.
Reservation, menu and opening-hours enquiries from supported messaging channels handled through an agreed inbox and handover process.
Proof
Every number below has its source and date next to it.
Of the conversations we dropped in 12 months, the watcher flagged about a third. our own system · Aug 2026
0 requests on 0 parallel threads, p99 0 ms. load test · Aug 2026
A Kraków estate agency: listings, prices and photos flow from their CRM to the website without anyone copying them. Read the case →
No client deployments of autonomous AI agents yet. We run those for ourselves and build each one per client.
What could go wrong
A person reviews drafts before sending. Review still takes time and can miss errors, so repeated failures are investigated in the source material, workflow and validation.
We define fallback routes and test uncertain, incomplete and out-of-scope requests. Models can still misclassify a message; approval controls and review of failures help identify where the workflow needs changes.
Where the integration supports it, failed items are queued and a person is alerted. We test retries and document cases that require manual recovery.
The agreed workflows, account access and documentation are handed over. Continued operation depends on active provider plans, valid credentials, maintenance and a named owner.
Price
Fixed in writing after a short call. You keep everything that is built.
Automation is useful when a repeated task has a recognisable beginning and a clear result. An enquiry arrives, a record changes or a scheduled report is due. The first step is to trace what people currently do between that event and the completed outcome. This often reveals that the main problem is a missing owner or inconsistent data, rather than the absence of AI.
Choose one trigger precisely. A submitted form is different from a new email thread, and a paid invoice is different from an invoice that has merely been created. Record which system supplies the event and how it identifies it. A vague trigger can cause duplicate work or leave the process waiting for information that never arrives.
Define completion from the business’s perspective. For an enquiry, creating a CRM row may only be the beginning; the responsible person also needs the context and a next action. For a report, the numbers need a stated period and a known source. A workflow is complete when the intended person can use its output without reconstructing the missing steps.
Not every part of a workflow benefits from a language model. The design should separate fixed business rules from tasks that require interpretation. This makes behaviour easier to explain, test and maintain. It also helps control running costs because simple operations do not need to be sent through an AI service.
Rules are suitable for required fields, routing by a selected service, date checks and standard calculations. A known department can receive a known type of request without asking a model to decide. Where the business policy is unclear, it should be agreed first. Encoding an unresolved disagreement in an automation simply makes the disagreement run faster.
AI can help extract information from free text, suggest a category or prepare a draft summary. Those outputs need validation appropriate to the consequence of an error. A suggested label may be easy to correct, while an invented price or commitment is more serious. The workflow should apply checks and approvals before consequential actions occur.
Check that the trigger contains enough information and that it has not already been processed. Decide how to handle empty fields, unusual formats and repeated submissions. If a required value is missing, the workflow should put the item into a visible review state or request clarification through an approved route. Silently dropping the item is not a useful fallback.
Connect the necessary systems with the least access required. Name the source of truth for each field so two tools do not overwrite each other indefinitely. If an action affects a customer, decide whether it needs a person’s approval. The proposed workflow should show where that approval happens and what information the reviewer receives.
Keep a useful execution record and send failures to someone who can act. A log should explain which step failed without exposing unnecessary customer information. Plan safe retries: repeating a failed read is different from repeating a payment or message. The process needs a way to resume from the appropriate point without creating duplicate records or actions.
Test a normal item and then submit it again. Check that the system recognises whether the second event is a duplicate or a legitimate update. Try realistic variations in input and confirm that the output remains usable. The acceptance cases should include the information your team actually receives, not only carefully prepared examples.
Simulate a failed connection, expired access and an unavailable downstream service. Confirm where the item waits and who is alerted. A workflow that runs smoothly while every service is healthy can still fail commercially if nobody notices an outage. Document which failures can retry automatically and which require investigation before another attempt.
The team should know how to pause the process, inspect a failed item and use the manual fallback. Ownership matters when the original builder is unavailable. Record the connected accounts, renewal responsibilities and change procedure. Adding a new field or altering a CRM stage can affect the workflow, so routine business changes need a defined review route.
Describe where the task starts, which tools it touches and what the completed result looks like. A short screen recording or a written example is often enough for the first review. Include one awkward case and the approximate volume. Remove personal information that is unnecessary for understanding the process.
A single-process automation starts at €500, and a system connecting several processes starts at €1,500. The quote identifies integrations, approval steps, testing and handover. Provider subscriptions, model usage and hosting are separate where applicable. An unavailable API or restricted account may change the implementation, so access feasibility is checked before promising a connection.
We can then propose a pilot with a baseline, an acceptance checklist and a named owner. Review the first real items before expanding the scope. The useful result is a task that is easier to operate and recover, with evidence of the work it saves and a clear understanding of what still belongs to a person.
Questions
Repeated tasks with accessible inputs and a clearly defined result are candidates. The first candidates are the replies to enquiries: website forms, missed calls, messages on Instagram or WhatsApp, emails asking for a price or a slot. Then follow-ups when somebody goes quiet, invoices after a finished job, and the handover of every enquiry into one list with ownership and error handling defined.
From €500 for one process, for example missed calls turned into a callback. From €1 500 for a system of several processes: enquiries from agreed, supported channels in one inbox, drafts, follow-ups and a CRM record. The price is fixed in writing after a short call, before the work starts.
Both, in that order. On the first call we look at how enquiries reach you today and identify two or three candidates and assess their likely benefit against running and review costs. If you want the analysis on paper before deciding, ask for an audit: it is a short written plan of what to automate, in which order, and what it costs.
The schedule depends on the number of steps, integration access, source preparation, approvals and testing. We confirm it after checking those dependencies. A small pilot is scoped separately from a system spanning several processes.
The intended fallback is a handover with context. Custom quotes, complaints and sensitive questions require a person. We test those routes and enforce approval for outbound replies in the default workflow; automatic sending requires a separately approved scope. A model can still misclassify a request, which is why prompts alone are insufficient.
The agreed automations, account access and documentation are handed over. Provider subscriptions and ongoing maintenance remain necessary. Disclosure, any call recording and retention are assessed for the deployment, with approved requirements implemented before launch.
A short call, then a fixed price for the first process in writing.