Daily report · Thursday 20 August 2026
Four teams worked at once again today. The four legal documents Ken sent are published, dated today, and every link is below. Inspectors can now block their own days off, and the jobs they take land on their own phone calendar. Josh will never guess at a price again — but when a job has a flat fee, he says it straight away. The robocall work went fully live on the phone. A server outage was traced back to a chat window. And the Josh on our website finally got the same ears as the Josh on the phone. Sixteen sets of changes went live here, and ten more from the voice team. And two things arrived tonight that outrank all of it: GC’s team scored thirty-six calls to Josh, and Ken settled the import window at twelve months.
The four documents are up. Two are the contract a subscriber signs. Two are the rules of the website itself. They are dated today, and the county for any legal dispute is now filled in — Lake County, Florida.
Inspectors can block their own time. A day off, a morning at the dentist, a holiday. Josh will not offer a blocked slot to anybody.
Their diary now reaches their own phone. They add one link once, and every job Josh books shows up in the calendar they already use.
Josh may end a robot call. Only a robot call. There is no button he can choose to press on a person, and that is built into the code, not asked of him politely.
And a price rule. No guesses, no “about $350”. But a flat-fee job gets its price the moment it is asked for.
Then GC’s test results arrived. Thirty-six calls, written up one by one. Eleven of them have Josh cutting out or going silent — the biggest thing on this page. The call records were pulled the same evening. They clear the phone bot and the memory crashes; two office-app restarts did land inside a live call, worth about two seconds of silence each, which is nowhere near eleven. Three more findings are Josh reading his card correctly and the card being wrong.
And Ken moved the import window from three months to twelve. Imported customers go straight into Engine 3 and are never texted, which is what makes twelve months safe.
Six pieces of work here, finished and live. Three more came from other teams.
Published where each one belongs, dated today, with the blank county filled in. The text message rules kept their own numbered section so they are easy to point at.
An inspector can now mark a day, a morning, or a whole week as unavailable. Josh stops offering it, on the phone and on the website, in the same minute.
One page. Two buttons the same size. Happy customers go to Google. Unhappy customers reach the inspector privately. Nobody is funnelled.
Ken ruled yes. It is built, tested, and Ken deployed it to the phone himself — in the same copy as the robocall work, without knowing it was in there.
Two halves. No number at all until Josh knows the house size — unless the job is a flat fee, and then he says it right away.
Jobs now reach the inspector’s own phone calendar. And Josh can sit inside a column on a page instead of floating over the words — which is what Ken asked for.
Two are the contract. Two are the website rules. All four are dated today.
Ken sent four documents and asked for them to go up. They are up. Here is what each one is, in plain words.
| Document | What it is |
|---|---|
| Subscription Agreement | The short front page a subscriber signs. It says who, what plan, and how much. |
| Service Terms | The long half. Fourteen sections plus two exhibits. It is part of the agreement above. |
| Terms of Service | The rules for using our website. Text messages are section 17. |
| Privacy Policy | What we collect, who sees it, how long we keep it. |
Three things had to be settled before they could go live.
The county. Both contracts had a blank where the county goes. That blank decides where a legal argument would be heard. We looked it up: the business address on the documents is in Lake County, Florida, so Lake County is what went in.
The date. Dil said today, so both version 6 documents read Effective August 20, 2026.
The text message section. It stayed, and it got clearer. We already send text messages — they are set up at the phone company and tested. The section now says exactly who we text and who we never text.
Ken asked for these four and only these four. So the old wording was taken out rather than parked on a second page. One page can be out of date. Two pages of the same contract is a fight nobody can win.
There is one exception, on purpose. The exact wording that is in force today is also saved at a permanent address, so a year from now we can prove what a subscriber agreed to. It is built from the same source file, so the two cannot drift apart.
An internal note of mine ended up printed on the Terms page, with stray star characters around it. It was on the one page where somebody is agreeing to something.
The cause was three small faults in the program that turns Ken’s files into web pages. It did not understand certain marks, so it printed them instead.
The fix that matters is the last one: the program now refuses to finish if a single mark is left over that it did not understand. That guard found two more faults within a minute of being switched on — including one in Exhibit B.
Found by Dil, looking at the live page. Fixed the same hour.
Two tick boxes sat one above the other on the sign-up page, saying almost the same sentence. One named the Subscription Agreement, the Service Terms and the Privacy Policy. The other named the first two.
They were not duplicates when they were built. One covered the rules of the website. The other covered the old Master Service Agreement. Those were different documents at different addresses. They turned into the same thing this morning, when Ken’s two documents replaced both — and nobody noticed, because each box had its own test and neither test counted the boxes on the page. One now does.
There is one tick now. The sentence comes from our own records, so the words on screen and the words we store are the same words. The Privacy Policy sits just under it as a line of its own, because a customer has to be able to reach every document before they tick — that is Ken’s rule and it is what makes the agreement hold.
When somebody agreed to receive texts, we saved a copy of the exact words they agreed to — that is the thing a phone company asks to see. It was saving the wrong paragraph. It picked the first consent box on the page, which was the contract one, so every text consent we hold was filed with the contract sentence instead of the text message wording.
Fixed, and it now names the box directly rather than counting from the top. The free tester page always had it right, which is how the difference showed up.
Two more changes to the same form, both asked for by Dil. “Company name” is now Company’s legal name, with a line saying why: it is the name that goes on the agreement. And your name is two boxes now, first and last. One box meant we split the name at the first space, so “Mary Anne Fletcher” was saved with the first name Mary and the last name Anne Fletcher — and every email after that greeted her as Mary.
Ken asked for it in the meeting. It is in the portal now.
Until today an inspector could see his week, but he could not close any of it. If he was at a wedding on Saturday, Josh would still cheerfully offer Saturday.
Now he opens the portal, picks a date and a time, and blocks it. A whole day, part of a day, or a stretch of days. He can add a reason for himself, and he can remove a block just as easily.
The important part is where the block is checked. It is not checked on the screen. It is checked in the same place both Joshes ask for open times — so the phone Josh and the website Josh both stop offering it at the same moment, with nothing to remember and nothing to sync.
There are two ways we work out free times. One asks the real calendar. The other works it out from the inspector’s normal hours when there is no calendar yet.
The block is applied to both. A rule that only covers one of two paths is worse than no rule, because it works right up until the day it quietly does not.
Ken was clear that he did not want a trap.
After a job is done, the customer gets an email asking how it went. That email now leads to a single page with two choices.
Both buttons are the same size, the same shape, and the same colour. One says the inspection went well and takes you straight to Google. The other says something was wrong and takes you to a private message that only the inspector reads.
A lot of review tools ask you to rate first, then send the happy people to Google and quietly hide everyone else. That is the thing Ken did not want, and it is also the thing Google has rules against. So we did not build it.
A reply to a public review goes out under Chad’s or Ted’s name, in public, and cannot be neatly taken back. We can write the draft. A person presses send.
Ken’s ruling, built the same day, live on the phone tonight.
Ken’s words: “Josh has our permission to hang up on a robot, but don’t hang up on a real person… hanging up on a real person could be $1,500.”
Back in July Josh had a general hang-up ability and it hung up on Dil and on a test call. It was removed. So the question was how to give him this one narrow power without giving the old problem back.
The answer is that Josh is not the one who decides. There is no hang-up button he can choose to press. It is not something he can do at all. The line is ended by the system, in exactly one place: the moment a call has already been filed as a robot call, after all of his own checks have finished.
That means there is no sentence a caller can say — however strange or robotic they sound — that reaches it. A person cannot talk their way into being hung up on.
He finishes his sentence first. The line waits about three and a half seconds, and it also checks that no sound has gone out in the last second. His “thanks, we’re not interested” is never cut off in the middle.
There is exactly one place this can be switched on, and a test that fails if a second one is ever added. A second one would quietly break the whole safety argument while everything still looked fine.
His instructions still never tell him he can hang up. He is told the line ends for him. That way he can never say “I’ll end the call here” to a real customer.
Off switch: one line in the phone’s settings file and a restart. No release needed.
Dil asked for it today. Building it turned up a fault that had been quietly running for eight days.
At the end of a booking call Josh asks one question: “is it alright if we text you about the inspection?” He says the answer back out loud, so it is on the recording, and then it goes on the record.
It now prints on the work order — on the note that lands in the CRM, and in the Inspector Portal beside the client’s name. There are three answers, not two:
| What it says | What it means |
|---|---|
| Yes — happy to be texted | They were asked and agreed |
| NO — do not text | They were asked and said no |
| Not asked on this call | Nobody asked. This is not a no |
The third one is printed, not left blank. A missing line looks like an old work order. “Not asked” is a fact the inspector can do something about. And it matters in a way that is worth being blunt about: we have no record and they told us no are two very different sentences if anyone ever asks.
Josh has asked this question on every booking since 12 August. On the phone, the answer was being dropped before it was saved. The part of the program that sends a booking to the CRM works from a list of fields, and this one was never added to the list.
So for eight days he asked, repeated the answer back for the recording, and nothing was written down. Every yes and — worse — every no was lost. The website version was never affected, because it sends the whole answer rather than a list.
Fixed. And the test now checks that every question Josh can answer actually gets sent, rather than checking for this one field, because the next one to go missing will be a different field.
A yes does not mean we text them. That rule has not changed — we do not text homeowners, and the only text this system sends is the booking alert to the inspector’s own mobile. So a yes is two useful things: the client’s permission on the record for the day that changes, and the inspector’s own answer to “can I text this client?” The portal says exactly that under the answer.
Four places. Every website booking ended with “you’ll get an email and text with your agreement”. And when Josh could not get an email address right after three tries, he was told to say “I’ll text you to confirm your email” — on the one call where the email is already broken, so the customer would have waited for a text that never came.
All four now say email, or “we’ll confirm it with you”, which is something a person can actually do. Josh is also now told plainly never to promise a text.
And something counts it. “Always” written in an instruction is a hope until something checks. Our call monitor now reads every booked call and flags the ones where the question was never put — and it stays quiet when he did ask, or when the answer was saved.
Ken gave the first half in writing and the second half in the meeting.
Half one. Josh does not give a starting price. Not a range, not “from $350”. Ken’s reason is about what the customer hears: “whether it’s $700 or $195, in that customer’s mind, that’s what it is.” So Josh says he will happily give the exact price, and asks for a few details first.
Half two, which Ken added in the meeting. Not every job is priced by house size. Phase inspections and new construction are a flat fee. For those, Josh quotes the number straight away and asks nothing.
A caller asked GC for a pre-drywall inspection. GC sells it for $425 flat. Josh refused to quote it, because he had been told to ask for the size first. The job was lost, and it took until 19 August to close properly.
So the rule is not “never quote”. The rule is work out which kind of job it is first, and the client’s own setup form is what tells him.
Both halves went into both of Josh’s brains — the phone one and the website one — because those are two separate files kept in step by hand, and a new test now fails if they ever disagree on this.
There is a size above which GC does not want a number given at all — Chad follows up with his own quote. That rule is in Josh’s setup, but only on one of the two price tables: the standard table stops at 5,500 sq ft, and the 5-Star table runs on to 7,000. So the same 6,200 sq ft house gets a quote or does not, depending on which package the caller named. Two of the thirty-six calls hit it. The section below has the detail.
Ken sent the results tonight. This is the best evidence we have ever had, and it changes what to fix first.
Chad’s team rang Josh thirty-six times and wrote a note on each call. Not our tests — theirs, on GC’s own line, playing the customers they actually get. It is worth reading in full. What follows is the count, because thirty-six notes have a shape that no single note has.
| What happened | How many of the 36 | Calls |
|---|---|---|
| Josh cut out, went silent, or said “sorry, I didn’t get that” | 11 | 1, 3, 5, 7, 8, 9, 14, 19, 23, 35, 36 |
| He never asked for the email address | 8 | 6, 8, 9, 12, 16, 18, 23, 33 |
| He could not get the phone number down | 6 | 3, 12, 17, 22, 27, 34 |
| He struggled with the street address or the ZIP | 5 | 7, 13, 19, 22, 31 |
| He offered a time that was already taken, or only one inspector a day | 3 | 30, 31, 32 |
| He never asked for the last name | 3 | 8, 16, 33 |
| He quoted a big house the team expected him to hand to Chad | 2 | 15, 21 |
| Came through with nothing at all noted against them | 6 | 2, 4, 24, 25, 26, 28 |
One call is worth quoting on its own, because it is the only one in the set where the customer gave up. Call 22: “Josh could never get the phone numbers correct (4 times)… I said I’ll call back. I called back. He couldn’t get the numbers correct again… I never finished the call because I was so frustrated.” On a real line that is a booking gone to whoever answers next.
The biggest single fault is not something Josh says. It is that he keeps disappearing. Eleven of thirty-six — nearly one call in three — carry a note about the line dropping, going quiet, stuttering, or Josh apologising for something he did not hear. Call 36 puts it plainly: “Josh went silent twice, and I had to ask are you still there… I’m sorry, I’m having problems with the line.”
This section first named the server as the leading suspect: the phone bot is pushed off memory onto the hard disk every time we release, we release thirteen to fifteen times a day, and being read back off a disk mid-call is what a caller hears as a gap. Reasonable, and wrong.
Dil asked for the call records, and then asked the sharper question: did our own restarts hit these calls? The tester is one number and it has rung Josh 47 times across three evenings. Three kinds of restart, three different answers:
The phone bot itself was never restarted during a session — not once, and the nearest was about eleven hours before the Tuesday calls began. Nor did the machine running out of memory touch them; the five that had happened by the 19th were 30 July, 7 and 11 August, and the phone had survived every one of them on luck.
But two office-app restarts did land inside a live call — and my first pass
said zero, which was wrong. It compared timestamps as text and six commits carry a
+08:00 offset. Redone properly: one on the 18th, 24 seconds before a call ended,
and one on the 19th about two thirds of the way through. That does not restart Josh; it
restarts the app he fetches the price list, the diary and the booking from, and since 7 August
those lookups retry rather than fail — about 1.9 seconds of extra silence, which a caller
hears as a pause.
It still cannot be the main cause. Two calls against eleven cut-outs, and the Saturday session — 22 of the 37 — had not one commit to main in a twenty-four hour window either side.
What the notes point at instead is Josh yielding, not Josh dropping. He stops while he is speaking and then apologises for it — “go ahead”, “I got it”, “I didn’t mean to interrupt you”. Those are the words of a program that believes the caller started talking. Two candidates are left, both inside the phone bot, and one command in the server’s log tells them apart — nine calls already have a verdict written and waiting.
The hosting upgrade is still the right call; the machine has died nine times since 30 July and the phone survived on luck. What has changed is that it cannot be sold as the fix for this.
⚠️ And the restarts did cost us something — just not on the line. Josh’s brain changed six times between the Saturday session and the Tuesday, and thirteen more between Tuesday and Wednesday. So the thirty-six notes do not describe one Josh; they describe at least two, and nothing in the file says which note belongs to which. A fault written down on Saturday may have been fixed by Tuesday. That is why “which nights are these?” is the one question that has to be answered before anything on the list gets built.
The full call-records investigation — the sessions, the numbers, and the three things to run →
Digits are still the second problem, and they cost money directly. Six calls on phone numbers, five on addresses and ZIPs. Three of them are worth reading twice:
Josh has a list of local words he is told to expect — Pearland, Kuykendahl, Bissonnet. Street names like NASA Road are not on it, and neither is anything that would help with a bare string of digits. That list is worth another pass with GC’s own service area in hand.
And then there is what he simply forgets. Eight calls with no email asked for, three with no last name. This is not a missing rule: his instructions call the buyer’s email mandatory, in capitals, with a whole ladder of what to do when it is hard to hear. So the question is not what to write. It is why an instruction that emphatic is being skipped on nearly a quarter of calls — and the honest first answer is that a call which has already cut out twice is a call where he loses his place.
1. The $972. Calls 15 and 21. GC’s team expected Josh to decline a quote on a 6,200 sq ft home and let Chad follow up. Josh quoted $972 — and $972 is exactly what his card says. His live setup stops the standard table at 5,500 sq ft (“over 5,500: do NOT quote — someone will reach out”) but runs the 5-Star table all the way to 7,000. So the cut-off disagrees with itself depending on which package the caller picked. Chad decides the number; then it goes in one place and covers both tables.
2. The pool at $75. Calls 20 and 32. His card says Pool / Spa is $75 added to an inspection, $250 on its own, and a pool inspection with leak detection is $147. He read it correctly, and on call 20 he even asked whether there was a leak, which is the right question. The team thinks $75 is wrong. That is Chad’s price to confirm, not a bug.
3. The new build question, which nobody ever wrote. Call 16 asks it directly: “Will customers have to tell Josh it’s a new build, or will the question be implemented? A lot of the time I have to ask the customer… They do not automatically tell me.” There is no instruction anywhere telling Josh to ask. Worse, he is told that the year a house was built does not change the price by a single dollar — true for a resale, and the reason he never brings it up. But new construction is a different product at a flat $425. A caller who does not volunteer “new build” gets quoted off the square-foot table for a job that is not priced that way. This is the pre-drywall fault again, seen from the other end.
GC’s prices exist in two places: a starter copy in our code, and the draft record from their own setup form. The record wins. A correction typed into the code is invisible to callers until it also reaches the record — which is precisely how the pre-drywall quote survived a fix for a week.
Every figure above was read off the live line tonight, not off the code, for that reason.
The diary answers are the other cluster worth acting on. Three calls (30, 31, 32) say the same two things: Josh offered one o’clock on a Tuesday that was already filled, and he offered only one inspector per day — “only Greg available on one day, and the next day it offered Chad available only.”
There are two candidate causes and they need telling apart before anything is changed.
Call 29: “One thing Josh never inquires about is a well/septic system, outside building, lawn irrigation after asking about a pool/spa.”
All three are on GC’s card — Well & Septic $50, Lawn Irrigation $25, Outbuilding $25. He handles them correctly when a caller raises one: on call 26 he added the outbuilding at $25 and totalled it properly. He just never offers. That is $100 of add-ons sitting in his own price list, on every call.
Realtor calls have a gap of their own. Call 18: “it only asked for the client’s name. He never asked for the realtor’s name and did not ask for an email.” Call 34: the realtor’s details did not come back when asked for. Call 29 shows the other side — the tester was pleased when he did ask. His instructions do tell him to take the agent’s name and number on an agent booking, so this is the same shape as the email: the rule exists and the call does not follow it.
The results arrived tonight. Three of the items above are Chad’s to rule on — the big-house cut-off, the pool price, and whether Josh should ask “new build or existing?” before quoting. The rest is ours.
And the ordering is not by count. It is: find out whether the cut-outs are the server, because eleven calls in thirty-six is bigger than everything below it, and because a call that keeps breaking is also the most likely reason he forgets the email.
A gap nobody had noticed, and it was not small.
Josh books a job. It lands in the Business Center. Until today, the inspector’s own calendar — the one on his phone, the one he actually looks at — knew nothing about it.
He does get a text alert, so he is not blind. But a calendar that says Thursday is free when it is not is worse than having no calendar, because he trusts it.
Now the portal gives him one link. He adds it to his phone once. Every job Josh books, and every block he sets, appears in the calendar he already uses. It keeps itself up to date.
One more thing worth saying. A booking with no time yet is not given a made-up time so the calendar looks tidy. It gets counted, and he sees a line saying how many are waiting. Putting a time nobody agreed to on a job he then drives to would be a much worse bug than an untidy month.
Ken: “my goal is for people to be able to read the website without that.”
Josh used to be a bubble in the corner. Open him and he covered the page. Ken did not like it, and Beth needed to know how much space to leave for him.
He can now be given a column and he will fill it. No bubble, no floating panel over the text, always open. The page says where he goes and how wide it is; he does the rest.
If the column is missing for any reason, he goes back to being the corner bubble instead of vanishing. A page that loads slowly still gets a working Josh.
The measurements document sent to Beth this morning said Josh could not be docked, and gave her three ways to work around it. That was true when it was written. It was built the same afternoon.
The corrected file needs re-sending. Otherwise she designs around a limit that no longer exists.
A standing rule from today. It will be in every daily report from now on.
The only text message this system sends is the booking alert to the inspector’s own mobile, plus alerts to ourselves. A homeowner hears from us by email — the confirmation, the reminders, the review request, all of it.
| Allowed | Never |
|---|---|
| A text to the inspector: new booking — Sarah, Tuesday 9am, 12 Oak St | A text to a home buyer, a seller, or an agent, for any reason |
Three reasons, and any one of them is enough.
One. Ken said it plainly: “our text is only for telling clients home inspectors that there’s a booking.”
Two. Our toll-free number is registered with the phone company for inspector booking alerts. A text to a homeowner is outside what we registered for. Ken put the cost at $1,500 in fines each time.
Three. We publish the promise. The website has a section headed “We do not text homeowners”, and section 17 of our Terms says “We text subscribers only. We do not send text messages to your customers.”
One of our files opened with the words “nothing here texts the customer, and nothing should” — and eighty lines later it carried a switch that would text the homeowner’s mobile.
It was switched off. Nothing was ever sent. But a switch sitting next to a rule is a switch somebody flips one day, having read the switch and not the rule.
It was deleted, not disabled. And there is now a test that lists every single file allowed to send a text message and names who receives it. A new one fails the test.
Putting it back would need three things in this order: Ken’s ruling, a way for homeowners to agree to it, and a change to our registration with the phone company. None of those three is code.
His words: “the question is, do we have permission to text the homeowner a request for review if they give it to us? The answer is, if they do, we’ll need to.” And on the other side of it: “if they say no, you can’t text me, that explicitly says no text of any type… the minute we text them, they have a potential lawsuit.”
The rule above has not changed and nothing has been built. It is written down here because it is the one place anybody will look for it, and because the reasoning has moved: Ken is not overruling the rule, he is pointing out that the first of the three things it asks for now exists.
Where the three things actually stand. A way for homeowners to agree — we have it since today. Josh asks every caller, says the answer back on the recording, and it prints on the work order with three states, including not asked. Ken had already described that as the defence: “this is why it’s important that Austin asks that every time, and that the recording and the transcript are attached to the work order, because we have a complete defence.” The other two have not moved: Ken’s ruling in writing, and a change to our registration with the phone company, which today declares inspector booking alerts only.
The registration is the hard one and it is not ours to decide. Consent from the homeowner does not widen what we told the carrier we send. That is a conversation with them before it is a line of code — and until it happens, a homeowner review request goes by email, exactly as the rule says.
One part is settled either way: an imported prior client is never texted, consent or no consent. Ken: “the text for a review request was already gone from the ISN.”
Asked because it matters for pricing. The answer is smaller than expected.
Every message a homeowner gets is an email. So the question was: what does that cost, and do we need another email company to send it?
No, and $1.62. We send through a service we already pay for. It charges about 67 cents for every thousand emails. One busy inspector generates roughly 2,400 emails a year — confirmations, reminders, review requests, the lot. That is $1.62 a year.
This takes email off the pricing worksheet. It is not a cost worth building a price around.
One correction to that, from tonight. We had also said there is no sending limit. There is — a daily ladder per client account, starting at a thousand a day. It is nowhere near what one inspector sends, but it is real, and the detail is in the meeting section below.
Appointments never reached anyone’s phone calendar. I had described that as something GoHighLevel was doing for us. It was not doing it. Nothing was. That is the gap the diary link above fills.
Payments were never on GoHighLevel either. They have always been somewhere else. The record should say so.
Ken asked what actually happens after a booking. Here is the honest answer.
Four messages go out today, and they all work.
| When | What happens |
|---|---|
| The moment it books | A text to the inspector’s own mobile |
| Straight after | A confirmation email to the customer |
| Day before, and 2 hours before | Two reminder emails |
| 3 hours after the job | The review request, then one follow-up two days later |
And here is the part that needed saying. Two of the four engines we sell are described as ongoing monthly contact with past customers and with agents. Neither of them exists yet. Nothing is sent to anybody after that review follow-up.
Ken was clear that we are not copying the sequence ISN uses. That was the right call, and it is not only about being different. ISN’s version is a conveyor belt: everybody who books gets the same twelve messages on the same days, no matter who they are.
Ken’s idea is a different shape. He talks about noticing when somebody has gone quiet. That is not a timetable. It is watching for a change and reacting to it.
Our own system already sorts every agent into groups — brand new, active, cooling off, gone quiet, and the best few. It puts them in a report nobody has to read.
The work is not the sorting. The sorting is done. The work is making something happen when somebody moves from one group to the next.
The single most valuable message we are not sending: the eleven-month reminder on a new-build home. The builder’s warranty runs out at twelve months. An email at eleven months saying “your warranty ends next month — want us to look before it does?” is a job the customer is grateful for. Nobody else is sending it.
The write-up has example emails in it for GC, so there is something real to read rather than a description of an email.
The other document covers what happens after a booking. This one covers how a new inspector gets set up in the first place.
Six steps. Three happen by themselves, three are us.
| Step | Who | How long |
|---|---|---|
| 1. Sign up and pay | the inspector | 2 minutes |
| 2. Fill in the setup questions | the inspector | 20 to 40 minutes |
| 3. Their own CRM account is made | automatic | seconds |
| 4. Their extras are set up | automatic | seconds |
| 5. Point their phone number at Josh | us | 10 minutes |
| 6. Give them a portal login, then mark them live | us | 5 minutes |
Step 2 carries all the weight, because that form is what Josh says to callers. The prices, the services, the hours, the service area, the mobile number the booking alert goes to, the follow-up email timings, the Google review link and the backup number all come out of it. There is no other source.
After they pay, the link to the form appears on one screen, once. No email carries it. Close that tab and the only way back is knowing the address.
There are no reminders either — no day 1, no day 3, no day 7. And there is no alert on our side: nothing says “signed up four days ago, form still half-done.” A stall stays invisible until a customer complains about something Josh said.
This is not a maybe. It is exactly why Chad has been live for weeks on a half-finished form, and it is what caused the pre-drywall quote that lost a job. With thirteen early adopters arriving at once, the same gap happens thirteen times.
What closes it is small. One welcome email with the link, sent the moment they pay. Three reminders — day 1, day 3, day 7 — that stop the second the form is submitted. And one alert to us when somebody has been sitting on a draft for three days.
Then one setting should be flipped. Right now a half-typed form still feeds Josh. That is correct today, because nobody ever told Chad or Ted the form existed and switching it off would drop their prices to a default. It is wrong the moment thirteen people are typing at their own pace, because a half-typed price list would reach their callers. The flip should happen the same day the reminders go out.
The messages in the other document are about noticing when somebody goes quiet over months. This one is a short chase with a finish line. It runs until the form is in and then it stops. Sending reminder four to somebody who finished on day two is how a system loses trust in one message.
Noted rather than fixed, because the fix needs the login.
Our testing service keeps failing Josh on Ted’s line. It has now done it four times. Each time somebody has gone and checked what Josh is told, and each time Josh is right.
There are two different screens and they are being confused. One holds what Josh knows. The other holds the marking scheme. Josh’s screen is correct for both clients. The marking scheme is the thing that is wrong.
The service says so in its own words: “the agent correctly stated that Saturdays are available, which violates the assertion’s requirement to decline weekends.” Read that twice. It agrees Josh was right and marks him down anyway. GC does not work Saturdays. Ted does. The rule that belongs to GC is being applied to Ted.
Three more marking rules are scoring the wrong thing. They grade whether the call ended in a booking — on test calls whose script says to hang up once a price is given. That is why one number on that screen reads 20% and the real result on the same run reads 3 out of 10. The headline number is noise.
When a test fails, ask which of two things is wrong before changing anything: what Josh knows, or what the test expects. Changing Josh to satisfy a wrong test would have meant telling Ted’s Saturday customers he is closed.
The rulings from this evening. The first one changes a number we have been telling clients for months.
Twelve months of history come in, not three. Beth has been telling new clients to bring the last three to six months of customers and agents, and Chad pushed back on it this week. Ken’s ruling: “3 months is too restrictive if we’re not texting… 12 months agents, 12 months clients.”
The reasoning is worth keeping, because it is the whole of our risk model in two sentences. An email to somebody who has forgotten you earns an unsubscribe or a spam mark. A text to somebody who never agreed to one is a fine. So the limit that matters is on texting, and an imported list is never texted.
| Who | What they get | Why |
|---|---|---|
| Booked by Josh, job finished | Engine 1, review request included | They were asked on the call and the answer is on the recording |
| Imported from their old system | Straight into Engine 3. No review request at all. | Their old system already asked. Asking again is a second bite at a review they have already given or refused |
Mechanically it is two tags on the way in — prior client and Engine 3 — and Engine 1 is skipped entirely. Ken: “they would just drop immediately into that Engine 3 sequence.” Nothing about this can be built until the Engine 3 content exists, which is still the item waiting on Ken’s words rather than on engineering.
They hand us the list. They do not upload it. Ken: “definitely not letting them upload… otherwise they’d upload four years.” And the list has to carry first name, last name and the date of the inspection — the date is what proves the twelve-month window if anyone ever asks. Beth’s point stands: a list handed over casually is often just a first name and an email, so this has to be asked for plainly.
Every list gets cleaned before it lands. We already pay for a verifier and it is pay-as-you-go — Beth remembers around $17 for a batch, which needs confirming. Ken wants one with an interface we can call, so the cleaning happens on the way in rather than as somebody’s manual job.
A hard bounce already stops that address by itself. What is missing is the other half: when a client’s spam complaints or unsubscribes cross a line, Booked Solid gets told — not just the client.
Ken’s words: “if their spam level or their unsubscribe level reaches a certain amount, then we need to be notified… so that we can have that discussion with the customer.” One client’s bad list damages the sending reputation every other client shares. Nobody has set the number yet.
Email stays where it is. Two things settled it. GoHighLevel no longer sends through Mailgun — they run their own sending now — so “move to Mailgun” is not the upgrade it sounds like. And Ken’s test is the right one: “if our cost of moving off exceeds what we were paying, that doesn’t make any sense.” Nothing about email justifies the move on its own.
The earlier note said there is no limit. That answered the billing question and reads as though nothing caps sending. It does.
Each sub-account climbs a ladder: 1,000 emails a day at the bottom, up to 15,000 as it proves itself, and it slides back down on a bounce or spam spike. It resets at midnight UTC.
And the scale is the actual answer. One busy inspector sends about seven emails a day, against a first-day ceiling of a thousand. Each client has their own sub-account, so thirteen testers are thirteen separate ladders, not one shared one. The cap is real and it is nowhere near us.
The one place it bites is a bulk send — a first newsletter to a freshly imported twelve months. Ken already described the answer without being asked: send the first month, then the second, then the third.
Three more things on the sign-up form. The duplicate tick box is gone and the company field already says Company’s legal name. Ken added:
Ken asked that this item not be closed off: “I would put questions pending. I wouldn’t let that get closed out. Till we get those, we can’t move forward.”
Blocking time needs two changes, and one of them is where it lives. What was built today works, and Ken found both edges of it in about four minutes on screen.
Open slots stay hidden. Ken worked through it out loud and landed on our side: thirteen inspectors times three start times is a phone calendar nobody can read. “Displaying only the slots that are taken is a smart move.”
And blocking a slot to hold it for an agent is a selling point, not a feature. Ted lost a job because ACC would not hold a slot an agent had asked him to keep. Ken: “that immediately makes us better than ACC… Josh can’t do it, but you.” It is the same button, described as the thing it fixes.
And one sentence on the diary page to rewrite. Ken read it out twice and could not parse it: “if any booking still needs one, the calendar says so… I’m not sure what that means. The first part of the sentence is clear. It’s after the hyphen.” It means a job with no time agreed yet is counted rather than given a made-up slot. It should say that.
1. What do the AI agents actually do once the workflows run in GoHighLevel? Today they do the Home Inspector Help work by hand. When those services become accelerants inside Booked Solid and the sequences run in the CRM, the answer is genuinely unclear. It matters immediately, because it decides the second question.
2. Does Josh need his own machine? Ken’s framing: “my goal was to have the voice just on Rose Hosting. Now what we have is all this other stuff on Rose Hosting competing.” If agent work grows, the phone gets moved. If it shrinks, it does not. Note that GC’s eleven cut-out calls make this a live question rather than a planning one.
A third is on the same thread: if the CRM ever moves off GoHighLevel and onto our own server, 120 GB of disk at 500 to 1,000 clients needs sizing before, not after.
The workflows go on a chart next. Ken wants the sequences drawn out — what goes out in which month, where the words come from for an agent versus a customer, and whether a client in Nashville gets something about the Nashville market. And to be clear about a misunderstanding from the meeting: we are not integrating Echo Desk. We modelled our own on it. Ken: “we created our own from Echo Desk.”
Built the same evening, because a map that disagrees with the endpoint is worse than no map.
Dil said he still had to “integrate the Echo Desk, the modules”, and Ken stopped it: “we don’t want to do the Echo Desk. We created our own from Echo Desk.” That went into the log and that is where it stopped, which made it read as forget Echo Desk.
He asked for something Echo-Desk-shaped in the same meeting: “like EchoDesk had that nice layout of the procedures for Sean Bacon. We need to get our procedures laid out on a Whimsical form. So that you and I can sit down and say, okay, this works, this works, here’s what the content looks like, here’s the topics.”
So the position is their layout, our content, no integration. We copy the idea that a procedure is something you can point at and argue with. We copy none of their sequences, timing or words — that would be the ISN conveyor belt under a different name.
And his four questions are the specification for that map. Not a summary of it — the actual list of what has to be on the page before anything gets built:
Plus one he asked separately that nobody has ruled on: should a client in Nashville get agent content about the Nashville market? We know it can be done. Nobody has decided whether it should be. Ken on all of it: “those things have to be worked out by us” — it is a sitting-down job for him and Dil before it is a build.
Our own map says a flow change is a code change first and a copy change second. So it was both.
Writing “twelve months” into a document while the endpoint still enforced three would have been the exact drift this repo has a rule against. So the ruling went into the code, the tests, the flow map and the copy in one go.
| Where | What changed |
|---|---|
| The endpoint | Both windows are 12 months. Kept as two settings even though they are equal, so splitting them again is one line |
| The tags | An imported client now carries Engine 3, alongside Prior Client and Imported |
| The tests | 23 → 28, all passing. Exactly one test knows the literal numbers, so moving the rule again is one place |
| The flow map | Section ⑩ rewritten — the window, the reasoning, the required fields, the cleaning |
| Parker and James | Both were still saying three months out loud. Both fixed |
The Engine 3 tag is a route, not a block. Nothing today could send an imported contact a review request even without it — that message fires off a completed job, and an imported row has no job. The tag is the hook Engine 3 will read when Engine 3 exists. Calling it a safeguard would be claiming a guard we did not build.
The agent half is not ruled, and it is not assumed. Ken named Engine 3 for prior clients and said nothing about where a prior agent starts. Engine 2 is the obvious parallel, which is exactly why it is not written — a test now fails if somebody adds it quietly, so the question reaches Ken instead of being answered for him.
Parker’s brief told him to say “only the last THREE MONTHS” and never to say six or twelve. James taught the same thing. Neither had ever been updated for the 17 August split, so both were already wrong before tonight.
They now say twelve, and both carry the line that makes twelve safe rather than reckless: nobody we import is ever texted. A prospect nervous about his list being spammed is asking about texting whether he says so or not.
Ten published pages still say three months — the four engine pages, the newsletter page, the Booked Solid homepage, the “what changed” page and its search index, the setup form and the risk report.
Those are marketing claims, and the wording is not mine to rewrite. The exact file list is in the flow map and in the decisions log, so it is a short job the moment somebody says go. The dated three-month-import report stays as written — it is the record of what was true that day.
His second question tonight: “my Claude code is not up to date on all the changes we have made… what can we do about this?”
The answer is that it is not out of date by accident, and it is not a settings problem. The chat Ken uses to think out loud cannot see this repository. Everything the rest of us treat as memory — the business file that loads on every session, the decisions log, the map of the flows, the handover — are files here. His chat has never read one of them.
So his instinct in the meeting was right, and worth saying back to him plainly. He described his own process: think it through in the chat, hand the result to the one that builds. That is the correct division and nothing about it needs changing. The only weak link is the hand-off itself, which today is Ken remembering what has changed and typing it out.
Paste. Open the catch-up page below, copy the whole thing, and drop it in as the first message of any new chat. Then ask the question. It costs one paste and the chat starts from where the business actually is rather than from where it was in July.
It is also the answer to a second problem he has been living with. A long chat gets slower and more expensive with every message, because the whole history goes back each time — and it is what took the server down twice this month. A fresh chat per task, started with the paste, is faster and safer than one long one.
The page exists as of tonight: bookedsolidinspector.com/reports/catch-up.html. One page, in plain English, with a button that copies the lot. It carries the things a chat gets wrong when it has not been told: that there are two real clients and nobody else, that no price is published and none should be quoted, that we are English-only today, that we do not text homeowners, which of the four engines exist and which two do not, and where each of the three agents actually runs.
A page like this is wrong the day after it is written unless something keeps it right. So it is not a new document with its own facts in it — it is built from the files that already have to be correct for anything else to work, and it gets its date bumped with each daily report.
Ken has been given wrong answers by his own chat for months, from documents in here that said three clients when there were two, and quoted prices that were retired. A briefing page that goes stale would do exactly that again, more efficiently.
Three teams worked at the same time. These are their reports, shortened, with the links.
Started 19 August. Live on the phone on 20 August.
Ken and Dil asked for one thing: “handle robo calls — we need to add this so Josh will know that it’s not a booking.” A robocall is a call from a machine playing a recording. The common one says your business listing is about to expire.
Before this, Josh only knew two kinds of call — somebody booking, and somebody leaving a message. A robot is neither. So he either tried to sell a home inspection to a recording, or he took a message that a busy man then had to read.
Josh now knows the signs. It talks over him. It never answers his questions. It offers a menu. The call opens with a click or a beep. It wants to confirm something about the business instead of booking. Two or more of those and he is talking to a machine.
And if he is not sure, the caller is a person. A real customer can sound like a machine — nervous, on a bad line, reading off a sheet. He asks one plain question: “Sorry, are you calling to book an inspection?” A person answers that.
The listing scam works by getting somebody to confirm the business name and address, and recording the yes. An invoice arrives later, and the recording is held up as proof.
Josh is now the person who answers the phone. He is recorded, and he is built to be agreeable. So the rule is not be careful. The rule is confirm nothing — not the name, not the address, not the hours, not even a plain yes. He presses no buttons either, because pressing one proves a real person answers this number.
Getting it live took two halves. The office half went out with the automatic release. The phone half does not release itself — Ken copied it to the server by hand and checked it six ways, because on 18 August a textbook copy quietly moved the old file and a whole test run was wasted on code that was not there.
Robot calls are counted, never shown. They are saved, but they never reach the inspector’s message list. He sees a number instead: Josh took 40 junk calls off you this month.
Merged as commit 237cddc. Ten files, about 780 lines. The hang-up built in this session went out in the very same copy, so Ken deployed it without knowing it was in there.
One question about a slow website turned into a full outage report.
Dil asked why the website felt slow. It was not slow. It was down — both the Booked Solid site and the Q dashboard at the same time. Two minutes later it came back on its own, with nobody touching it. Two different sites failing together means the problem is the machine, not the sites.
The exact moment is in the server’s own records: Wednesday 19 August at 8:51:45 PM, the machine ran out of memory and killed the biggest program on it.
Our server is one small computer with about 1.9 GB of memory. When Linux runs out, it does not slow down politely — it picks the biggest program and kills it. This time the chain reaction took down the program that keeps everything running, and all six apps died with it, including the phone bot.
The server had 1.35 GB free. The program wanted 1.45 GB. That gap took down everything.
And it was not the first time. It has happened nine times since 30 July. Every single time it was a Claude session that had grown large.
Nobody did anything wrong. Beth was using a chat box in a web browser. Behind that chat box, the dashboard was starting a real program on the server using a gigabyte and a half. There was no gauge, no limit, and no warning anywhere. In the meeting Ken and Dil worked out the cause in three minutes; the software never hinted at it in weeks.
What was fixed. The emergency memory went from 1 GB to 4 GB, which cost nothing. An abandoned session that had been running for six days was closed. A memory monitor now writes down what is happening every five minutes — it only watches, it never restarts anything, because something that restarts things could take the phone line down at 2 AM.
And the cause was fixed in the software. Both dashboards were packing the whole conversation into every message, so each message was bigger than the last. Both now have a memory ceiling, a one-message-at-a-time rule, a trimmed history that never cuts the newest message, and cleanup when you close the tab.
Start a new chat for each task. Do not keep one long conversation going.
A long chat is not just risky, it is slower and costs more on every message, because the whole history is sent again each time. If a chat starts hanging: stop, and start a new one. That is exactly what fixed it on the 19th.
The website felt slow for a separate reason, and that is fixed too. The site was telling browsers not to save anything, so every click re-downloaded the same seven files. Pictures are now kept for a week and scripts for an hour. Pages are still checked every time on purpose — when Ken or Beth changes wording, it has to show up straight away. The site now loads in 0.18 seconds.
Everything above is a seatbelt. It does not make the machine bigger. The hosting company quoted two options: 4 GB at $64.99 a month, or 8 GB at $89.99 a month. The data stays, the address stays, and it needs one restart.
The recommendation is 8 GB. On 4 GB only one person can run a Claude session at a time. There are six project folders on that machine, so more than one person clearly works at once. There is also new evidence: the phone bot gets pushed off memory onto the hard disk every time we release, and we release 13 to 15 times a day. For a phone system, the first two seconds of a call are the whole product.
Dean is the app whose chat session actually crashed the server. It was the only one still unprotected.
Three apps could have caused that outage. Two have been fixed and Dean is the one that actually did it. The session the machine killed at 8:51:45 that night was Dean’s, not the dashboard Beth was typing into — that one was a victim.
The memory handover for Beth’s dashboard was sent this morning and the work on that side is done. Dean now has its own, and Dil passed it on this evening. Dean lives in a different place that we cannot reach from here, so it is a document rather than a change we can make ourselves — but it is now in the hands of whoever works on it.
What is in it: the minute-by-minute record of the crash, the proof that it was Dean’s session, what has already been done to the server so nobody redoes it, the six things to build ranked by how much damage each one prevents, and the numbers that work.
Two more apps want the same guard. Our Q has it and it is live. Dean, Arlo and Max do not. They are all on the same small machine, and any one of them can still do what Dean did on Wednesday night.
And somebody should prove the ceiling is really switched on. A passing test is not proof: our tests run where there is no such thing as a kernel limit, so they can only check the softer half. One command on the server checks the real one, it is safe to run live, and it prints a plain yes or no.
The team that protected Beth’s dashboard read it and found one of their own numbers wrong. They had set the cut-off at 1,400 MB. Six of the nine times this server died, the program was bigger than that — so a 1,400 cut-off would stop six chats that used to finish perfectly well.
The reason the old number looked right is worth keeping: it was the right number for the machine before we added the extra memory. Now that the machine can absorb 1.7 GB, the cut-off’s job is to stop a runaway, not to stay under the old cliff. Their words: “the other Claude’s 1600 is the better number, and I agree with the correction.”
It is three lines in a settings file and a restart — no release. That is the whole reason every limit was built as a setting rather than written into the code: a release restarts everything, which is its own small outage.
Their guard stops a chat that is growing. It does not stop a chat that is alive, small, and going nowhere — “Claude is a minute and a half, and it isn’t doing anything.” That is the exact thing Beth reported, and it still spins forever.
The fix is a time limit: after five minutes the answer ends with a sentence instead of a spinner. They have offered to build it. It is worth saying yes.
Six traps are written down, because each one was paid for once already. The worst is this: the obvious setting for “warn me at this size” does not warn. It slows the program down instead. Set it where you think it belongs and the program never reaches the limit that would stop it — it just sits there, alive and crawling.
That is worse than no protection at all. It turns “stopped with a clear message” into “hangs forever” — which is the exact thing Beth reported in the first place.
Two other traps are the kind that ship and look fine: one popular fix is quietly ignored altogether, and a second only measures the small wrapper program rather than the huge one underneath it, so it reports a comfortable zero while a gigabyte and a half sits one level down.
Ten changes, all live. Dil found four problems and every one was real.
Dil tested Josh on the website and reported four things in his own words: “he sound gibberish, specially when he is repeating a number”, “why does he cannot listen well”, “we need a manual tap for mic”, and “he is so delayed.”
All four were real, and three of them were things the phone Josh fixed weeks ago that the website Josh never got. Nobody had ever compared the two.
| Problem | Now |
|---|---|
| Numbers read as quantities — $450 became “4 and $50” | Spoken as words, using the same filter the phone has had since 28 July |
| Cut you off in the middle of a phone number | Waits 1.5 seconds, and 4 seconds after a number. A pause inside a number is punctuation, not the end of your turn |
| Heard himself through the laptop speakers and answered it | Two guards: the mic waits, and anything that repeats what he just said is thrown away |
| 4.3 seconds of silence before he spoke | 1.5 seconds. He says the first sentence while still writing the rest |
| A wobble where the audio pieces joined | Each piece is now told what came before it, so it sounds like a continuation |
| “Tap to talk” explained the wrong button | The button says what it is, and a separate line says what to do next |
| Nothing was written down, so faults were fixed by guessing | A copyable timeline of the call, and a line in the server log for every piece of audio |
The big one was his hearing. Everything above is about his mouth. On the phone, Josh listens through a paid service that lets us hand it a list of words to expect — like Pearland, the town GC works in. On the website he was using the browser’s own free listener, which cannot take word hints at all.
| What the caller said | Without hints | With hints |
|---|---|---|
| 1827 Willow Bend | “187 Willow Bend” | 1827 correct |
| 3,200 sq ft | “three d 200” | 3,200 correct |
| lockbox 4217 | “four to 21 up and seen” | 4217 correct |
Those are house numbers, sizes and lockbox codes — exactly the things a booking depends on. Web Josh now hears through the same service, with the same 25 word hints, from the same list. Add a town for a new client and both the phone and the website learn it at the same moment. As a bonus, Safari and Firefox have voice for the first time.
The first attempt looked at the wrong setting. The second could not find the password, which was hidden somewhere no script thought to look. The third said “success” when it was not true. The fourth found the real fault: the web server was answering the microphone connection with the marketing homepage.
And because Josh falls back to the free listener whenever anything fails, nothing looked broken and nothing was better. That is the worst shape a problem can have.
The check now opens a real connection from outside and refuses to claim success otherwise.
It costs money now. The browser listener was free; this one charges by the minute, on a public page. So there are hard limits: 5 minutes per microphone session, it closes after 30 seconds of silence, 12 sessions at once across the whole server and 3 per person. Every session writes down how many seconds it used, so a surprising bill can be explained. Turning it off takes under a minute.
The four new documents are at the top. All checked while this was written.
Nothing here is waiting on engineering.
Ken or Dil — five rulings
Chad — three answers only he has
Waiting on people, not on work — eleven