Answer in brief
The form submitted and the visitor saw a thank-you screen — and that is where the guarantee ends. Three destinations, taken one at a time: the CRM, the payment provider and analytics. What each needs from you, how each fails, and the checks that catch it.
The short answer: the form is only the first link
An integration is a chain of handoffs. The browser sends the data to your server, the server stores it, and only then does it pass the record on to a CRM, to a payment provider, to an analytics endpoint. Every link in that chain fails on its own terms.
The message that reads «thank you, we have your enquiry» describes the first link and nothing beyond it. It means the request reached the server and the server answered with a success code. What happened after that is not part of the promise the visitor just read.
That gap is where the situation in the title lives. The form works, the visitor is certain they have contacted you, and meanwhile the CRM is empty, the notification email is sitting in a spam folder, and the channel report has no row for the enquiry at all.
The rest of this article goes destination by destination: what each integration needs from you before anyone writes a line of code, how it fails, and which acceptance checks catch a silent failure before a lost customer catches it for you.
What a successful submission actually proves
A success response proves three things. The endpoint exists, the submitted fields passed validation, and a record was written on your own side. That is less than the phrase is usually taken to mean, and it is still worth having: without that link there is nothing to forward anywhere.
It does not prove that an email was delivered, that a row appeared in the CRM, that a payment was confirmed, or that an event reached analytics. All of those happen after the response has been sent, and they happen out of the visitor's sight.
A developer can demonstrate the success response and close the ticket in good faith. So acceptance should not test the submission; it should test each destination by name. Open the CRM and see the record, open the inbox and see the notification, open the dashboard and see the event.
The engineering answer is a separation. The visitor's confirmation is earned by the write on your side, and delivery to each destination becomes a second operation with its own log, its own retries, and its own alert to a named person when it does not succeed.
Three destinations, and what each one is for
The CRM owns the enquiry. It keeps the contact, the history and the deal stage, assigns someone to answer, and lets you ask six weeks later what became of a particular lead. A shared inbox cannot do that; the thread simply drifts down the list until nobody remembers it.
The payment provider owns the money and the legal surface: the card, the currency, the receipt, the refund. A mismatch between charged and recorded is visible to the buyer and to their bank, which is why this destination is checked with a real transaction rather than a screenshot of a sandbox.
Analytics owns attribution. Where the visitor came from, which pages they read, at which step they left. Without it an advertising budget is set from impressions in the room rather than from what your own site can tell you about the path that leads to an enquiry.
Three systems, three jobs, three ways of breaking. That is why a single quote line reading «set up integrations» tells you nothing useful about the work. Each one needs its own access, its own field mapping, and its own check when the work is handed over.
What a CRM integration needs from you
An account and the rights to use it. A working CRM plan that permits records to be created through its API, and a key or connection issued in the company's name rather than from the personal profile of an employee who may hand in their notice in March.
A field map. The list of fields on the form and the CRM field each one lands in: name, phone, email, message, source, campaign. Without that list the developer is guessing, and the mismatch surfaces on live enquiries from real people rather than during testing.
Pipeline rules. Which stage a new record enters, who is assigned as its owner, and what should happen when the same person writes twice: a second card, or a note appended to the card that already exists under their phone number.
An answer to the question of who opens it. The integration carries the enquiry as far as the system; a person with a notification and an agreed response time carries it the rest of the way. Without that person, a tidy CRM only accumulates unread rows.
Where CRM integrations break
Required fields. A CRM rejects a record that leaves a field its administrator marked as mandatory empty. The website form knows nothing about that rule, so the rejection arrives after the visitor has already been shown a thank-you screen and closed the tab.
Types and formats. A phone number sent as free text, a number carrying spaces and brackets, a date written in the other order: the receiving system either refuses the value outright or quietly files it somewhere you are never going to look for it.
Expired access. Tokens and connections have a lifetime, and a password change or a permission revoked by an administrator ends them immediately. An integration that ran for six months stops working on a day when nobody touched the code at all.
Deduplication. A merge rule keyed on phone or email can attach the new enquiry to an old card and keep it out of the list of new ones. The record technically exists; what does not exist is anyone looking at the place where it landed.
What a payment integration needs from you
Your own merchant account. The contract with the provider is signed by your legal entity, which also passes the verification and names the account that receives the payouts. A supplier connects an account that already exists; opening one on your behalf is not something a supplier can do.
The legal layer. Terms of sale, a refund policy, company details, the tax treatment of the receipt, and whatever your provider requires in the product description. That material is yours to supply, and the Product Build package states plainly that payment licensing is not included in it.
Currencies and amounts. Which currency the price is quoted in, how rounding works, whether tax is shown separately. Providers take amounts in the smallest unit, cents rather than dollars, and confusing the two produces a figure that is out by a factor of one hundred.
An address for notifications. The provider needs a publicly reachable endpoint on your site to announce a completed payment, and a verified signature on that message, so that a request arriving from somewhere else cannot mark one of your orders as paid.
Where payment integrations break
The unconfirmed webhook. The buyer paid, the bank debited the card, the provider sent its notification, and the endpoint answered with an error. The money has moved, the order sits in your system marked unpaid, and you learn about it from the buyer's email two days later.
Test keys on a live site. Payments run through the provider's sandbox and look successful on screen while no money moves at all. There is one check worth trusting here: put a small real payment through and find it in the provider's own dashboard.
The return trip. After payment the provider sends the buyer back to an address configured in advance. Point it at a page that does not exist, or one that fails without the payment parameters, and the buyer is left uncertain and may well pay a second time.
Retries and idempotency. Providers repeat a notification until they receive an acknowledgement. Without an idempotency key that repeat creates a second order or a second line in your accounts, and the reconciliation at the end of the month stops balancing.
What an analytics integration needs from you
A list of questions. Not «install a counter» but a list of decisions: which channel pays for itself, where the form loses people, which pages get read before someone writes. Events are derived from questions, and building them the other way round produces numbers nobody uses.
Consent rules. Which scripts you may run before a visitor consents, which only afterwards, and what the banner offers. This decides both the legal position and how much of your traffic will appear in the report at all, which changes how the report should be read.
An event naming scheme. One name per action, written down somewhere: form submitted, checkout started, payment confirmed. Names invented ad hoc as features ship turn a dashboard into a column of near-identical rows that nobody can choose between six months later.
A reader. Who opens the dashboard, how often, and what they do with the number once they have it. Analytics with no reader is a pile of data collected for years that never changes a single decision about where the money goes.
Where analytics breaks
Consent and blocking. Some visitors decline, some run extensions, and some browsers restrict third-party scripts on their own. The number on the dashboard sits below the real visit count, which is why it is compared against itself over time rather than against your bank statement.
Navigation without a reload. On a modern site a page change often happens without a new document request. A counter written for document load sees the entry and concludes the visitor went nowhere else, so every internal step quietly disappears from the funnel.
Duplicates. Two copies of the same tag, one pasted into the template and one added later through a tag manager, double the pageviews and flatten the bounce rate. The report looks healthier than the site behind it actually is.
Counting the click instead of the result. A form-submitted event fired on the button counts attempts that never reached the server. Fire it on the confirmed response instead, or the conversion rate you show yourself is larger than the one you actually have.
The silent failure, and how to fix it
A silent failure is the state where the visitor sees a confirmation, the destination received nothing, and nobody finds out, because the error happened in the background and was addressed to no one. Nothing in the interface is wrong; the outcome simply did not occur.
The first remedy is a log. Every delivery attempt is written down: destination, timestamp, outcome, and what the receiving system answered. The question of whether there was an enquiry on Tuesday then takes a minute to settle instead of becoming an argument between two parties.
The second is a retry. A network fault or a short CRM outage is handled by a few repeats with a growing pause between them, so a delivery that failed at nine o'clock goes through at five past nine without anyone opening a laptop.
The third is an alert to a person. When the retries are exhausted, someone has to receive a message saying so. Silence is not a monitoring strategy: it looks exactly the same as a quiet week with no enquiries in it at all.
What integrations cost the page: speed and access
Every third-party script is extra bytes, extra connections and extra work on the browser's main thread. The MDN performance documentation sets out how to measure that contribution and why code you do not control belongs after the content the visitor actually came for.
The practical consequence is an ordering rule. A chat widget, an advertising pixel and a tag manager should not stand between the visitor and a usable form. The form is the reason for the visit; the scripts that observe it can wait their turn behind it.
The form's accessibility is covered in the W3C quick reference for WCAG 2.2. An error has to be identified in text rather than by colour alone, and status messages have to reach a screen reader without stealing focus from the field the person was typing in.
WCAG 2.2 also adds a criterion on redundant entry: do not make someone type the same information twice within a single process. In a checkout that is precisely the confirmation step, where an address entered on the previous screen should already be filled in.
How to scope the work, and what each package excludes
Site Fix Pack is $70 and takes 1-2 working days: up to five agreed fixes, a mobile and desktop check, a before/after list at handover, and one round of revisions. New pages, a redesign and migrations sit outside it, so connecting a payment provider for the first time is not a fix-pack job.
Launch Site is $380 over 3-5 working days: a responsive build, core CMS or data wiring, deployment setup, and two rounds of revisions before launch, with content and translations supplied by the client. Launch Site Express is $520 and 2 working days, the same scope in a priority queue with daily builds, a launch checklist, a handover call, and one round of revisions after the first full build.
Product Build is $880 over 2-3 weeks: feature delivery, state and route logic, testing and hardening, and two rounds of revisions per delivered feature. Native mobile apps and payment licensing are not included, which is the line to read before assuming a supplier will handle your merchant onboarding for you.
Ongoing Dev Support is $290 a month: priority updates, a weekly release rhythm and technical maintenance, billed on a monthly cycle with 30 days notice to stop, and the volume for each cycle agreed at the start of that cycle. A new build or a redesign is scoped separately rather than absorbed into the monthly fee.
Practical checklist
- List every destination one submission has to reach: your own record, email, CRM, payment provider, analytics.
- Write the field map from form fields to CRM fields before development starts.
- Issue access in the company's name rather than from an employee's personal profile.
- Put a small real payment through and find it in the provider's own dashboard.
- Fire the form-submitted event on the confirmed server response, not on the button click.
- Name the person who receives the alert when delivery fails, and agree a response time.
Questions and answers
The form submits, but no enquiries arrive. Where do I look?
Work through the destinations in order. Is there a record on your own side; what does the delivery log say about the last attempt; is the notification sitting in a spam folder; what did the CRM answer to the last request; has the access key expired. Until a log of attempts exists, each of those answers has to be dug out by hand, which turns a one-minute question into an afternoon.
What does it cost to fix an integration that has stopped working?
For contained breakages there is Site Fix Pack at $70 and 1-2 working days: up to five agreed fixes, a mobile and desktop check, a before/after list at handover, and one round of revisions. New pages, a redesign and migrations are not included, so connecting a payment provider for the first time does not fit inside that package.
Can you open a merchant account with a payment provider for us?
No. The contract is signed by your legal entity, which also passes the provider's verification and names the account that receives payouts. Product Build lists payment licensing among the items it does not include. A supplier connects an account that already exists, wires up the notification endpoint and verifies the signature on incoming messages.
What should we prepare before integration work starts?
CRM access issued in the company's name, a field map from form fields to CRM fields, pipeline rules and a named owner, company details and a refund policy for payments, and the list of questions analytics is supposed to answer. Content and translations are supplied by you; writing them is not part of the development packages.
Why do analytics numbers disagree with the enquiries we actually received?
Some visitors decline consent, some use blockers, and some browsers restrict third-party scripts. Add navigation that happens without a page reload, which a load-time counter never sees, and duplicate tags, which double the pageviews. Reconcile conversions against the confirmed server response, and compare the dashboard with itself over time rather than with your bank statement.