Why the difference matters more than the success rate
Owners ask the right question about any automation pitched to them: when it does nine out of ten, is the tenth a wrong order or an incomplete one? The two cost completely different amounts.
An unplaced order costs a few minutes: someone opens the email, sees why it was kicked out, and enters it by hand. A wrong order costs a drive to the wrong address, the wrong package on the invoice, a photographer who could not get in, and an agent who finds the mistake before you do.
Where wrong orders come from in automation
Almost every wrong order an automation places comes from one of five shortcuts. Each one is the automation filling a gap instead of admitting it.
- Guessing a field it could not read — the square footage, the time, the package.
- Landing on the default order form instead of the one for that office and region.
- Picking the agent by name, when two agents share a name or one agent has two accounts.
- Booking the requested time in the wrong time zone — the email is in the agent’s zone, the calendar in yours.
- Submitting twice after a slow page or a timeout, so the same listing gets two orders.
How a safe setup is built not to guess
Every technical choice below serves one rule: a value is either proven or it is missing, never invented. Our Concierge Order Intake module follows it — agent by email, the right form for the office, no payment step, the order number read back, unsure orders kicked out, never the same order twice.
- Reading the email: a parser or a language model turns the email into a fixed set of fields — address, square footage, package, selections, requested window, agent email, access, notes. Each value has to appear in the email itself; if it is not there, the field stays empty.
- Rules before any click: the agent is found by exact email address; the order form comes from a table of offices and regions; products come from a mapping per office; the requested time is converted from the agent’s time zone.
- Placing it: the order form is filled through a team-member login, field by field, the way a person on your team would, with no payment step.
- Checking it: after submit it reads the order number back from the system. No number, no “placed”.
- One attempt per email: each email carries its own key, so a retry after a timeout cannot create a second order.
- Everything else is an exception: the email gets a label, and your team gets a note naming the exact reason — agent not found, no slot in the window, new client, a field it could not read.
What to ask before you trust any of them
Whoever builds it, these four answers tell you whether the misses are safe ones.
- When it misses, does it place a wrong order or kick the order out?
- Where exactly is a kicked-out order marked — a label, a ticket, an email — and who sees it?
- How does it know an order really exists after it submits?
- What stops it from placing the same order twice?
What the first two weeks should look like
Run it alongside your team at first. Every order it places is compared with what a person would have entered, and every exception is read for its reason. Exceptions are expected early — a new office, a product nobody mapped, an agent who is not in the system yet. Each one is a mapping to add, and the count drops as the table fills in. Wrong orders are not expected at all; one wrong order in the first two weeks means a rule is missing.