dohosGet started
PLATE Nº 056

Nothing external connects to Dohos today.

Dohos is the phone line and the console — the system that answers a call, and the screens a restaurant’s own staff use to see what came in. It does not connect to a point-of-sale system, hold a reservation, sync a calendar, or move money through a payment processor. That is a real limit, not a simplification, and it is worth being specific about exactly where the boundary sits.

PLATE Nº 056 · INTEGRATIONS
WHAT ACTUALLY CONNECTS, AND WHAT DOESN’T

A manual step, described as a manual step.

No system on this page is named, because none of them is connected — naming one would imply a relationship that does not exist in either direction. What is described instead is what genuinely happens, restaurant-side, once a call becomes an order, stated by function rather than by product.

The manual step is also not purely a downside. A silent, automatic sync between two systems that were never designed together is exactly the kind of thing that quietly drifts out of agreement — a price changed on one side and not the other, an item marked unavailable in one place but not the other. A manual step means a real person’s attention sits between the two. That is a genuine tradeoff, not a missing feature stated politely.

SIX CATEGORIES, IN PLAIN PRESENT TENSE

Every rung states a fact,
not a status.

No rung below carries a label about how far along something is, because that would describe an intention rather than a capability. Each states what is true of the product as it exists.

01POINT OF SALENO LIVE CONNECTION · A PERSON KEYS THE ORDER INAn order a caller places gets confirmed, read back in full, and sent to the restaurant. Once a staff member accepts it, it reaches them through Dohos’s own console and staff tablet — not through a sync into whatever system the restaurant rings sales through at the counter. Getting the accepted order into that system is a short, deliberate manual step: a real person keys it in, the same way they would an order that came in by phone before Dohos was answering the line.
02PAYMENT COLLECTIONNO CARD PROCESSOR CONNECTED · A VOICE ORDER SETTLES IN CASHA voice order settles in cash, reconciled directly between the restaurant and its customer, the same way it would if a staff member had answered the phone. Nothing electronic passes through a Dohos payment system on that order. Separately, and regardless of how a restaurant eventually takes payment, card numbers are never something Dohos asks a caller to say, captures, or stores — the isolation mechanism behind that holds whether or not a processor is ever connected.
03CALENDAR AND RESERVATIONSNO RESERVATION CAPABILITY IN THE PRODUCT AT ALLThis is broader than “not connected.” Dohos answers a call about placing an order, checking hours, or asking what is available. It does not hold a table, manage a booking calendar, or read from or write to one anywhere. A caller asking to book a table is told plainly that this isn’t something Dohos handles, rather than routed through a flow that pretends to take a reservation and quietly fails to honour it.
04TEAM COMMUNICATIONNO CHAT OR MESSAGING TOOL CONNECTEDThere is genuinely nothing further to add beyond that plain absence. The reason there isn’t a workaround worth describing is the last rung on this ladder — the one place a missing connection turns out not to be a gap at all.
05DEVELOPER ACCESSNO PUBLIC, DOCUMENTED INTERFACE FOR OUTSIDE USEThat kind of access needs a stable, published interface to build against, and nothing in that shape is available for outside use. A restaurant with its own technical staff who wants to build something custom has the same option as anyone else on this page: a conversation, not a document to start coding against.
06WHAT DOESN’T NEED AN EXTERNAL CONNECTIONTHE ACCEPTED ORDER REACHES THE STATION SCREEN DIRECTLYOne thing that looks like a missing integration from the outside is not a gap. Once an order is accepted it reaches the staff tablet directly, as a built-in part of the product — not a message routed through a separate ticketing or notification system a restaurant would have to connect and keep working on its own. That is a design choice about how an accepted order reaches the people who need to see it, not something Dohos left unbuilt.
FIG. IN-01 — SIX RUNGS · THE LAST ONE IS NOT A SIXTH ABSENCE, WHICH IS WHY IT IS TONED DIFFERENTLY
THE TWO PATHS THAT ARE REAL

One hand-off in.
One built-in path out.

IN — FROM WHATEVER CARRIER YOU ALREADY USE

Forwarding is the hand-off.

