Thirty days of fixes after launch, and a clear way to ask for them
A build is only finished when it keeps working. Every plan includes thirty days of fixes after launch, and this page explains what they cover, how to ask and what the optional optimisation program adds.
- Written in plain English
- A summary above every section
- Updated when our practice changes
Six things you can count on once you are live
Support means different things to different companies. This is exactly what it means here.
Thirty days of fixes, included
If something we built stops working as described during the thirty days after launch, we repair it at no cost.
Ask in one place
Report a problem through your client portal, and it lands with the person who built the part that is affected.
A quick first answer
We acknowledge every report within one working day and tell you what we think is wrong and when you can expect a fix.
A playbook you can use
You receive a recorded walkthrough and a written guide that explains every flow and setting, so your team is never in the dark.
Fixes never use revision rounds
A fix repairs something broken. It does not count against your two revision rounds.
Keep improving if you want
The optional ninety-day optimisation program adds monthly tests, refreshes and a results call.
What the thirty days cover
- Flows, messages and rules that no longer run as described in the scope.
- Connections between your store and the tools we set up that stop passing data correctly.
- Settings, filters or templates that were configured wrongly.
- Errors caused by something we built interacting badly with another part of the build.
The thirty days start on the day your build goes live, and the date is recorded in your client portal.
What they do not cover
- Problems caused by changes you or others make to your store, apps or settings after launch.
- Changes to the rules, limits or prices of a platform that we do not control, though we will help you adapt, and larger adaptations may need a quote.
- New features, flows or channels, which are a change in scope.
- Changes to wording or design that work as described, which are revisions rather than fixes. See the revision policy.
- Problems with your own platforms or apps, such as outages, which only their providers can resolve.
How to ask for a fix
Open a request in your client portal, or use the contact form and choose “A current project or order”. Tell us what you expected, what happened instead and, if you can, when it began. A screenshot or an order number is more useful than a long explanation.
How fast we respond
Every report gets an acknowledgement within one working day, with a first view of the cause and a time for the next update. Urgent problems, such as a flow that is blocking orders, are put ahead of everything else.
If we cannot fix it
If a part of your build cannot be made to work as described within the thirty days, we treat that as being unable to deliver, and the refund policy applies.
The optimisation program
For three months after launch, the optimisation program adds monthly tests of subject lines, timing and offers, copy refreshes based on what is working and a results call to review the numbers and decide what to try next. It is available as an option on service pages and is priced there.
Help after the thirty days
After the thirty days, small fixes are quoted at a fixed price, and bigger improvements can be quoted as new work. You are never locked into a support contract, and you own everything we built, so you can also ask someone else.
Questions people ask about this policy
When do the thirty days start?
On the day your build goes live in your store. The date is recorded in your client portal, and we send a reminder before the period ends.
Does a fix cost anything?
No. Fixes during the thirty days are free. After that, we quote small fixes at a fixed price.
What if the problem is on my platform’s side?
We help you work out where the problem is. If it lies with the platform or an app, only their provider can resolve it, and we help you describe it and adapt your build where we can.
Do I need the optimisation program?
No. It is optional. Many clients run their build as delivered and ask for the program only when they want to improve results further.
Can someone else support the build later?
Yes. You own the build and receive a playbook that explains it, so any competent developer or agency can support it.
What does the warranty cover?
Faults in what we built, such as a flow that stops or a rule that behaves differently from the agreed design.
What does it not cover?
Changes made by others after handover, platform outages and new features, which we quote separately.
How do I ask for a fix?
Send a short description through your client portal and we reply within one working day with a plan.
How quickly do you fix problems?
Urgent issues that stop revenue are looked at first, and we tell you what we found and when to expect the fix.
Can I extend support?
Yes. The optional optimisation program adds three months of improvements, and a care plan continues monitoring, repairs and improvements month to month for as long as you like.
Read these next
Revision policy
How many revision rounds are included, what counts as one and how to request it.
Read moreRefund policy
When a refund applies, and how to ask for one.
Read moreClient portal
Your place for files, messages, revisions, orders and milestones.
Read moreDelivery and turnaround
Delivery windows by plan, what starts the clock and how rush options work.
Read moreTerms of service
The agreement that covers every Checkout Loom build, in plain language.
Read moreContact
Ask a question about a service, an order or your store and hear back within one working day.
Read more
Want a build with a safety net?
Every plan includes thirty days of fixes. Pick a service and see exactly what is included.
- Thirty days of fixes included
- Reply within one working day
- Playbook and walkthrough