Inbox AI. The 23:10 request doesn't wait for tomorrow morning.

Almost no business loses requests because it answers badly. It loses them because requests arrive on four different channels, and there is no place to see them all together.

This is the page for a single piece of the system. The other pieces, and the criterion for choosing which to start from, are on the services page.

Four channels, no list

The places a request can come from have multiplied, and each one is one more inbox to check. In 2025 63.57% of European businesses use at least one social network, and in Italy the share is 58.97%: this is measured by Eurostat in its ICT survey of enterprises, which writes «In 2025, 63.57% of EU enterprises used any type of social media».

In accommodation and food service the same survey reaches 78.25%, the second-highest share of all sectors. Those who work in these trades receive requests from one more channel than the others, and that channel talks neither to the mailbox nor to the management software.

On the other side is the phone in the customer's hand. Istat, in its 2025 release on Citizens and ICT, reports that 79.1% of people aged 6 and over go online via a smartphone. The request goes out when the customer has the phone in hand, not when the office is open.

The request that costs most is the one nobody ever saw. Before buying anything it pays to do the maths: the cost of answering by hand, in six lines and three numbers of your own. It arrives in the evening, on a channel nobody is watching at that moment, and by the next morning it has sunk beneath ten other notifications.

The practical point is that the business has no way of noticing. To know which requests were left without a reply you would need a single list, and that list doesn't exist in any of the four channels, because each one knows only itself.

A request without a reply shows up nowhere. It is the only loss that leaves no trace to read.

The useful window is narrower than it looks

Whoever contacts a potential customer within 5 minutes of the request is up to 100 times more likely to make contact with them than someone who waits 30 minutes. The figure comes from research by Harvard Business Review with InsideSales.

That number measures US web leads, not the email of a food buyer or the message of a couple looking for a venue, and the difference matters. We have written a whole page on what it really says and what it doesn't: the five minutes that decide a request.

What holds even outside its sample is the direction: the probability of contact collapses quickly, and it collapses in minutes, not days. On where automated request handling is heading, with the appropriate caveats, there is Gartner's forecast on customer service.

What the system does, step by step

Every incoming request, from any channel, enters the same point and receives an identifier. From there the route is always the same, and each step leaves a log entry saying what happened and when.

Step	What happens	What you get
Captureevery channel	WhatsApp, email, website forms and phone converge into a single list, with date, channel and content.	A single place to look, and the answer to the question that has no answer today: which requests haven't been worked on yet.
Classificationon arrival	The request is sorted by urgency and type, and gets a priority.	The requests that matter are seen first, and people's time goes there instead of to the first message opened.
First replyautomatic outside hours	Recurring questions get an immediate reply built on the information the business has already approved, which states that it is a system.	Whoever writes in the evening gets a real reply straight away, and the next morning you find a conversation already under way instead of a message sitting there.
Fallback routewhen the model gets it wrong	If the classification doesn't arrive or arrives malformed, fixed rules still sort the request and keep it on the list.	No request disappears when something breaks, and that is the worst damage of all.
Handover to a personwhen it commits the business	Quotes, prices, discounts and confirmations are prepared with the context gathered, and wait for approval.	You decide on prices and confirmations, with the context already gathered in front of you and without having to reconstruct it.

The fallback route, and why it matters more than the model

A system built around a language model has a typical way of breaking: the model doesn't answer, or answers in a format the rest can't read, and the request slips through the net. The failure makes no noise, exactly like the problem the system was meant to solve.

Here there is a second route that doesn't use the model. It sorts the request with fixed rules on urgency and content, and keeps it on the list. Each row records whether it was handled by the model or by the fallback, so the error gets counted instead of disappearing.

The engine is built and tested on its test branches, with no real customers involved. It is a functional check, and we state it for what it is.

What goes out on its own, and what waits for a person

Outside working hours the reply goes out on its own, and that is why this piece exists. The 23:10 request immediately gets availability, opening hours and basic information: content the owner approved once and that the system simply repeats.

During working hours the owner chooses, channel by channel. Some businesses prefer to answer in person while someone is in the office, others let the system work during the day too and step in where needed. It is a switch that can be turned on and off at will, without touching the system again.

What never goes out on its own is whatever commits the business: a quote, a price, a discount, a confirmation. Those replies are prepared with the context already gathered and wait, because they are decisions.

Opening hours can be repeated. A price is decided.

The time recovered is the time spent waiting and retyping, never the time spent judging. If a request needs a person, the person sees it sooner and with more context, not later.

The automatic reply states that it is a system

From 2 August 2026 Article 50 of Regulation (EU) 2024/1689 on artificial intelligence applies, and for whoever uses a system like this it translates into a duty to inform: the person must know they are talking to a system.

The moment when it must be said is set by paragraph 5 of the same article: «The information referred to in paragraphs 1 to 4 shall be provided to the natural persons concerned in a clear and distinguishable manner at the latest at the time of the first interaction or exposure». So it is stated in the first reply, not once the conversation is under way.

So the automatic reply says so, in one line, within the text itself. It costs nothing and removes the only serious risk of the function. What really changes for a small business we have written in the AI Act and Italian SMEs, and the systems we use are listed on the AI transparency page.

The same statement keeps the tone honest. Nobody discovers halfway through a conversation that they have been talking to a machine while believing they were writing to the owner, and the reasoning behind this choice is on the page about the principles we build with.

The same thing changes name with the trade

The mechanism is identical; the request that gets lost isn't. It is worth looking at your own case, because that is where you see how much it costs today.

Sector	The request that gets lost	Where you see it
Food and agricultureand export	The email from a foreign buyer that arrived at 23:10, from a time zone that isn't yours, with a question about formats and the price list.	The typical day of a small producer who exports
Hospitalityaccommodation and events	The three requests that arrived on WhatsApp between 22:00 and midnight, when people actually plan their holidays.	The pre-season of an accommodation business
Restaurantsand bars	The call nobody answered during service, which went to the next restaurant without leaving a trace.	The service of a dining room where the phone rings unanswered

What this piece doesn't do

It doesn't replace the management software, the CRM, the channel manager or the switchboard. It works in the layer that doesn't exist today, the one that gathers the requests scattered outside those systems and brings them back together with the others.

It doesn't bring in new requests. It works on the ones already arriving, and that is why it is almost always the first piece to build: the return is measured on the current volume, without depending on a campaign that still has to work.

It doesn't decide for anyone. It repeats information approved beforehand, sorts and flags, and stops where a choice that commits the business begins.

Questions and answers