Keep the channel familiar
I chose SMS so a busy, non-technical tradesperson would not need another app to receive a short enquiry alert.
For automation freelancers · small overflow work
Small tasks.
Useful automations.
I’m an entry-level Zapier builder looking to help with straightforward jobs that fall outside your usual project size or current capacity.
ZapierAirtableWeb formsSMS notifications
See the ladder enquiry ZapEntry-level scope / simple setups & mapping changes
Small paid pilot / clear acceptance checks
Your client relationship / your final review
Featured case study / the ladder enquiry Zap
Built around a person,
not just an app connection.
A tradesperson up a ladder cannot keep checking web enquiries. The customer needs reassurance; the tradesperson needs the details in a familiar channel.
What I built
A form enquiry is checked against an Airtable no-contact table. If the number is found, the Zap stops before either message. If it is not found, the Zap formats the phone value used in the trader alert, sends that alert, and acknowledges the customer.
The useful information
The internal text includes the customer’s name, requested service, location and callback number. The customer gets confirmation that the enquiry was received and that follow-up will happen.
The important rule
Found = stop. Not found = continue. The lookup’s Boolean result controls the Filter. The form’s Phone value supplies Formatter. Those are different values with different jobs.
What this demonstrates
- Turning a practical user problem into a simple workflow.
- Mapping form data into an Airtable search and SMS messages.
- Using a Filter before external actions.
- Correcting a field mapping and checking the result.
The stop branch represents the Filter’s behavior, not a separate Paths step.
Decide before sending
The no-contact lookup and Filter come before both messages. A match stops the workflow rather than sending first and checking later.
Use the right value
The form and Airtable use +44 format for matching. Formatter then converts the phone—not the found-status flag—to local 0 format for the alert.
Builder’s test account / 20 October 2026
Checked after the phone-mapping correction
- A suppressed number stops the workflow before either SMS.
- An absent number allows it to continue.
- Formatter returns the expected phone value, not true/false.
- The trader notification carries the correct enquiry/callback information.
I corrected Formatter’s input to use the submitted Phone field and confirmed the behavior worked.
These are my reported checks of my own Zap. The original export was inspected; a fresh corrected export, screenshots and run logs are not included. This is not an independently executed test report.
Trader notification / illustrative wording
“New enquiry: Alex needs gutter cleaning in Exampletown. Callback: [customer phone].”
Customer acknowledgement / illustrative wording
“Hi Alex, thanks for your enquiry. I’ve received your request and will get back to you when I can.”
Examples explain the message purpose. They are not screenshots, exact deployed templates or captured delivery results.
Where I can be useful
Small work from a clear brief.
I’m looking for manageable Zapier tasks, not claiming senior-level architecture or experience with every integration. I’ll check the requirements with you before accepting a job.
Forms & field mapping
Straightforward form-to-Airtable flows and carefully mapped values from one app to another.
Filters & notifications
Simple condition changes, message fields and notification steps in workflows I can understand and test.
Checks & short notes
Agreed sample-data checks and a concise record of the source, rules, changes and known limitations.
A starter-friendly fee should match a starter-sized task. I’m happy to begin with a modest paid pilot—not an open-ended commitment. You retain the client relationship and final sign-off.
Define the result
Trigger, apps, required rules, access and sample data.
Agree one small task
Deliverable, fee, checks and review/revision boundary.
Use safe test data
Verify the agreed cases. Escalate unclear behavior rather than guess.
Hand back for sign-off
Configuration and short notes. Agree live activation separately.
For the technical reviewer
A clear design you can inspect.
The inputs, six steps, suppression rule, phone mapping and remaining boundaries are documented.
The JSON is a readable process specification—not an importable Zap, native account export or runnable demo. No credentials, live destinations or customer data are included.
Read the requirements, field mappings and limits
Purpose
Acknowledge a web enquiry and notify a busy tradesperson without asking either person to install another app. Screen the submitted number against a local Airtable no-contact table before sending either message.
This is a demonstration of a manually built Zapier workflow. It is not presented as paid client delivery or a complete business messaging platform. The original account export identifies the featured Zap as “Send \"ladder\" auto-reply marketing message via SMS”; the portfolio uses a clearer descriptive title, not a claimed live rename.
Required inputs and assumptions
The form supplies Name, Phone, Service and Location. The phone is supplied in +44 format and matches the format stored in Airtable’s number field. The example is UK-focused and has a configured fixed internal notification recipient.
The form, Airtable connection and TextMagic connection already exist. Numbers must be entered consistently; changing the displayed number after the lookup does not fix an earlier mismatch. Missing numbers, international variants and unexpected data need separate validation before adapting this example to a new brief.
The six steps
- Form — new submission. Receives the enquiry fields.
- Airtable — Find Record. Exact-match search of the suppression table’s
numberfield against the form’s Phone. The lookup is configured to finish successfully when no record is found, so the following Filter can evaluate that result. - Filter — allow only not found. Continue only when the Airtable “Search Was Found” flag is false. A true result stops before both SMS actions. This Boolean must not be replaced with the phone value.
- Formatter — Text Replace. Input is the form’s Phone, not the Airtable found-status. Replace
+44with0. The output is the local phone representation used in the trader alert. This is a format conversion, not comprehensive validation. - TextMagic — internal notification. Sends to a configured fixed tradesperson recipient. Maps Name, Service and Location from the form and the callback-phone field from Formatter’s output.
- TextMagic — customer acknowledgement. Acknowledges receipt and promises later follow-up. The original export maps the recipient from the submitted Phone. No additional recipient-mapping change is asserted without a fresh corrected export; the builder reports the workflow tests worked. A customer-facing delivery test should verify the current provider settings and recipient mapping together.
Steps 5 and 6 are sequential. The customer message is not a job booking or an availability check. The filter blocks both sends for a found number; it does not represent two separately managed paths or an internal exception alert.
Why the phone and the Boolean stay separate
The lookup output answers “Was this number found?” The form Phone identifies “Which number is this enquiry about?” Formatter transforms the latter. Earlier-step outputs remain available for mapping later steps; there is no requirement for Formatter to combine the Boolean and phone into a single output.
The corrected input was reported by the builder after inspecting the original export. The lookup remains before Formatter because the form and Airtable use matching +44 representations. No database migration or step reorder is part of this correction.
Acceptance checks and current evidence
The builder reported on 20 October 2026 that the Formatter correction and the advised suppression/notification checks worked. This is builder-confirmed test evidence; no independent execution, screenshot, delivery log or fresh export from the corrected Zap is supplied in this portfolio.
The agreed behavior to demonstrate is:
- A known suppression record causes the workflow to stop before either SMS.
- A number absent from the table allows the workflow to proceed.
- Formatter’s output is the expected phone representation, not true/false.
- The internal notification contains the enquiry details and correct callback number.
- The acknowledgement goes to the intended customer test recipient.
Future testing should use records and recipient numbers controlled by the tester. Testing an SMS action can send a real message; a hypothetical sample is not delivery evidence. A screenshot of a Formatter preview is not proof of a whole workflow run.
Limits and handover considerations
An absence from the no-contact table is not affirmative marketing consent or a complete compliance check. The person responsible for the client’s messaging policy should approve purpose, content, contact permissions and opt-out handling. No claim is made that SMS avoids applicable rules.
A busy tradesperson is the scenario, not a detected status. The Zap has no ladder sensor, work schedule or automatic availability lookup. There is no demonstrated inbound STOP-handler, duplicate-enquiry control, retry route, delivery-receipt management, job assignment or booking system in this featured example.
The workflow should be reviewed against any new client brief before reuse. A broken app connection or lookup error must not be treated as an ordinary not-found result. Check the live error behavior rather than assuming it from configuration alone.
No account export, credentials, live phone numbers, table identifiers, private endpoints or customer data are included. The JSON supplied with this document is a readable process specification, not an importable Zap or a tested clone. A native shareable Zap template, if later provided, should be checked for what configuration it includes and what the recipient must recreate.1
References
The example handles enquiry acknowledgement and notification. It does not demonstrate automatic bookings, inbound opt-out capture, full compliance, retries or delivery-receipt management. No time-saving or paid-client claim is made.
A good first collaboration
One suitable task.
A clear review point.
If you have a small Zapier setup or modification that does not fit your current capacity, I’d be happy to discuss a paid pilot. Send the intended result and required rules, and we can agree whether it fits my current skills.