Formulari rebut, lead perdut: conciliació entre WordPress i CRM

El formulari celebra «enviat». Comercial pregunta on és la consulta. Entre aquestes dues escenes pot haver fallat una notificació, una integració o simplement l’assignació de la feina. Per investigar un lead que no apareix al CRM, convé conciliar les entrades rebudes amb allò que l’equip pot tramitar. Aquesta guia proposa un informe per identificador i període, amb un exemple original descarregable. Ajuda a delimitar el diagnòstic entre WordPress i vendes sense donar per perduda una consulta perquè no apareix en una pantalla.

Comença pel tram que pots demostrar

Identifica què vol dir rebut a la teva instal·lació: entrada desada, resposta del servidor, acceptació d’un proveïdor o registre al CRM. Cada evidència té un abast. La documentació de wp_mail() explica que un resultat cert no acredita la recepció del correu pel destinatari. Una notificació visible tampoc demostra que la consulta tingui responsable comercial.

Si encara no pots localitzar l’entrada o el missatge, fes servir la guia per rastrejar el formulari fins a la bústia final. Aquí partim d’un període d’entrades identificables i en revisem el destí. El pla de proves de formularis per al 2027 ajuda a preparar una comprovació futura; aquesta conciliació analitza registres i pendents d’un tall concret.

Defineix quines consultes haurien d’arribar al CRM

Escriu la regla d’elegibilitat: formulari, idioma, servei triat i condicions que activen la integració. Algunes entrades poden ser proves, spam, sol·licituds de suport o rutes que acaben en un altre sistema. Conserva el motiu de cada exclusió. Comparar totes les entrades amb una única cua comercial pot generar absències aparents que el procés previst explica.

La documentació de webhooks de Gravity Forms descriu peticions configurades mitjançant feeds i condicions. És una referència d’aquest complement, no de tots els formularis. Demana al responsable de la integració la regla vigent i la versió abans d’interpretar un registre absent. Una exclusió prevista i una transferència fallida necessiten investigacions diferents.

Acorda període, tall i temps d’espera

Utilitza la mateixa zona horària i declara els límits del període. Una exportació d’entrades creades avui i una altra de contactes modificats avui poden descriure conjunts diferents. També importa el moment d’extracció: una consulta rebuda fa dos minuts podria continuar dins del temps previst per a una integració en cua.

Separa el marge tècnic per aparèixer al destí del termini operatiu perquè algú assumeixi la consulta. A l’exemple fixem deu minuts per a recepció i trenta per a l’acusament operatiu des de l’arribada al destí. Són regles fictícies de classificació, sense calendari laboral. En un encàrrec real cal acordar horaris, excepcions i quin esdeveniment constitueix aquest acusament; no equival necessàriament a contestar el client.

La unitat que concilies ha de representar una consulta

Un contacte pot enviar diverses consultes vàlides. Comptar contactes nous no sempre permet comptar formularis atesos. HubSpot documenta la deduplicació de contactes per email i l’actualització del contacte existent en determinats enviaments. L’activitat o registre que conserva cada consulta depèn de la configuració concreta.

Defineix quina unitat de feina esperes: activitat, tiquet, sol·licitud o un altre objecte relacionat amb l’entrada. A l’exercici hi ha una unitat per enviament elegible. Dos enviaments poden compartir contacte i continuar necessitant dues actuacions. Desa un identificador de correlació per seguir cada consulta; l’email d’una persona no és, per si sol, un identificador únic de consulta.

Conserva el context de l’identificador d’origen

Un número d’entrada pot ser únic només dins d’una web o instal·lació. Dues webs poden tenir l’entrada 42. Inclou el context necessari per distingir-les: lloc, formulari i identificador d’enviament, o una clau de correlació acordada. Conserva’n el significat durant el traspàs i la relació amb l’objecte de destí.

Si la integració no exposa la relació, registra-ho com una mancança d’investigació. Una hora o un email coincidents poden ajudar a localitzar un candidat; documenta com el responsable confirma que correspon a aquella consulta. Evita convertir una coincidència plausible en una recepció verificada. És rellevant quan diversos formularis comparteixen bústia, hi ha una migració o conviuen importacions històriques i consultes actuals.

L’exemple: set entrades i set files no tanquen el compte

Vam preparar set entrades fictícies elegibles, E01 a E07, i set files de destí. Les files representen unitats de feina; una consulta duplicada ocupa dues files. Simulem un tall el 20 d’octubre de 2026 a les 12:00 UTC. E06 acaba d’entrar a les 11:58. E01 i E07 comparteixen CONTACT-1, però corresponen a consultes diferents.

Vam executar una unió per identificador i una classificació local. El resultat retorna cinc excepcions per revisar, una entrada pendent dins del marge i dos registres amb el resultat previst. No vam accedir a WordPress, correu, CRM ni vendes per executar l’exemple; no acredita pèrdua o recuperació de leads reals. La classificació mostra la primera excepció aplicable a cada identificador.

Descarrega l’exemple original: tres CSV i notes en anglès, amb dades fictícies. Inclou entrades, unitats de destí i informe per revisar la correspondència. No és un paquet d’importació per a un CRM de producció.

Una absència necessita confirmar l’abast de les exportacions

Abans d’atribuir E03 a la integració, revisa filtres, permisos, paginació i dates dels dos conjunts. Comprova si el registre s’ha arxivat, s’ha actualitzat en un altre objecte o queda fora de la vista de l’usuari. Conserva l’identificador cercat i quins sistemes s’han inspeccionat. «No trobat en aquesta exportació» és una observació més precisa que «lead perdut».