Calls reach Dohos because the restaurant sets forwarding on its own line, at its own carrier. That works from a carrier without anything being built for that carrier specifically — it is ordinary call forwarding, not a connection between two systems. Dohos has no visibility into a carrier account and can’t set it from its side, and no carrier-by-carrier reference of dial codes is published here, because a wrong code would be worse than none. See forwarding.

OUT — INSIDE DOHOS, NOT SYNCED ANYWHERE

The station ticket, and the record behind it.

An accepted order lands on the station screen directly. The text transcript of a completed call and the day’s closeout ledger live in the console, role-gated and retention-bound. All of that is reachable where it sits — none of it is pushed into another system, and this page does not claim a delivery mechanism it does not have.

THOSE ARE THE ONLY TWO PLACES ANYTHING CROSSES A BOUNDARY TODAY: A CALL ARRIVING BY ORDINARY FORWARDING, AND A PERSON READING A SCREEN. NOTHING ELSE MOVES BETWEEN DOHOS AND ANY OTHER SYSTEM, IN EITHER DIRECTION.

ONE CALL, START TO FINISH

Nothing about the manual step
happens silently.

01

THE CALLER ASKS FOR A PICKUP ORDER

Dohos reads the order back in full, confirms it, and sends the request to the restaurant.

02

A STAFF MEMBER REVIEWS AND ACCEPTS IT

On the console or the staff tablet — the same acceptance step every order goes through, no matter how it arrived. Once accepted, it appears on the station screen exactly as confirmed.

03

AND THEN A PERSON KEYS IT IN

If the restaurant rings sales through a system at the counter, a staff member enters the accepted order into it directly — the same short step they were already taking for a phone order before Dohos was part of the call. A person’s judgment sits between what a caller asked for and what gets rung up, rather than an unsupervised sync between two systems that might quietly disagree.

04

PAYMENT SETTLES THE WAY IT ALWAYS HAS

The customer pays in cash on pickup, reconciled directly between the restaurant and its own customer. Dohos is not a party to that payment at any point.

None of this is a connection waiting to be quietly wired up without anyone being told. It is a deliberate boundary, and the system is built to say so plainly the moment a call reaches a point where that boundary matters — rather than guess, improvise a workaround, or fail in a way nobody would notice:

DOHOS · WHEN A CALL REACHES A POINT NO SECURE PAYMENT PATH COVERSA verified secure Restaurant payment path is not available. Dohos will not take card or bank details by voice, text, or an unverified form. The order/payment remains [verified state]. Use [verified Restaurant alternative] or try again later.

That is not a hypothetical line written for this page. It is the response built into the system for exactly this situation, and it applies the same discipline everywhere else a caller reaches for something Dohos doesn’t connect to: state plainly what isn’t available, point to a real alternative, and never improvise a workaround that would misrepresent what is possible.

WHAT PEOPLE ACTUALLY ASK

Asked plainly, answered plainly.

Will this replace my point-of-sale system?

No. Orders still reach that system the way described above — reviewed and entered by a person, not synced automatically. Nothing about using Dohos requires replacing what a restaurant already rings sales through.

Can it take card payments?

Not today. The isolation mechanism that keeps card data away from Dohos entirely holds regardless — a caller’s card number is never something the system asks for, whether or not a processor is ever connected.

Does my menu need to be entered twice?

Today, yes. A restaurant’s menu is set up directly with Dohos so a caller hears accurate items, prices, and availability, and that is a separate step from however the same menu is already set up wherever sales get rung in. There is no automatic sync between the two — the same honest limit described above for point of sale, applied to menu data rather than a finished order.

What if I use a system that isn't listed here at all?

Nothing is listed here at all, deliberately. Name what you actually use when you get in touch — there is no promised timeline attached to a request like that, but it is a real request that reaches a real person.

TELL US WHAT YOU USE

A specific system name, mentioned once, tells a more useful story than six honest categories can on their own. It is information Dohos genuinely doesn’t have otherwise about what a restaurant considering the product already relies on day to day.

Saying so commits nothing on either side, and it isn’t a signal that something gets built to order. There is no queue with a published response time behind it.

RELATED PAGES

THE NEXT STEP

Start from what's actually real today.

Sign up or request access and run the phone line as it exists — one forwarded number in, one checked ticket out, and a person still deciding what gets rung up.