Evidence record: client intake on Tally, Make, HubSpot Free and Brevo (v1)
This page is the run record for the evidence pack named below. It lists what we tested, when, what we observed case by case, and what we did not test. It is generated from the pack file in our repository, so it cannot quietly drift from the source. Identifiers that would expose our accounts (record ids, run ids, message ids, addresses) are left out on purpose; the underlying files are available on request.
The question this pack answers
Does a free-tier client-intake chain (form to CRM contact and deal to acknowledgement email) actually work end to end for a solo consultant, what does it cost in automation operations, and how does it fail?
What was tested, and when
| Pack | client-intake-v1 |
| First tested | 2026-08-16 |
| Runs | 2 full rounds on the same day, plus two deliberately forced failures |
| Status | passed |
| Pages built on it | tested-client-intake-workflow, what-breaks-client-intake, intake-workflow-template, who-should-not-use-this-stack |
Stack and plans
- Form: Tally, free plan
- Automation: Make, free plan (1,000 credits per month at the time of the test)
- CRM: HubSpot Free CRM, EU data centre
- Acknowledgement email: Brevo, free plan (transactional send)
How we tested
Submissions were made by a scripted browser (Playwright) against the live form, one case at a time, with the timings shown below. Each case was then checked in the receiving systems: the automation run history for the operation count and status, the CRM for the records created, and the receiving mailbox for the acknowledgement. Screenshots were taken of the form fill and the submitted state for every case.
Cases
| Case | Input | What we observed | Ops | Status |
|---|---|---|---|---|
| R1 new lead | new email address, ordinary characters | contact created, deal created, deal linked to contact, acknowledgement delivered to the inbox | 6 | confirmed (both rounds) |
| R1 duplicate after about 50 seconds | same email as the preceding case | existing contact updated, no second contact, no second deal, no second email | 3 | confirmed (both rounds) |
| R1 special characters | Nordic characters and an apostrophe in name and company | values stored intact in the CRM | 6 | confirmed (both rounds) |
| R1 forced failure at the association step | association call made invalid on purpose, then one submission | contact and deal created, association rejected by the CRM, acknowledgement never sent, run ended in error, and the automation platform switched the whole scenario off | 5 | confirmed (reproduced in round 2) |
| R2 duplicate during a queue drain | submissions queued while the scenario was off, then released together on reactivation | four runs started within about one second; a duplicate slipped past the search check and the create call was rejected for a duplicate email address, which errored the run | n/a | confirmed (once; the race itself was reproduced later in pack v2) |
"Confirmed" means the outcome held in every round we ran that case, which for several cases is a single round. Where a case was seen once, the status column says so, and every page that cites it says "observed once". We do not treat one observation as a pattern.
What the pack establishes
- End to end chain works on free plans, both rounds.
- Acknowledgement delivery verified from the receiving inbox, not from the sending tool.
- A new lead consumes 6 automation credits, a duplicate 3, a run that fails at the association step 5.
- At 1,000 free credits a month that is roughly 160 new leads of headroom.
- Duplicate protection holds at ordinary submission pace and fails inside a burst.
- A single unhandled error switches the whole scenario off and queues every later lead.
What it does not establish
- Dedupe is search-then-create, which is not atomic; the race was observed during a queue drain.
- One errored run auto-deactivates the scenario; an error-handler route was not yet in place in this version.
- The acknowledgement was sent from a shared sender domain, because the lab had no authenticated domain at the time.
- The full name is stored in the CRM first-name property; there is no first and last name split.
- Deliverability was verified to one mailbox provider only.
- The free plan's licence lists seven-day run-history retention; we read the licence through the platform's API and could not establish exactly what those seven days cover.
Artifacts
| File | What it is | SHA-256 |
|---|---|---|
| client-intake-v1.blueprint.json | Exported automation scenario (sanitised copy of the tested version) | 56812fed1a7ed57c4d02be5cc813fbb5625cf2ff7e01a46204c14c4d43eb80f2 |
| build-log.md | Build and test narrative (not published; available on request) | not published |
| screenshots | 33 screenshots of form fills, submissions, run histories and error runs (not published; available on request) | not published |
Changelog
- 2026-08-16: pack tested and approved; four pages built on it.
- 2026-08-20: superseded for recommendation purposes by pack client-intake-v2, which adds error handling. The v1 scenario is kept as a reference download and is not recommended for production use.
Corrections are welcome: hello@workflowtestlab.com. If you believe a result here is wrong, tell us which case and we will re-test and publish the re-test with its date.