Automation activity
Week of Mon 13 to Sun 19 July 2026
This week your automations handled 60 things across your four connected tools. 55 went through cleanly, 4 needed a human eye and were sorted out, and 1 is waiting on you: a deposit that could not be matched to a project.
Every enquiry from your website or Facebook form becomes a contact and a deal in HubSpot, and your estimators get a Slack ping.
Captured 22 enquiries. 20 were new people. 2 were repeat enquiries from people already in HubSpot, so they were added to the existing record instead of creating a second one.
Nothing needed a person.
An AI model reads each new enquiry and sets the project type, a rough budget band, how urgent it looks, and which estimator it should go to.
Read all 22 enquiries. 19 were confident enough to route on their own. 3 did not give the AI enough to go on, so it flagged them for a person rather than guessing. Every decision it made, and the reason behind it, is listed in the next section.
The 3 it flagged are the flow working as intended, not errors. All 3 were replied to and routed by the end of the week.
When a quote has been sitting without a reply, this sends a friendly nudge on day 3 and again on day 7.
Sent 9 follow-ups. 2 were skipped because the client had already replied, so no unnecessary nudge went out.
1 follow-up bounced and was flagged for a person. It was resent to an alternate address on Tuesday.
When a deposit is paid, this sends a thank-you and a review request, and marks the deal as Won.
Processed 5 deposits. Sent 5 thank-yous and 5 review requests, and marked 5 deals Won.
1 more deposit came in that could not be matched to a deal. It is held for you, in the Needs your attention section below.
This is the part that is usually hardest to explain. The AI step made a call on each enquiry, and here is exactly what it decided and why. Where it was not sure enough, it says so and left the enquiry for a person.
“We are gutting our kitchen, hoping to start before the holidays. Budget is around 40 to 60k. Can someone come out and measure?”
“Looking to update the tile in our guest bathroom, nothing major.”
“Do you do commercial work? We manage three restaurants.”
“Following up on the quote from last month for the primary bath, we are ready to move.”
“hi price?”
The confidence bar is set to 70%. Anything below that is left for a person instead of routed, which is how “hi price?” ended up flagged rather than sent to the wrong estimator.
The same week, laid out in one place across all four tools. This is the view that answers what happened and when, without you having to open four different dashboards.
On Saturday a deposit was paid by a customer who is not in HubSpot yet, for what looks like a kitchen job. The automation held it instead of guessing which deal it belongs to.
Why it happened The Stripe payment did not carry a deal reference it could match on, and the paying email was not on any open deal. Rather than attach the payment to the wrong project, it parked it for you.
What to do Tell it which deal this belongs to, and it will finish sending the thank-you and marking the deal Won.
The day-3 nudge for one contact bounced back. The automation caught it and flagged it, rather than quietly recording it as sent.
Why it happened Gmail returned a hard bounce, so the message was recorded as not delivered.
Outcome Already handled. It was resent to the contact's alternate address on Tuesday and went through.
Three short messages, like hi price?, did not say enough for the AI to pick a project type, so it flagged them for a person instead of guessing.
Why it happened Each one scored below the 70% confidence bar. This is the triage working the way it is meant to, not a failure.
Outcome Already handled. All three were replied to and routed by the end of the week.
This part is for you, not the client. The report is not a mockup. It is built from the real execution data your scenarios already produce, plus the recent events in the connected tools. Here is one run, as Make records it, and the plain line it turns into.
One run, as Make records it
{
"id": 30184417726042,
"scenarioId": 4821771,
"status": 1,
"operations": 7,
"transfer": 4213,
"duration": 1840,
"type": "auto",
"executedAt": "2026-07-13T09:12:04.510Z"
}
status 1 is a clean run, 3 is an error. operations is what it costs, transfer is bytes moved, duration is in milliseconds. This is exactly what GET /scenarios/{id}/executions returns.
The AI step in that run
{
"module": "anthropic-claude:CreateChatCompletion",
"status": "ok",
"operations": 1,
"output": {
"project_type": "Full kitchen remodel",
"budget_band": "40-60k",
"urgency": "high",
"route": "senior_estimator",
"confidence": 0.93,
"reason": "Whole-kitchen gut, firm budget range, and a request for a site measurement are strong-intent signals; pre-holiday start set urgency high."
}
}
Because your AI step returns a structured result with a reason and a confidence, the report can show the client the why in plain English. Nothing new is asked of the model, it just surfaces what it already returned in the run.
The waiting item, as a held run
{
"id": 30184901120067,
"scenarioId": 4821791,
"status": 3,
"reason": "No matching HubSpot deal for the paid Stripe session; parked as an incomplete execution rather than guessing.",
"storedAt": "2026-07-18T11:05:39.220Z"
}
With store incomplete executions turned on, a run like this is held and is readable and resumable through the API. That is what becomes the one waiting-on-you item, instead of a silent gap.
The line it becomes
How this would run for real, without touching your existing scenarios: