The normal way, and what it costs you
The standard build is to embed a chat vendor's script. It is fast, it is cheap on day one, and it means every message a visitor types is transmitted to a third company, stored on their infrastructure, and governed by their terms rather than yours. You pay monthly, forever, per seat or per conversation. When you stop paying, the widget stops and the history goes with it.
For most businesses that trade is fine. For a business whose visitors type things they would not want a stranger holding — a medical detail, a family situation, a financial one — the trade is worse than it looks, and the vendor's own published terms are where you find that out. Worth reading before you sign rather than after.
What runs where
The intake assistant is a small piece of first-party code on your page, plus an endpoint inside your Google Workspace. The page collects the answers and posts them to a Google Apps Script deployed under your own Workspace account. The script writes the row to your Sheet, sends the notification from your domain to the inboxes you chose, and returns the confirmation.
The only company in that sentence is one you already chose: Google, under your own Workspace agreement, exactly as it already carries your mail. No chat vendor is added to the path, and neither am I. The software is licensed to you, and no code path in it sends a submission, or a copy of one, anywhere but the Workspace account it was built for — including to me. That is a property of the code, and it is the kind of claim a test can be pointed at.
What happens when somebody submits
The submission is validated before anything is written, so a malformed or hostile payload is rejected rather than stored. It is checked against recent submissions, so a visitor who double-taps is told the message already arrived instead of generating a second one — and that check keys on the full text and its length, because two long messages that merely start the same way are not the same message. It is written to the Sheet first and mailed second, so a mail failure cannot silently lose the record. The visitor sees a confirmation describing what actually happened, not a generic thank-you that is true whether or not anything worked.
The hours logic, which is most of the value
The assistant knows your staffed hours in your timezone, including the transition days that break naive implementations. Inside those hours it says a person will reply. Outside them it says something different and correct.
That distinction sounds small and is the entire point. A confirmation reading "thanks — you'll hear back shortly" sent at eleven on a Saturday night is a lie your software told on your behalf, and the person finds out it was a lie on Monday. Worse, a relative word decays: "nobody is reading messages until tomorrow at 8 a.m." is written Sunday night and read Monday morning, when "tomorrow" now means Tuesday — so the reader is told to expect nothing for another day at the exact moment her message is on somebody's screen. Every sentence that outlives the instant it was written carries an absolute day instead, and past six days out, a date.
What it deliberately does not do
It does not answer questions. It routes to people. An assistant that composes answers is a different product with a different risk profile: it can be confidently wrong, in your voice, on your domain, to somebody about to spend money. If you want that, it is a real conversation to have, and it starts with what happens the first time it is wrong.
It also does not offer a phone number after hours when nobody is at the phone. Sending someone to a voicemail nobody will hear before Monday is not a fallback; it is a second dead end.
How it is tested
Over a thousand automated checks, counted by the test gate itself rather than by a number typed onto a web page. Every fix is proven by sabotage: the fix is reverted on a throwaway copy and the suite has to go red naming that exact failure. A check that has never been shown capable of failing is not evidence — it is decoration, and a green suite full of decoration is worse than no suite, because it produces confidence instead of information.
The checks run against pinned instants on both sides of every open-and-closed boundary, so the behaviour at 7:59, 8:00 and 8:01 is asserted rather than assumed. That regime is also what caught two faults in the test harness itself. On a weekday between 8 a.m. and 8 p.m. Eastern, one suite aborted before it executed a single check and wrote no verdict at all; the other reported a failure that was not real, and went green again after hours. Neither was a fault in the software being tested. Both would have been invisible to a suite that ran whenever the tests happened to run, and both would eventually have waved a real failure through.
What tests cannot tell you
They prove the logic. Not one of them proves a deployment. So every build ships with a runbook naming the checks a person has to perform by opening a real inbox and looking — including whether the notification landed in spam, which is the one failure a delivery check structurally cannot see, because a message filed in spam at the destination was delivered.
Ladus AI Development, LLC is not a law firm, does not provide legal services, and no client-lawyer relationship or its protections arise from anything here.