Quan l’absència està acotada, segueix el tram que falta: regla que s’havia d’activar, execució del connector, resposta i registre final. Una resposta HTTP correcta s’ha d’interpretar segons l’API i l’operació. Demana l’identificador de destí o l’evidència de processament corresponent. Un log d’enviament sense resultat correlacionable deixa una comprovació oberta.

Investiga duplicats sense esborrar consultes diferents

A E02 hi ha dues unitats per al mateix identificador d’enviament. A E01 i E07 hi ha dues consultes del mateix contacte. Són situacions diferents dins del model acordat. Revisa si el connector ha reintentat una petició, si un altre flux ha processat la mateixa entrada o si l’exportació repeteix una fila. L’informe ha de conservar els IDs dels dos registres.

Abans de fusionar o eliminar, acorda quin registre conserva l’historial i quines tasques associades podrien canviar. Recuperar una fallada d’integració exigeix comprovar efectes previs per evitar repetir feina. L’exercici descarregable classifica files; no executa reintents, fusions, eliminacions ni proves d’idempotència d’una API.

Un registre creat pot continuar fora de l’abast de vendes

Per a E04, comprova la regla d’assignació i si el destí esperat és una persona o una cua atesa. Després demana a algú amb el rol operatiu previst que trobi el registre i el pugui tramitar. Un nom en un camp no acredita, per si sol, que l’equip hi tingui accés o que la cua s’estigui revisant.

A E05 falta l’acusament definit a l’exemple. En el procés real, diferencia assignació, obertura, assumpció de feina i resposta al client. Decideix quin esdeveniment cal observar i qui el pot confirmar. Una captura del panell pot aportar context; el tancament requereix l’evidència acordada per a aquella consulta.

Conserva els pendents sense declarar-los fallades

E06 té dos minuts d’antiguitat i un marge fictici de deu. Mantén la referència pendent i programa la revisió següent segons el procés acordat. Si supera el marge, torna a inspeccionar el destí abans de reclassificar-la. Aplica la mateixa regla temporal a la cohort, amb les excepcions explícites.

E99 planteja una altra pregunta: hi ha una unitat sense entrada correlacionada a la mostra. Pot requerir revisar un període més ampli, un altre formulari, una creació manual o un error d’identificació. L’exemple no demostra quina és la causa. Conserva aquesta incertesa i el responsable de resoldre-la a l’informe.

Converteix cada excepció en una incidència verificable

Una fitxa útil identifica origen, destí, regla esperada, observació, evidència i responsable. Afegeix quin canvi es proposa i quina comprovació tancaria el cas. Per a E04: entrada localitzada, unitat sense assignació; revisar la regla de la ruta; després de corregir-la, comprovar responsable i accés operatiu amb una consulta de prova acordada.

Separa corregir el registre afectat de corregir la regla que l’ha produït. Reassignar una consulta pot recuperar-ne l’atenció mentre l’enviament següent repeteix el problema. Després de reparar, revisa la cohort afectada i executa una comprovació controlada del recorregut. L’informe ha de mostrar què s’ha resolt i què continua pendent.

Demana una mostra petita que permeti investigar

Per a una primera revisió, n’hi ha prou amb identificadors i observacions que expliquin la relació entre sistemes. Evita afegir missatges de clients, contrasenyes o tokens a l’expedient compartit. El responsable de cada eina pot aportar una evidència acotada sense exportar tota la base comercial.

Si cal una prova nova, acorda identitat, destins, efectes i manera de reconèixer-la. La guia per verificar conversions sense generar feina comercial de prova ajuda a preparar aquesta part. Un esdeveniment d’analítica serveix per estudiar la mesura; no substitueix la conciliació del registre operatiu.

Demana un informe que un altre equip pugui reproduir

Registra com s’ha obtingut cada exportació: objecte, camp de data, filtres, moment d’extracció i límits de permisos. Identifica la versió de les regles d’elegibilitat i espera. Conserva els IDs d’origen d’una excepció encara que després en canviï el responsable. Així els equips de web, connector i CRM poden discutir la mateixa observació.

Per a cada pendent, identifica qui aportarà l’evidència següent i quina condició permet tornar-lo a revisar. Un traspàs útil diferencia dades inspeccionades, l’explicació d’un company i la reparació proposada. Les comprovacions posteriors han d’afegir les observacions sense substituir l’historial de la troballa inicial.

Què cal demanar al proveïdor i quan repetir la conciliació

Demana un abast que separi extracció, comparació, diagnòstic de WordPress, revisió del connector i validació del CRM. El lliurament hauria d’incloure regles d’elegibilitat, període, resultats per referència, responsables, canvis realitzats i comprovacions de tancament. Si falta accés a un tram, cal identificar qui n’aportarà l’evidència.

Després pots convertir l’informe en una rutina quan canviïn formularis, destinataris, integracions o regles comercials. La guia de monitorització del lliurament ajuda a triar cobertura i resposta. Repetir una conciliació té sentit quan l’equip sap què ha de revisar i qui actuarà sobre les diferències.

Per demanar un diagnòstic de formularis i del traspàs, envia les URLs públiques, la integració utilitzada i dues o tres referències anonimitzades que il·lustrin el problema. Delimitarem el tram WordPress i connector i què necessita confirmar el responsable del CRM. Pots consultar com s’organitzen la revisió i el pressupost abans de demanar cap intervenció.