La señal más clara de que el registro de asistencia está fallando aparece cuando el lunes exige reconstruir el domingo a partir de chats, hojas de cálculo y recuerdos. Si nadie puede consultar un registro común y responder quién llegó, cuándo se registró y en qué actividad participó, la iglesia tiene fragmentos, no datos de asistencia.
En 1854, el médico John Snow intentaba entender por qué el cólera golpeaba con tanta fuerza una zona de Soho, en Londres. La explicación dominante atribuía la enfermedad al aire contaminado, pero Snow reunió direcciones de personas fallecidas y las colocó sobre un mapa. Al verlas juntas, apareció una concentración alrededor de la bomba de agua de Broad Street.
La famosa retirada de la manivela de aquella bomba no surgió de una intuición aislada. Surgió al reunir información que, separada, parecía una colección de casos sin relación. Steven Johnson documenta este episodio y el trabajo de Snow en su libro The Ghost Map.
El problema de asistencia de muchas iglesias tiene la misma forma, con consecuencias distintas. Los datos existen, pero viven en lugares que no permiten ver el cuadro completo.
El ritual del lunes por la mañana
El administrador abre el primer grupo de WhatsApp. Busca mensajes como “ya llegamos”, “voy con mi hermana” o “el autobús de Legon salió tarde”. Luego entra al grupo de ujieres, donde alguien compartió una foto de una lista escrita a mano.
En el tercer grupo aparecen nombres de miembros que confirmaron su asistencia. En el cuarto, un coordinador informa de varias personas que llegaron directamente al recinto. Ninguno de esos mensajes usa el mismo formato.
Después vienen las hojas de cálculo. Una contiene las inscripciones previas. Otra registra los códigos QR escaneados en la entrada. Los nombres no siempre coinciden: “Akosua Mensah” puede aparecer como “Akosua M.” en una lista y bajo un número de teléfono en otra.
La pregunta parecía sencilla: ¿quién vino?
Una hora después, la respuesta sigue siendo una estimación. El equipo sabe cuántas personas se inscribieron, cuántos códigos se escanearon y cuántos nombres circularon por WhatsApp. Todavía no sabe con certeza cuántos miembros participaron.
Esa incertidumbre se arrastra hasta la siguiente decisión. ¿Qué grupo necesita seguimiento? ¿Qué autobús tuvo ausencias? ¿Cuántas personas llegaron tarde? ¿Quién se registró para el evento, pero nunca hizo check-in? ¿A quién debe llamar un líder de grupo?
Una inscripción no demuestra asistencia
Una de las confusiones más frecuentes consiste en tratar cada lista como si respondiera la misma pregunta.
La inscripción indica intención. El check-in confirma llegada. La lista del autobús muestra quién reservó una plaza. El mensaje de un ujier puede registrar una excepción. La pertenencia a un grupo aporta contexto, pero tampoco prueba que la persona asistiera ese día.
Cuando esos registros permanecen separados, el equipo termina comparándolos a mano. Además de consumir tiempo, el proceso borra diferencias importantes. Una persona ausente puede quedar marcada como presente porque se inscribió. Otra puede haber llegado sin aparecer en el informe porque un voluntario resolvió su entrada por WhatsApp.
Un registro conectado conserva cada paso y permite relacionarlos. ChurchFlow reúne la inscripción a conferencias, el check-in mediante QR o búsqueda por teléfono, la hora y el método de entrada, los grupos del miembro y, cuando corresponde, su reserva de autobús. Así, el administrador puede distinguir entre “se apuntó”, “tenía transporte” y “entró al evento”.
Ese mismo principio aparece en cómo Kojo confirmó la reserva de Abena: la respuesta fiable surge cuando los registros se conectan alrededor de la persona, en lugar de depender de mensajes repartidos entre equipos.
Qué debe mostrar un registro común
Centralizar no significa guardar todo en una hoja enorme. Significa acordar qué hecho registra cada acción y dónde se consulta después.
Para la asistencia a un evento, el registro común debería mostrar al menos:
- La identidad del miembro.
- El evento y la inscripción correspondiente.
- Si realizó el check-in.
- La hora y el método de entrada.
- La sede o sucursal asociada.
- La reserva de transporte, si la hubo.
- Las correcciones realizadas por un administrador.
También hace falta un procedimiento para las excepciones. Si el código QR falla, la búsqueda por teléfono o la entrada manual deben actualizar el mismo registro. Crear una lista paralela para “resolverlo después” devuelve al equipo al ritual del lunes.
Conviene definir además una fuente principal antes del próximo evento. WhatsApp puede servir para coordinar una incidencia, pero el resultado debe quedar registrado en el sistema que produce el informe final. De lo contrario, la conversación se convierte en una base de datos accidental, difícil de buscar y todavía más difícil de auditar.
Del recuento aproximado a una decisión útil
John Snow pudo reconocer el patrón de Broad Street porque colocó los casos sobre una misma superficie. El mapa no creó los hechos. Los volvió comparables.
Una iglesia obtiene el mismo tipo de claridad cuando inscripciones, check-ins, grupos y transporte dejan de contarse como historias separadas. El lunes ya no comienza abriendo cuatro grupos y dos hojas para adivinar qué ocurrió. Comienza con preguntas más útiles: quién faltó, dónde se formó una cola, qué autobús quedó corto y qué miembros necesitan seguimiento.
Para avanzar, elija un próximo evento y documente su recorrido completo. Defina dónde nace la inscripción, qué acción confirma la llegada y qué registro consultará el equipo el lunes. Después elimine cada lista paralela que no tenga un propósito distinto y explícito.
El objetivo no es producir un número bonito para el informe. Es poder mirar a cada miembro como una persona concreta, con una participación verificable y un siguiente paso claro.
Comentarios
Todavía no hay comentarios.