Find a problem small enough to finish
Ask a prospective client to show you a recent example rather than describe an ideal workflow. Follow one inquiry from arrival through assignment, response and recordkeeping. Note what someone copies, what they decide and where information goes missing. A real example exposes exceptions that a feature list hides.
Choose a process that happens repeatedly and has a clear finish. An electrician's inquiry might need a customer name, service address, problem description and callback task. Start by assembling that information for a person to review. Automatically promising an appointment or quoting work would introduce decisions that the first project does not need.
| Process | Sensible first deliverable | Keep under human control |
|---|---|---|
| New inquiries | Organized summary and assigned follow-up task | Price and service promises |
| Meeting notes | Draft action list with owners | External commitments |
| Customer questions | Suggested response using approved material | Exceptions and sensitive advice |
| Weekly reporting | Checked totals and an exception list | Business decisions |
Sell an outcome with a testable boundary
Write a short scope: inputs, output, connected accounts, approver, exclusions and acceptance checks. Replace “automate customer service” with “prepare a draft reply for these five common questions, show its source and place uncertain cases in a review queue.” That is something the client can evaluate.
Set up accounts in the client's name where possible. Agree who pays recurring software and usage charges. Make describes credits as its billing unit, with usage depending on workflow actions. A low advertised subscription does not establish the cost of a busy process. Price the workload, not just the tool.
Build in failure before selling reliability
Test a normal input, an incomplete input, a duplicate and an unavailable connected app. Include a customer message containing irrelevant instructions. The workflow should identify missing information instead of inventing it. Repeating an event should not create a second customer or send a duplicate request unnecessarily.
A review step is a practical control, not evidence that every result will be correct. Zapier documents an approval action with account and plan requirements. Check those conditions before promising clients an approval process. Choose a safe outcome for declined or unanswered requests.
Give the client a pause switch, error notifications and a short recovery guide. Record what the system is allowed to read and change. Do not request broad account access merely because it makes setup faster.
Price the build and maintenance separately
Hypothetically, a project takes six hours to build, two to test and two to explain and revise. At an internal labor target of $45 an hour, labor alone is $450. Adding $40 of unreimbursed tooling and a $60 contingency produces a $550 planning floor before tax and profit choices. This is an illustration, not a market quote or earnings forecast.
A maintenance agreement should say what monitoring and small changes include. New applications, departments and decision rules are new scope. Otherwise a one-time project can quietly become indefinite support.
Land the first project
Demonstrate a small workflow with synthetic business data. Show the before-and-after task, an intentional failure and how a person intervenes. Offer a paid, limited pilot with an agreed acceptance test. A dependable explanation of what happens on a bad day is more useful than a polished happy-path demo.
Use our service-pricing guide to calculate the work you keep. If the client needs a small interface rather than a cross-app workflow, compare building an AI tool.
Walk through a complete pilot
Consider a fictional electrician who receives website inquiries and manually copies them into a shared job list. The pilot handles one form, one spreadsheet and draft callback tasks. It does not book work, calculate prices or send a reply without approval.
The mock input is: “Alex Rivera, 14 Oak Lane. The kitchen outlet stopped working yesterday. Please call after 3 p.m. I do not know the panel model.” The contact information is fictional and used only to demonstrate the process.
The expected output is a job row with the supplied name and address, a summary that preserves the customer's description, a callback preference and a missing-information flag for any required contact field. It should not infer a cause, describe the issue as safe, invent a phone number or promise a same-day visit.
A draft reply could say: “Thanks for your inquiry. Please provide the best phone number for a callback. Our team will review the job details before confirming availability.” The owner approves the wording and the escalation process for urgent or safety-sensitive messages.
Test the same inquiry twice. The second submission should be identified according to the agreed duplicate rule rather than silently creating two jobs. Then remove the address, disconnect the destination sheet and insert a message telling the system to ignore its normal rules. The result should be a visible exception or safe failure, not a fabricated complete record.
Agree what counts as acceptance
Use a fixed set of synthetic cases before connecting live data. The number of cases should reflect the complexity, not create a false claim of statistical certainty.
| Check | Evidence the client can inspect |
|---|---|
| Required facts are preserved | Input beside the resulting row |
| Missing fields remain missing | Exception list with reason |
| Duplicate handling follows the agreed rule | Repeated submission and resulting records |
| External messages require approval | A pending draft and approval history |
| Connection failure is visible | Error notification and recovery steps |
| Client can stop the workflow | Demonstration using the pause control |
| Permissions are limited | Account-access inventory |
Document any failed case, correction and retest. Approval should mean the client accepts the stated scope, not that the automation is guaranteed never to fail.
Make outreach as specific as the pilot
A first message could read: “I help small service businesses organize incoming quote requests. I made a fictional example that turns a form response into a checked callback list and keeps replies for your approval. If copying inquiries is a recurring problem, I can scope a paid pilot for one form and one shared list.”
Do not claim you observed their private workflow. Ask permission to examine a sample with personal information removed. Use the first-client process to qualify the need before offering a fixed price.
Hand over an operation, not just a login
Deliver the scope, account inventory, workflow diagram, field definitions, test cases, error instructions and a short recorded or written walkthrough. Explain recurring subscription costs, review responsibility and which changes require a new quote.
For the hypothetical $550 planning floor above, the proposal might include the one-form build, the agreed tests, one consolidated revision round and a handoff session. An ongoing monitoring service would have separate hours and response expectations.
Have the client pause and resume the system, locate an exception and identify the responsible reviewer. That final exercise shows whether the handoff is usable. For related administrative work that needs a person each week, compare AI-assisted virtual assistance.
Frequently asked questions
Do I need to code?
Not for every first project. You do need to understand data flow, permissions and failure handling. Decline work you cannot test or maintain.
Can I promise a time saving?
Measure the client's baseline and pilot result first. Include review, corrections and maintenance. Keep an estimate labelled as such until comparable evidence exists.
Should I charge a monthly retainer?
Only when there is a defined recurring service. Monitoring and documented changes can justify recurring work; simply leaving a workflow switched on is not a clear deliverable.
What belongs in the handoff?
Account ownership, a workflow diagram, permissions list, tests, operating instructions, known limits and a support route. Another competent person should be able to understand the system.
What if a client wants the system to act without review?
Evaluate the consequences, permissions and testing needed for that specific action. Do not remove a review step simply because the tool can execute automatically. Start with the limited workflow you can support.
Sources and research notes
Source pages checked October 30, 2026. Worked examples are hypothetical; they are not observed earnings or guarantees.