How to Test an Automation Before It Goes Live:Use Yourself

To test an automation before it goes live, run the whole thing on a contact you control, which is you. Treat the test as real, because in most tools it is. Walk every branch, read the messages on a phone, then check the records it left behind.

How to test an automation before it goes live: use yourself as the customer

Here is the rule. Nobody outside your business sees a workflow until you have been through it first.

Most solo operators skip this. You built the thing on a Sunday. It looks right in the editor. The boxes join up. So you switch it on and go to bed.

That is how your best prospect becomes your test subject. The broken link, the blank first name, the condition that sends everyone down the wrong path: they all reach a real person first, and the first real person is usually the warmest lead you have.

A test takes minutes. A bad first impression can't be recalled. Do the maths.

And be clear about one thing before you start. In many tools a test run is a real run. Real messages go to whichever contact you choose. That is not a flaw. That is exactly why the contact should be you.

Set up a contact that behaves like a customer

Use your own address, ideally one you can read on your phone. Make a record for yourself that looks like the people the workflow is meant for. Same fields filled in, same tags, same source.

Then ask what a stranger's record would look like and make yours match. If your real contacts often arrive with a half-empty profile, your test contact should arrive with a half-empty profile too. The tidy version of you will pass every test. The messy version is who the workflow will actually meet.

One more thing here. Write down what you expect to happen before you trigger anything. A task for you. A tag on the record. A confirmation in your inbox. If you only look at the results afterwards, you will convince yourself that whatever happened was what you meant.

Free guide · 21 pagesAutomate the follow-through, not the relationship.The Automation Playbook: what to hand to a machine first and how to build it so it behaves.Get the free guide →

Walk every branch, not just the happy path

The happy path is the one you designed. It works because you designed it. It is also the one that matters least for testing.

Every condition in your workflow is a fork. If this is true, go one way; otherwise, go the other. Each fork needs a test, which means each fork needs a version of your test contact that takes it.

If you wrote the workflow as plain sentences first, as in designing it from trigger, condition and action, those sentences are your test script. Say you have a workflow that treats existing customers differently from new enquiries. Run it once as a new enquiry. Run it again as a customer. Run it a third time with the field that decides the branch left empty. That third run is the interesting one. It shows you where people fall out when your data is incomplete, and incomplete data is normal.

Also test the exit. The workflow should stop the moment the person reaches the goal it exists for. So reach the goal during your test. Reply to the message. Book the call. Then check that the rest of the sequence goes quiet. A workflow that keeps chasing someone who already said yes is the single most embarrassing thing automation does.

While you are there, enrol your test contact a second time. Does it send everything again? If so, that is a decision you need to make on purpose, not one you discover when a customer forwards you the duplicates. There is a whole post on how to stop an automation sending twice.

What to check, and what each check catches

Four things need your eyes. Here is what each one is for.

That is five checks to test an automation, not four. Fine. If you were counting, you are already the kind of person who should be testing.

Test an automation by reading it the way the recipient will

Open the message on your phone. Not in the editor preview. On the phone, where most people will read it.

Look at the subject line. Does it make sense on its own? Read the first line. Does it sound like you, or like a rule wrote it? People can tell. If a message pretends to be a personal note you never wrote, fix it or cut it.

Then click every link. All of them. A link that goes nowhere in your test goes nowhere in the real run, and nobody will tell you. They will just leave.

Now break the personalisation on purpose. Empty the first name. Paste a name in all capitals. See what the greeting does. If it shouts or stutters, rewrite the line so it still reads naturally without the field. The safest personalisation is the kind nobody notices when it fails.

Last, look for the way out. Every marketing message needs a working way to stop receiving it. Click it. Check that it does what it says. This is not only polite. In many places it is a legal requirement, and getting it wrong damages your ability to reach everyone else.

Free assessmentHow trapped are you, really?Take the Corporate Suffocation Index, the free solopreneur readiness assessment.Take the assessment →

Check the work nobody sees

This is the step people skip, because the inbox looks fine and the inbox feels like the result.

It isn't. The more valuable half of most workflows is invisible to the customer: the task created for you, the tag applied, the lead routed into the right list, the reminder that something needs your judgment today. These are the actions where handoffs actually drop.

So open the record afterwards. Is the task there? Is the tag on it? Did the reminder reach you? Is the contact sitting in the list you expected?

If the confirmation email arrived but the task never appeared, your test passed and your workflow failed. Only the second look shows you that.

Check the timing and the neighbours

Two more things, and both are easy to forget because they do not show up in a quick run.

First, timing. Waits are steps too. A follow-up that arrives a few days later reads as patience. One that arrives an hour later reads as pressure. One that lands in the middle of the night, or on a public holiday, announces that nobody was there to send it. You can't sit through a multi-day wait in a test, so read through the wait settings by eye and ask what should happen if the situation changes while the person is waiting.

Second, the neighbours. Does anything else in your business send this same person something at the same moment? Two workflows, each sensible alone, can collide into a contradiction. One tells a new customer to book a call. The other thanks them for booking. Look at what else runs on the same trigger and make sure they do not talk over each other.

Free guide · 21 pagesAutomate the follow-through, not the relationship.The Automation Playbook: what to hand to a machine first and how to build it so it behaves.Get the free guide →

When the test is done, you still are not finished

Passing a test means the workflow does what you designed. It does not mean it does what you meant.

So switch it on for real, and watch the first few people who go through it. Not weeks later. This week. Open their records and read what they received. Treat the first real run as the last step of the test. If something looks off and you cannot tell why, here is how to spot a silent failure.

Then put the workflow on your weekly look. A test is a photograph. Review is the film. Things drift: fields go stale, stages get renamed, people arrive by routes you never anticipated. The test you ran today says nothing about the form you rebuild next month.

That is also the moment to run the test again. Any change to a form, a field or a pipeline stage earns a fresh run on yourself.

Free assessmentHow trapped are you, really?Take the Corporate Suffocation Index, the free solopreneur readiness assessment.Take the assessment →

Frequently asked questions

Do I really need to test something this small?

Yes. Small workflows are the ones you stop thinking about. A test takes minutes, and a small mistake sent to a real prospect still costs you trust. Size does not protect you from a broken link.

What if my tool has a preview mode?

Use it, then do the real run as well. A preview shows you the message. It does not show you the tag, the task, the timing or the branch. Know what your tool's test actually does, and remember that in many tools it sends for real.

How many branches should I test?

All of them. If a workflow has a fork, each side needs a run, and so does the case where the deciding field is empty. That empty case is where people quietly drop out.

When should I test again?

Test an automation again after any change to the workflow, and after any change to the forms, fields, stages or pipelines it depends on. If something upstream moved, assume the workflow noticed before you did.

The full method, with the checklists, is in The Automation Playbook, a free 21-page playbook.