OhMyDesk 如何讓 AI 在確認後才修改真實商業資料

I run a small coworking space in Burgas, Bulgaria, with my wife. I also build OhMyDesk, the software we run it on.

Most of the admin in a small space happens on the go. Someone walks in and wants a desk tomorrow. A member pays in cash. A bill for coffee beans arrives. You are standing at the door with a phone, not at a desk with a dashboard.

So we added an AI operator to the Telegram bot that already sent us booking alerts. You type what you need in plain words. It answers questions about your space, and it can do the work.

That second part is scary. An AI that answers questions can be wrong and you shrug. An AI that writes to your bookings and invoices can be wrong and you lose money or a customer.

Here is the pattern that let us ship it anyway.

The rule: the model never writes, it only proposes

Every action goes through two steps.

1. Propose. The AI reads your live data and builds a concrete change. For example: "Book Alex on Desk 2 (Room 1), Tue 30 Jun, 1 day, 8 EUR."
2. Confirm. The chat shows that change with a Confirm button. Only the tap saves it.

A real booking looks like this:

You:  Book a free desk for June 30
Bot:  There's 1 free desk on June 30. That's Desk 2 (Room 1).
      Who should I book it for?
You:  Alex
Bot:  Book Alex — Desk 2 (Room 1), Tue 30 Jun · 1 day · 8 EUR
      [Confirm]
Bot:  ✅ Booked Alex on Desk 2 (2026-06-30).

Four messages. No forms. And the AI never had the power to save anything by itself.

If you build an agent that touches real data, I think this is the single most useful rule. Below are the lessons that came with it.

Lesson 1: Make the proposal concrete

A vague proposal is useless. "I will book a desk for Alex" does not let you catch a mistake. Which desk? Which day? At what price?

So every staged action shows the full result: who, what, when and how much. The human checks the same facts they would check on a paper form. If the date is wrong, you see it before it matters.

A good test: could a tired person at 8 a.m. spot the error in two seconds? If not, the proposal needs more detail.

Lesson 2: Ask instead of guess

When a request is missing something, the AI asks. "Who should I book it for?" "Which desk?"

It is tempting to let the model fill gaps with its best guess. Don't. A guess that looks confident is worse than a question. The question costs one message. The wrong guess costs an awkward call to a member.

Lesson 3: Keep short follow-ups in the same thread

People reply with fragments. "10:00." "Desk 4." "Yes, her."

If your agent treats each message as a new request, a fragment like "Desk 4" means nothing. Worse, it might start a new action. We made sure a short follow-up stays attached to the open conversation. The time or desk number fills the missing slot in the proposal already on the table.

This sounds small. In practice it is the difference between a chat that feels natural and one that feels like a broken form.

Lesson 4: Never let the model make up a number

Operators ask things like "revenue this month versus last" or "how many desks are free this week."

A language model will happily produce a plausible number. That is the worst possible failure for a business tool, because nobody checks a number that looks right.

So answers are grounded in the space's live data. If the data is not there, the answer says so. And each space only ever sees its own data. The AI cannot read another space's records.

Lesson 5: A stray message must be harmless

Telegram is a busy app. People type in the wrong chat. They paste text by accident. Kids grab phones.

With propose-then-confirm, a random message can at worst produce a proposal you ignore. It cannot cancel a booking or mark an invoice paid on its own. That gave us the confidence to let the bot do real work, not only answer questions.

Lesson 6: Speak the operator's language

Our customers are small spaces across Europe. Many prefer to type in their own language.

The operator can write in English, Bulgarian, Russian or most other European languages, and the bot replies in the same language. Since the action itself is structured (a date, a desk, an amount), the language of the chat does not change what gets saved.

Lesson 7: Draft, don't send

Some actions should stop one step earlier. An invoice is one of them.

When you ask the AI to draft an invoice, it saves a draft on the Invoices page. It does not send anything to the member. You review it and send it yourself. Money sent to the wrong person in the wrong amount is very hard to take back, so the human keeps the last word.

What the AI can do today

For context, this is the list of actions the operator can stage, each behind a Confirm tap:

• book, cancel, or mark a desk booking paid;
• mark an invoice paid, which also records the payment;
• freeze or reactivate a dedicated desk plan;
• log an expense with amount, category and date;
• let or vacate a private office;
• capture a new lead;
• draft an invoice for a member or a one-off guest.

It also answers questions like who is in today, which plans end soon, and which leads have gone quiet.

If you are building an agent that writes data

A short checklist, whatever your domain:

1. The model proposes. A human confirms. Nothing else can save.
2. Show the full change in the proposal: who, what, when, how much.
3. Ask when a detail is missing. Never guess silently.
4. Keep short replies attached to the open request.
5. Ground every number in real data. Say "I don't know" when it is not there.
6. Scope every request to one customer's data.
7. For anything that leaves the building (emails, invoices), stop at a draft.

None of this needs a better model. It needs a smaller job for the model and a clear button for the human.

If you want to see how it looks in a real product, the OhMyDesk AI Autopilot page has a short demo. The rest of the product is on ohmydesk.app.

I would love to hear how others handle this. Do you let your agents write data directly, or do you keep a human tap in the loop?