A person fills the form, taps the button, and sees thank you. A few minutes later the manager opens the list the team actually works from. The new row is not there. In the chat someone says the site lost the lead, and the next sentence is usually a request for a new form, a new plugin, or a new contact page. That request is early. Thank you on the site and a ticket in the working list are two results. This note is only about the gap between them.
Other notes on this site cover a wider quiet week, and one submission that never reaches any inbox at all. Use those when you still do not know whether the person waited, whether the button lied, or whether nobody called a row that did arrive. Stay here when the confirmation is already visible and the working list is still empty for that same attempt. Do not fold this into a redesign conversation until you have watched one submission land, or fail to land, in the exact view the manager uses to call.
1. The confirmation and the ticket are different results
The site can render thank you from its own response. The ticket is a row that a person at the company can open, assign, and call. Those steps do not share a fate. The code that changes the screen can run even when the code that creates the row never runs, or runs and is rejected. A screenshot of thank you proves what the person saw. It does not prove that a phone number exists in the list.
Teams argue because the two results arrive in different rooms. The person who submitted is looking at the site. The manager is looking at a filtered view in the CRM. Both can be telling the truth about their own screen. The argument starts when someone treats the first screen as proof of the second. It is not. A lead, for this check, is the row. Thank you is a message.
If the person never saw thank you, and the button spun until they left, you are in a different failure. Time that click before you blame the CRM. If thank you never appears and a row still shows up, the form may be saving while the message is late. That is also a different failure. The case on this page is the awkward middle: the person saw thank you, and the working list has no ticket for the name and phone they just typed.
2. Name the working list before you name the bug
Say the words the manager would use on a Monday morning. Which pipeline. Which status counts as new. Which owner. Which filter is on by default. "The CRM" is a product. The working list is one screen. If two people on the team would open two different screens, you do not have a shared definition yet, and a missing ticket might be a ticket in the other screen.
Write down who opens that screen, and how many minutes after a real inquiry they open it. A row assigned to a former colleague, a row in a status the default filter hides, and a row in a second pipeline all look like "no ticket" to the person who only checks their own open list. The integration did not necessarily drop the lead. The view dropped it.
A notification is not the list. An email that says a form was sent is not the list. A dashboard number is not the list. For this check, open the screen where someone would type a call outcome. If that screen has no row, you have the mismatch. If that screen has a row and nobody noticed, you have a viewing problem, and a new form will not teach the team which filter to clear.
3. Why thank you can appear while the ticket never opens
The usual split is timing. The site decides the attempt succeeded, then a later step talks to the CRM. If that later step is a background job, the person already saw thank you before the job ran. When the job fails, the screen does not go back and retract the message. The manager sees an empty list. The person who submitted has already closed the tab. Nobody is looking at the failed job unless someone goes to find it.
The CRM can also refuse the payload after the site has already said yes. A required field on the ticket has no value because the form never asked for it. A phone number arrives in a shape the CRM will not store. A picklist value from the site is not one of the allowed values. The connector logs an error, or it does not. Either way the person saw thank you. Search the log for that one attempt before you rewrite the form. The error text is the specification. A new layout that sends the same payload will get the same refusal.
A duplicate rule can hide the row on purpose. Someone tested twice with the same phone, the second attempt matched an old ticket, and the working list still shows yesterday's status. The team calls that a lost lead. It is a match against an old row. Search by the test phone with filters off before you conclude the create step is dead. Look at closed and spam statuses too. A rule that files website tickets as spam will keep the list clean and the ads useless.
Wrong destination is the last common shape. The row is created in a pipeline the sales team does not open, under an owner who left, or in an account that belongs to a different brand on the same CRM. The connector's success is real. The working list is still empty. Write the pipeline name and the owner onto the note for the test. If you cannot say them, you are not ready to judge the form.
The wider trail, from the button through mail and hand-copying, is what to follow when a lead never arrives. The five breaks that make a whole week look quiet are the checks before a redesign. Stay narrower here. You already know the person saw thank you. You are looking for the ticket.
4. One submission, then the list
Use your own phone number and a name you can search. Submit once. Do not submit a second time to "be sure" until you have searched, because the second attempt can trip a duplicate rule and confuse the result. Note the clock time. Note whether thank you appeared, and whether it appeared before any waiting indicator finished. Then open the working list with filters wide enough to see a new row, a closed row, and a row owned by someone else. Search the phone.
You want one sentence at the end. Either the row exists and the usual view hides it, or the row was refused for a named reason, or the create step never ran after the site said thank you. Each sentence has a different fix. Hiding is a filter or an owner. Refusal is a field or a value. A create step that never ran is a job, a timeout, or a connector that reports success too early. A new form is not on that list until you know which sentence is true.
If a person still copies from mail into the CRM after the row should have been created, write down the fields they type. That copy is a second product. The thank-you message can be honest about the mail and still leave the working list empty until someone pastes. Fix the paste, or stop telling the team the list is automatic. The map of that hand-off is what usually breaks when a form should create the card.
5. What to write down before anyone prices a rebuild
Keep the note short enough to paste into a task. Time of the attempt. The phone you used. Whether the person saw thank you. The name of the view you searched. Whether a row existed. If it did not, the error text, the pipeline you expected, and the owner you expected. Attach nothing private from a real customer. This test uses your own number for a reason.
Leave campaign reports out of the note. A report can count a thank-you view and still be right about the view while the list is empty. Do not let that number decide the budget for a new page. Decide from the row. If the row is missing, the campaign is buying a confirmation, not a ticket the team can call.
When to ask for help
You can run this test in one sitting if you can open the working list and the connector log. Ask for help when thank you appears, the list stays empty, and nobody can find an error for that minute. Ask when the row appears in a pipeline the team does not use and the connector has no obvious place to set the destination. Ask when a background job fails only sometimes, so a single lucky test looks fine and Monday does not. The work is to make the confirmation and the ticket agree, not to draw a new form.
Services cover that path from the submission to the list someone already calls from. Selected work keeps each result next to the operation that produced it. A thank-you page with no ticket in the list is the gap that request automation into CRM closes. If you write, send the view name, what the person saw after one test, and what the list showed for that phone. Leave real customer names out of the message.
