Assistants that answer from your own documents and data. Agents that act: create the record, send the reply, hold the slot. Chatbots that qualify an enquiry before it reaches you. All of it wired into the systems you already run, with guardrails you can read.
20 minutes. You leave with a clear view of what to build first, whether you hire me or not.
The assistant on this page is one of mine. Test it properly.
Ask ODUEX is the assistant I built for my own site. It is the same build I would fit to your business, pointed at mine instead. It streams its answers, it knows what I build and how the work runs, and when a conversation turns into a real problem it makes sure I see it.
Push it. Ask something it can’t know. It will say so and offer the call instead. That behaviour is built in, not a failure. And if you leave an email, the whole conversation reaches me as one enquiry. Nothing gets retyped.
It’s my assistant, not me. It can be wrong, and anything that matters I confirm myself.
The assistant needs JavaScript, which is off in this browser. Everything it would tell you is one message away:
Chat is the surface. The value is what happens after the message: the record created, the slot held, the right person told. Every build below is judged on that.
You answer the same forty questions a month, and the answers live in your head or a folder nobody opens.
I build assistants grounded in your own material: service lists, policies, job history, the questions your customers actually ask. It answers with your facts, says when it doesn’t know, and hands over to a person rather than guessing.
Answering is the easy half. The admin after the answer is what eats the day.
An agent goes further than replying. It creates the CRM record, drafts the follow-up, holds the calendar slot, and notifies whoever needs to move. Every action it can take sits on a short allow-list you approve, and every run is logged.
Enquiries arrive at 9pm and get answered at 11am. By then they’ve called someone else.
A qualification bot asks the questions you would ask. What the job is, how urgent, what’s been tried already. Then it routes: urgent to your phone, routine to the diary. You get a formed brief, not a bare email address.
A worked example from a pattern I build for trades and service businesses. The visitor thinks they’re chatting. Underneath, a job record is being formed.
Visitor: Do you fix boilers? Mine keeps losing pressure and I’ve got tenants in the flat.
Assistant: Yes. Pressure loss is usually fixable the same week. Two quick questions so this gets booked right: is any water actively leaking, and roughly how old is the boiler?
Visitor: No leak that I can see. About ten years old.
Assistant: Thanks. I’ve logged this as an urgent repair rather than an emergency call-out, and held the first available slot. You’ll get a confirmation by text in the next minute, and the engineer sees this whole conversation before knocking.
Urgent repair · record created · slot held · owner notified
Two questions separate an emergency from a repair. The bot asks them because the diagnosis was scripted with the owner. That judgement is the build, not the chat window.
The record, the held slot and the notification all exist before the visitor closes the tab. Nobody retypes anything at 8am, and nothing lives only in a chat log.
An upset customer. A legal question. A job outside scope. Anything ambiguous goes straight to a person, with the full transcript attached.
Every enquiry seen, sorted and actioned within seconds of arriving, and a person pulled in the moment judgement is needed.
A bot that lives in a silo makes work instead of removing it. These read from and write to the tools your business already trusts, or the CRM I build you.
The tools underneath get named, not hidden: Make.com and n8n for the plumbing, Anthropic and OpenAI models for the reasoning, Cloudflare for the functions in front of them. The assistant on this page runs on the same models, behind the same Cloudflare functions.
This is the part nobody demos and everybody should ask about before giving a system access to customers. Ask me, or ask the assistant, which answers from the same policy.
It’s grounded in your documents and scripted to say “I don’t know” rather than improvise. Anything it isn’t sure about goes to a person with the transcript attached. In the first weeks live, we review real conversations together and tighten the answers. That review is part of the build, not an extra.
To providers we agree before the build, named in the proposal, in accounts that belong to you. The model receives what it needs to answer and act, nothing more. Nothing is sold, shared or used to train anything.
It sounds like your business, because it’s written with you: your tone, your phrases, your rules on what it may promise. And it introduces itself as an assistant, because a bot pretending to be a person costs you trust the first time someone notices.
No. You get a plain way to see conversations and change answers, full handover documentation, and a walkthrough at launch. You own the accounts and the workflows, and everything is exportable. If we part ways, it all keeps working.
If enquiries wait overnight, if the answers live in one person’s head, if the chat widget you tried just collects email addresses. That is exactly what the 20 minutes is for.
20 minutes. You leave with a clear view of what to build first, whether you hire me or not.
Prefer writing? enquiries@oduex.com. I reply to every enquiry personally within one working day. If I can’t help, I’ll say so and point you at someone who can.
Ask ODUEX
Daniel’s assistant · answers, then routes
I’m the assistant Daniel built for ODUEX. Ask what he builds, how the work runs, or tell me what is going wrong in your business and I’ll tell you where he’d start.
Daniel’s assistant, not Daniel. It can be wrong, and anything that matters he confirms himself. Leave an email and the whole conversation goes to him.