Construir un sistema de rendición de cuentas permanente que rastree los problemas de vivienda a través de los cambios de propietarios, administradores e inquilinos, creando evidencia para la organización y asegurando que los problemas no se pierdan por el camino.
Por qué esto es importante
Problema Actual
No tenemos una forma organizada de hacer seguimiento a los problemas de los inquilinos. Usar una lista de verificación básica o una base de datos de Excel significaría que cuando los propietarios venden o cambian de administradores, perderíamos la capacidad de atribuir los historiales de quejas a las personas correctas.
Impacto
Aunque podamos empezar a resolver problemas a corto plazo, perderíamos la capacidad de construir sobre nuestro trabajo a lo largo del tiempo.
Solución
Crear una base de datos que preserve las relaciones a lo largo del tiempo.
Lo que estamos (intentando) construir
Diseño del núcleo de la base de datos
Hacer seguimiento de cuatro entidades clave: Inquilinos, Propiedades, Propietarios, Administradores
Preservar las relaciones históricas (quién fue dueño de qué y cuándo)
Vincular las quejas a todas las partes relevantes en el momento en que ocurrieron
Sistema de seguimiento temporal
Los registros sobreviven a las ventas de propiedades
Las quejas siguen a los propietarios a nuevas propiedades
Los patrones de las empresas de administración son visibles en todos sus clientes
Pista de auditoría
Cada entrada es rastreable: quién la recopiló, la informó y cuándo
Documentar qué soluciones funcionaron para problemas específicos
Capacidades clave
Permitirnos encontrar patrones
“El 80% de las propiedades del Propietario X tienen problemas de mantenimiento”
“La empresa de gestión de propiedades Y acosa a los inquilinos en múltiples propiedades”
“El edificio Z tiene problemas de plagas independientemente del propietario”
Permitirnos actuar estratégicamente
Identificar a los peores propietarios/administradores para campañas dirigidas
Predecir problemas futuros basados en cambios de propiedad
Conectar a inquilinos que enfrentan problemas similares
Implementación
Puntos de integración
Solidarity.Tech: Herramienta de sondeo y comunicación con los inquilinos. Puede albergar datos de encuestas relacionadas con los inquilinos.
Foro de Discourse: Tratar los problemas como tickets a los que se les puede dar seguimiento.
Flujo de trabajo de asignación: Asegurar que al menos un miembro de WCU sea asignado a un problema y sea responsable de mantener a los inquilinos informados.
Flujo de datos
Nuevo inquilino → Vincular al edificio/propietario → Recopilar problemas/asuntos
Problema reportado → Se crea un hilo en el foro → Se asigna a un miembro de WCU
Las asociaciones de inquilinos pueden ver/crear hilos para sus edificios
Próximos pasos
Próximos pasos iniciales
Base técnica
Elegir la tecnología de la base de datos
Crear un repositorio de control de versiones
Documentar las decisiones del modelo de datos
Diseño del esquema central
Definir las tablas mínimas viables (Membresía de WCU, personas, propiedades, unidades, problemas)
Implementar campos temporales
Diseñar campos de auditoría (creado por, modificado por/en)
Mapeo inicial de datos
Exportar datos del condado
(Quizás) Incorporar datos de PropertyRadar
Exportar datos de solidarity.tech
Identificar cómo se deben limpiar los datos, mapearlos a los campos y usar n8n para automatizar la migración de datos
Línea base del MVP
Determinar cuál es el nivel de referencia para el desarrollo del MVP
Estoy medio trabajando en otro proyecto que intenta hacer conexiones entre los datos estatales y locales en CO. Es muy molesto intentar hacer coincidir los datos del estado para un negocio en particular con los datos del municipio. NYCDB es la inspiración, pero NYC tiene datos buenos y limpios, pero incluso así están usando búsqueda difusa para conectar nombres y direcciones entre conjuntos de datos. GitHub - nycdb/nycdb: Database of NYC Housing Data
Pero si tuvieras un modelo de datos básico que pudieras normalizar a través de conjuntos de datos variados, y luego acotado a regiones particulares, podrías hacer un sitio simple que liste los apartamentos/propietarios/administradores de propiedades y simplemente dejar que la gente comente en él. Podría despegar como una forma de quejarse de tu arrendador, lo que podría ayudar a los organizadores de inquilinos. Tengo que revisar las reseñas de Google para ese tipo de información.
Aquí hay alguna información de otra persona sobre una encuesta que usaron:
Aquí hay un diagrama. Bastante básico. Hay una encuesta, que tiene preguntas, que tienen respuestas. Hay respuestas de la encuesta para la encuesta, que tienen respuestas asociadas con las preguntas de la encuesta. Algunas características:
survey_questions.required permite requerir una respuesta a la pregunta
survey_questions.kind puede ser algo como ‘opción única’, ‘opción múltiple’, ‘respuesta abierta’. Tendrías algo de lógica en tu aplicación para asegurar que las preguntas de opción única solo tengan una única respuesta.
survey_response_answers.answer_given es para preguntas de respuesta abierta, donde la persona que responde la encuesta puede rellenar con comentarios o lo que sea. También permite que la persona que responde la encuesta dé una explicación para las respuestas de opción única y opción múltiple.
survey_questions.sequence y survey_answers.sequence es para mostrarlos en un orden específico cuando se visualizan
¡La estructura de la base de datos se ve genial! Me gusta cómo los contratos de arrendamiento, las quejas y los ID de los inquilinos están todos vinculados. Sin embargo, antes de profundizar en más detalles de nuestra base de datos, creo que deberíamos examinar los datos del condado y del estado. Esto debería darnos una buena idea de qué tan bien se pueden conciliar sus conjuntos de datos y si nuestra base de datos cubre la información esencial para la TU.
Por ejemplo, basándonos en los registros comerciales de una semana del estado, no solo tenemos el nombre de la persona asociada a una corporación/LLC/LP, sino también su estado y dirección postal (junto con mucho más). ¿Cuánta de esa información deberíamos tomar? Publiqué los datos de muestra en esta publicación por si alguien quiere consultarlos. Lamentablemente, si queremos obtener todos los datos del estado, parece que cuesta 100 $. (Pregunté a los colaboradores de Evictorbook si podían proporcionarnos sus datos, pero hasta ahora no he recibido respuesta).
En cuanto a las quejas sobre propiedades, parece que hay dos vías que podemos tomar para recuperar datos: la ciudad y el condado. La Ciudad de Stockton parece tener un proceso bastante simple. Solo tienes que rellenar un formulario que he adjuntado en esta publicación y enviarlo por correo electrónico a NSS@Stocktonca.gov. Su personal me ha informado que lo más probable es que no haya ningún costo si pueden enviar los datos electrónicamente. Sin embargo, no han respondido si pueden enviar todos sus datos sobre el cumplimiento de códigos activos y anteriores, por lo que podría no valer la pena solicitar una base de datos debido a los costos potenciales, como ocurre con el estado. El departamento de cumplimiento de códigos del condado también parece gestionar las quejas sobre propiedades, pero no he encontrado un formulario de solicitud de información en su sitio web. Tendré que llamar a su oficina y preguntar al respecto más adelante.
Una última cosa que quería añadir. Conciliar los datos de las parcelas fiscales del condado y los datos de las corporaciones del estado parece una tarea abrumadora debido a las posibles discrepancias de caracteres entre el “OWNENAME” de la parcela fiscal y el “ENTITY_NAME” del estado. Podría intentar un algoritmo simple de búsqueda de cadenas una vez que tengamos todo el conjunto de datos, pero pensé que Joseph podría tener una mejor manera de automatizar esta conciliación.
A continuación se muestra un ejemplo de queja que recibimos de la oficina del registrador para CalVilla, pero las extrajimos individualmente. Me pregunto si nos darían solo los PDF en lugar de algún tipo de hoja de cálculo si los solicitamos en grandes cantidades.
