It’s important for founders to experiment with pricing, but many of us forget that it isn’t just about changing the price itself.
Checkout, support, tracking, messaging, and billing all need to be checked — these are the things that founders usually miss.
Here’s a workflow that uses AI and no-code automation to keep your experiments on track. One form starts the test, AI checks what needs to be done, automation creates the tasks, and a launch gate blocks the test if key pieces are missing.
Stack
Create a Jotform called Pricing Test Intake. The form fields should collect the basic details of the test:
Also, add a checkbox field for where the price could appear. Include:
Use the same Test ID in Trello, Google Sheets, Slack, Stripe notes, support docs, and analytics. This makes the test easier to track.
If current customers are affected, add a required field called Migration plan. This should ask:
For the stop rule, go for something concrete, such as:
This prevents the test from running forever.
Now, connect the form to the rest of the workflow.
In Make, create a new scenario. Use Jotform as the first step:
If Make asks for an API key, get it from: Jotform → Profile → Settings → API
Test it:
Once Make receives the test entry, the form is connected.
Once Jotform is connected, add OpenAI.
Then write a prompt that includes the key intake details needed to review the test:
Ask OpenAI to return four sections:
Run one test submission. The result should be the checklist you use to create the Trello cards.
Now, add Trello after OpenAI in the same Make scenario.
Create the main experiment card first. Set the card up like this:
In Make, map the experiment ID and experiment name from Jotform into the card name. Then, map the OpenAI AI checklist into the card description.
Next, create four more Trello cards:
Copy card
Use this card to check every place where the price message may show up.
Check: Pricing page, upgrade page, signup page, FAQ, onboarding emails, support replies, receipts
Checkout card
Use this card to check the checkout setup.
Check: Product name, price, billing terms, trial, success page, cancel page, checkout URL, test checkout
Support card
Use this card to check customer support issues.
Check: Who gets the price, who does not get the price, existing customer questions, Past payments, confused customers
Tracking card
Use this card to check if the test can be measured.
Check: Pricing page visits, checkout clicks, purchases, refunds, cancellations, pricing support tickets
Add the main metric and stop rule to the tracking card.
Run one test submission and check Trello.
Only create this card if existing customers are affected.
In Make, add a Router and create two paths:
Add this filter to the migration route: Does this affect existing customers? = Yes
Then, add Trello Create a Card to the migration route. Use:
The card should include:
If existing customers are not affected, this card should not be created.
Now, add Google Sheets to the intake scenario.
In Make:
Create these columns in the spreadsheet:
Leave these fields blank for now:
Run a test form submission. A new row should appear in Google Sheets.
Next, add Slack at the end of the intake scenario.
In Make:
Use this message (or something similar):
New pricing test created: {{Experiment ID}} — {{Experiment name}}
New price: {{New price}}
Audience: {{Who should see this price?}}
Do not show to: {{Who should not see this price?}}
Main metric: {{Main metric}}
Stop rule: {{Stop rule}}
Check Trello for the task cards.
Run a test submission and check Slack.
Create a second Jotform form called Pricing Test Pre-Launch Check.
Add these required fields:
Use Yes/No answers for the readiness questions. For 'migration plan ready?' Use:
This form is completed only after the Trello tasks are done.
Create a new Make scenario for the pre-launch check.
Use this trigger:
Then fill out the pre-launch form one time to test it. Make should receive the answers.
Next, add a Router with two routes:
Route 1: Blocked
Use this route if anything is missing.
Add a filter:
Block the launch if any of these answers are No:
* Pricing page ready?
* Checkout ready?
* Support replies ready?
* Tracking ready?
* Does checkout match the pricing page?
* Migration plan ready?
Then send this Slack message(or something similar):
Launch blocked: {{Experiment ID}}
Fix the missing items before launch:
* Pricing page
* Checkout
* Support replies
* Tracking
* Checkout and pricing page match
* Migration plan, if needed
Route 2: Approved
Use this route when everything is ready.
Add a filter:
Set the approved route to run only when:
* Pricing page ready? = Yes
* Checkout ready? = Yes
* Support replies ready? = Yes_
* Tracking ready? = Yes
* Does checkout match the pricing page? = Yes
* Migration plan ready? is not No
Then send this Slack message:
* Pricing test approved: {{Experiment ID}}
* _Pricing page: {{Final pricing page URL}}
* Checkout: {{Final checkout URL}}
You may launch.
This is the key automation. It does not launch the price. It blocks or approves the launch based on the pre-launch check.
Create one more Make scenario for weekly review.
Use this Slack message (or something similar):
Weekly pricing test review
Check every live test.
Review:
* Pricing page visits
* Checkout clicks
* Purchases
* Refunds
* Cancellations
* Pricing support tickets_
* Main customer objection
Decision: Keep, stop, or change.
This gives every live test a review date. It’s not fancy, but it is enough to stop pricing tests from running forever.
Before going live, submit fake entries via the intake and pre-launch forms. Check that the workflow does what you expect:
When the tests work, turn the scenarios on. Now the workflow is live.
The basic logic also works in Zapier, but in this version, Make is the automation layer.
This is the system.
The piece I'd add to any "test prices without chaos" system: grandfather existing paying customers indefinitely on whatever price they signed at. Anchoring loss aversion is real — a churn spike from a price change on existing accounts will overwhelm whatever ARPU lift you get from new ones, and the math basically never works out at <$50 ARPU. Test prices on new signups only, version your pricing page (e.g. /pricing-v2), and let cohort-by-acquisition-date tell you the truth.
The stop rule is the most underrated piece of this. Most founders never test pricing because it feels like an open-ended mess, and a concrete kill switch like "stop if refunds pass 8%" is what makes the test safe enough to actually run. When we raised prices at SocialPost.ai, the scary part was never the number. It was the surface area: receipts, FAQ, support replies, old screenshots in help docs. Your checkbox list of every place a price can appear is worth the whole post.
Solid pattern. One thing the price-testing flow misses that AI eval workflows solved: a shadow run before you flip the segment. DSPy (https://github.com/stanfordnlp/dspy) bakes the same idea in. You run the new prompt against the same data the old one ran on, before any user sees it. For pricing this means: same intake form, same audience filter, run both prices for 48 hours in parallel where the user still sees the old price but you log the conversion as if they saw the new one. Cleaner read on the elasticity without burning customers. Worth bolting on before the segment switch ships.
This is the kind of post that makes you realize how many pricing experiments are running half-blind. Most founders change the number and call it a test.
The pre-launch gate stood out to me. Blocking the launch if something is missing instead of just flagging it is a small detail that changes everything. Warnings get ignored. Hard stops don't.
One question: what happens when the numbers move during the test but for reasons outside your control — a competitor changes their price, a big mention sends a traffic spike? Does the stop rule still apply or do you just accept that as noise?
testing before can save SO much unnecessary stress later. thanks again for this.