Five Messages, One Job Card: The Intake Tax Nobody Prices

Because the people sending you work are not filling in your form. They are standing in a hallway, or on a roof, or driving. One poster on r/ausbusiness, sharing an automation he had built for a client, described the sequence this way: "A customer sends a voice note explaining the problem. Then a few photos. Then a text message with the address. Sometimes more photos. Sometimes another voice note." Then the second half of the tax lands, described in the same post: "By the time all the information is there, someone has to go through everything, figure out what's relevant, extract the customer details, work out what the issue is, and then create the job." Nobody prices that step. It does not appear on a quote. It is absorbed by whoever runs the office, usually between phone calls, usually while a tech is waiting on a scheduling answer. The reflex fix is to send everyone a form and insist they use it. The problem with that fix is the first exception. A good customer sends a voice note, you take the job anyway, and the exception becomes the rule again. You cannot win a standards fight against your own revenue.

No, and it is worth being blunt about why. Your intake channel is whatever channel the customer already trusts. If a builder has your mobile number, they will text it. If a homeowner found you on Facebook, they will message there. Refusing that traffic costs more than processing it. The same problem exists inside the business. Two techs will write up the same job differently, and a driver will bundle several updates into one message because that is faster than sending them separately. That is not a discipline problem. It is what happens when someone types with one hand while holding a torch. Systems that assume otherwise fail on the first busy Friday. So the design decision is settled before you build anything. Accept mess on arrival. Do the structuring after the message lands, not before.

One inbox, one drafting step, one human approval. Capture: every channel, including SMS, WhatsApp, email, web form and voicemail, lands in one place with the original message attached. Transcribe: voice notes are converted to text and photos stay linked to the thread. Draft: the model fills a fixed job card covering customer, site address, contact, problem summary, urgency, trade required, photos and source message. Review: one named person scans the draft against the original, corrects it and approves. Create: the approved card is pushed into ServiceM8, Tradify, simPRO or whatever job system you already run. The review stage is the one that matters. A card with blank fields is fine. A card with confidently wrong fields is not. Anything the model is unsure about should be flagged as unknown rather than guessed. Australian addresses are the usual failure point. Suburbs go missing, states get abbreviated inconsistently, and unit numbers arrive in three formats. Pattern matching alone will not save you. Validate addresses against a real lookup and flag anything ambiguous for the reviewer. A wrong suburb sends a van to the wrong side of town, and a wasted run undoes whatever the intake step saved you.

Yes, but be honest about which half you are saving. Reading a voice note transcript and correcting two fields takes well under a minute. Listening to a voice note, scrolling for the address, opening the job system and typing eight fields takes several. You are removing the retyping and the hunting, not the judgement. The same r/ausbusiness poster, describing the ServiceM8 flow he built, said the quiet part out loud: "The work flow is not perfect, it just creates job drafts that still needs to be reviewed by office staff." That sentence is the honest sales pitch. Anyone promising a fully autonomous intake pipeline for trade work is selling you a support ticket. Job creation touches money, addresses and safety. Keep a person in the loop and the failure mode is a slightly wrong draft rather than a van at the wrong house. The realistic claim is this: same intake volume, less typing, faster response, and nothing sitting unread in a personal phone.

This part has nothing to do with typing speed. Field extras get lost because they are recorded informally and late. A poster on r/Construction described the pattern: "They do the work, tell the GC "no problem," and then send me a vague text or a blurry photo of a scribbled note 2 weeks later. By the time I write up the Change Order, the GC denies it because it wasn't documented in time." Once you have a capture channel that accepts a photo and a sentence, extras stop being a memory problem. A tech texts a one-line note with a photo attached and it becomes a dated, timestamped variation draft against the right job, sitting in a review queue that day rather than two weeks later. The difference is not the model. It is that the informal channel the crew already uses is now wired to something that files it. You are not asking anyone to change behaviour. You are catching the behaviour they already have. If unbilled work is a problem in your business, chase the variation capture before you chase the admin saving. It is the easier of the two to point at on an invoice.

Someone on your payroll, not an agency on a retainer. Intake logic is the most business-specific thing you have. Your urgency rules, your trade codes, your suburbs, your commercial accounts that always jump the queue. That knowledge sits with your office manager, not with a contractor who learns it from a discovery call. Intake automations also drift constantly. A new channel appears. A customer changes how they refer to a site. The job system gains a field. If every change requires raising a ticket with a third party, the flow decays until someone quietly goes back to retyping. There is a fair counter-argument, put by one commenter in an r/ausbusiness thread on trade software: if you want to be back on the tools and see growth, you will need to hire somebody to set up and maintain the invoicing and scheduling. That is right about delegation and wrong about outsourcing. Someone does need to own it. The question is only whether that person is inside the business. Give your office manager the skill to read a failing flow, work out which step broke and fix it, and the system survives. Rent that skill and you have added a dependency to the thing you built to reduce dependencies. The transferable capability here is diagnosis and process mapping, not knowing where the nodes go.

Pick one channel and one job type. Run it manually first. For two weeks, have whoever creates jobs keep the raw messages for one job type and note what they had to add or fix each time. That list becomes your job card schema and your review checklist. Build against real messages, never against an imagined tidy one. Then wire capture for that single channel, draft into the card, and route to review. Measure two things: minutes per job created, and the number of variations captured that previously would have been missed. Expand only once both hold up for a month.

**Do I need to replace ServiceM8 or Tradify to do this?** No. This sits in front of your job system, not instead of it. Messages are captured and structured before job creation, then the approved card is pushed into the system you already run. Your scheduling, invoicing and history stay exactly where they are. **Can it handle voice notes and photos, not just text?** Yes. Voice notes are transcribed to text and the audio is kept alongside the draft. Photos stay attached to the thread and carry through to the job card. The reviewer can always open the original message, which matters when a transcript is unclear. **What happens when the model gets a field wrong?** The reviewer corrects it before the job is created, which is why the review step exists. Configure the drafting to leave uncertain fields blank rather than guess, especially addresses. A blank field prompts a check. A confidently wrong field gets approved without anyone noticing. **Is this worth it for a two-person business?** Often yes, but for the variation capture rather than the admin time. If unbilled field extras are walking out the door, a capture channel that accepts a photo and a sentence pays back faster than any keystroke saving. If you invoice everything accurately already, the case is weaker. **Who maintains it once it is built?** Someone inside your business. Intake rules change whenever a channel, customer or job type changes. A staff member who can diagnose which step broke will keep it alive. A flow that requires an external ticket for every tweak tends to decay until people quietly revert to retyping. **How long before it is usable?** A single channel and single job type is a small build. The longer part is mapping how jobs actually get created, exceptions included, and agreeing the job card schema. Doing that mapping properly is what determines whether the thing survives contact with a busy week.

Quotes are reproduced verbatim from public Reddit threads and attributed to the subreddit only. The two r/ausbusiness quotes in the intake section come from a single post by a developer sharing an automation he built for a client, so they are one source, not two. r/ausbusiness: https://www.reddit.com/r/ausbusiness/comments/1tteewu/anyone_else_tired_of_manually_creating_servicem8/ and r/Construction: https://www.reddit.com/r/Construction/comments/1p3e7l4/lost_4k_this_month_on_unbilled_tm_work_how_do_you/ . Evidence strength is low. This is a small number of public posts, not survey data, and no volume or frequency claim is made here.