Skip to content
Studio proof

4 min read

Transmission Form System

How the project brief and Test Pilot forms became a safer intake system for real enquiries, not just a contact form with a prettier label.

About this piece

Stage
Studio note
Published
2026-05-25
Updated
2026-06-11
Tags
Forms, Intake, Automation

Cleaner project intake

Safer enquiry handling

Manual fallback stays available

The work

The Transmission page is the main entry point for project briefs and Test Pilot requests. It needed to feel simple for the visitor while still giving the studio enough structured information to judge fit, scope, timeline, and next steps.

That meant treating the form as a small operational system, not just a design component. The visitor sees plain questions and useful confirmation copy. Behind the scenes, the site keeps the payload tidy and avoids accepting messy, incomplete, or suspicious submissions.

That is the difference between a contact form and an intake system. A contact form asks for a message. An intake system asks for just enough structure that a useful reply can happen without a long back-and-forth.

The useful bit

The form now supports the way real enquiries arrive. Some people have a clear project brief. Others only know that a workflow is taking too long, a website is not explaining the business properly, or a tool needs to exist before the next busy season.

The page gives those people a way in without forcing them into a sales script. Even when the shape is not obvious yet, the studio can still reply with a practical next step.

The page separates two different visitor intents. A project brief is for people who might need a website, automation, AI agent, integration, dashboard, or practical system built. The Test Pilot form is for people who want to hear when early Wacky Works apps and tools are ready for real-world testing. Keeping those paths distinct makes the inbox more useful and makes the visitor's choice clearer.

The project brief shape

The project brief form asks for the useful basics: name, email, project type, rough budget, timeline, what the visitor wants to build or improve, and the current tools or systems involved. That is enough to understand fit without asking the visitor to write a formal specification.

The budget and timeline fields are not there to qualify people out rudely. They help the first reply be honest. A tiny urgent fix, a mid-sized automation, and a larger custom system need different next steps. Asking early saves both sides from pretending every enquiry is the same.

The free-text fields are where the real signal lives. A good brief often says: "We copy the same data between a form, a spreadsheet, and an inbox every week." That is more useful than "we need AI". The form is designed to draw out that kind of practical detail.

The Test Pilot path

The Test Pilot form is intentionally lighter. It asks what the visitor is interested in testing and what kind of business or work context they come from. That gives the studio enough information to match future tools with the right early users.

This matters because not every test build should go to every person. A warehouse utility, a search-audit helper, an internal dashboard pattern, and a small business automation tool all need different feedback. Better context means more useful pilot invitations later.

The safety details

The forms use server-side validation, a hidden honeypot field, separate recipient routing, and visitor-safe status copy. Those details are not exciting, but they stop a public form from becoming a mess.

Validation keeps the payload useful. Recipient routing makes sure different enquiry types reach the right inbox. Confirmation copy tells visitors what happened without exposing implementation details. Manual fallback copy remains available if email delivery is temporarily offline.

The key principle is that the public page should never sound like a debug log. Visitors need a calm status message and a reliable fallback, not a list of environment variables.

What shipped

What shipped

  • One shared intake flow for project briefs and Test Pilot interest.
  • Plain confirmation states for successful submissions and manual fallback.
  • Email delivery that sends different enquiry types to the right place.

The lesson

Forms are part of the product experience. If the intake is vague, the work that follows starts vague. If the intake is too demanding, visitors bounce before a conversation starts. The useful middle ground is a short form that captures the decision-making facts and leaves room for messy human context.

That is what Transmission is for: fewer performative questions, better first replies, and a cleaner path from "something needs improving" to "here is the next practical move".

Related capability

Automations

Workflow automations that save time across handoffs, repeated admin, and reporting.