DSmartWare

Specialty

Most restaurant sites are a brochure.

Someone looks, decides, and leaves — and the restaurant never finds out they were there. We build the version that keeps a record, and a panel that says exactly where each number ends.

The three leaks

Three moments where an interested guest leaves without a trace

Each one is a specific hole, and a contact form closes none of them.

The party of thirty

Lost today

A group of thirty can't use the reservation widget — it stops at eight or ten. The request becomes a phone call nobody writes down, or it goes to the restaurant next door.

Recorded

The request arrives recorded, with the date and the head count, and the alert goes out immediately. It's the highest-value booking a restaurant gets, and whoever answers first usually wins it.

The night with no table

Lost today

Someone had already decided to come, already picked the night, found no time slot, and closed the tab. A failed search never becomes a reservation and never shows up in any report.

Recorded

The nights the house couldn't seat are on the record. Added up, that's demand nobody else is counting — the number behind opening a second seating, adding a table, or moving closing time.

The guest who wanted to hear from you

Lost today

Someone liked the place enough to want news from it, and the restaurant has no way to reach anybody.

Recorded

Name, contact and birthday, with consent stored alongside the date and where it came from. It's the one thing on the site that grows on its own and doesn't leave with a supplier.

What the guest sees

Pages that answer before the phone has to

A restaurant site has a small number of jobs, and a PDF does most of them badly.

Menus in HTML, never PDF

Food, wine and cocktails are structured text with prices on the page. Search engines read it, screen readers read it, and nobody on a phone has to pinch-zoom a document built for paper.

Marked up as a restaurant

schema.org Restaurant and Menu data on the structured content — that is what lets Google show a rich result instead of a bare blue link.

Bilingual, checked every build

Each language is planned into the site's architecture, not translated on top afterwards. A script compares the keys on every build, so no page ships half-translated.

Booking where guests already book

The reservation widget the house already uses stays embedded. What it can't take — the large party, the full night — becomes a form instead of becoming nothing.

Answers drawn from the real menu

Questions about dishes and wines are answered from the house's own data, with pairings suggested and the guest pointed to the booking page, always in the language of the page they are on.

What the owner sees

One screen, in the order the questions actually arrive

First what needs a person today, then how the house is doing, then the evidence behind both.

Now

What's waiting on someone: requests with no reply yet, this month's birthdays, the guests the widget couldn't seat. The manager marks what has been answered — which is how the panel can say how many requests were closed and how fast, not just how many arrived.

How the house is doing

The Google rating with its own history, the size of the guest list, the month's traffic, and what those visits turned into.

The evidence

Where visitors came from, what they asked about, which dishes came up, and what time of day they arrive.

A rating with history is the part nobody else hands over

Google shows today's score and doesn't keep yesterday's. We keep one snapshot a day, so you can see whether the rating is climbing or slipping and since when. And because the source covers any public place, the same chart follows the competitors down the street — and the owner's other houses — without asking anyone for access.

Four restaurants, one panel

An owner with several houses sees all of them behind one selector. Adding a restaurant is a row in the database, not a second project.

Limits

What we don't do, and why

These are things a panel could show and ours doesn't. Each one would cost more trust than it buys.

Put a money figure on the panel
The POS holds the revenue. A number here that the restaurant's own reports can contradict is worth less than no number at all.
Say "reservations"
We say "84 went through to the booking system". The booking system has the real reservation count — ours would be the wrong one.
Store what guests asked
Only the topic is kept. Privacy settled at the source, not by a written policy.
Promise more bookings by X%
We don't measure a completed reservation, so we can't claim a percentage of one. Anyone quoting that figure is estimating.
Fill a gap with a guess
When a source is missing the section disappears and a notice names what's absent. An empty panel is honest; an invented number isn't.
Measured, not promised

We're not asking you to take our word for it

This page is built to the standard described above. The scores are its own, measured with Google Lighthouse — the audit anyone can run.

See how we measure
92
out of 100
Performance
100
out of 100
Accessibility
100
out of 100
Best Practices
100
out of 100
SEO

We publish the lowest score measured across every page, not the best one. Measured on August 21, 2026.

Want to see this on your restaurant?