Las secciones siguientes cubren cada una de estas tres pólizas en su totalidad, incluyendo lo que garantizan y lo que no garantizan.
Este artículo es publicado por ClassicDecoder , una empresa especializada en la decodificación de VIN clásicos y la investigación de la reconstrucción de la configuración de fábrica para vehículos antiguos y anteriores a 1981. Las correcciones ClassicDecoder no tienen costo adicional ni límite de revisiones establecido, mientras que los casos de corrección y asistencia para completar la información pueden tardar entre 24 y 48 horas, a menudo menos, y los resultados aún están limitados por la información disponible sobre el vehículo.
Las tarifas, los plazos de entrega y las expectativas de revisión se enmarcan dentro de un proceso de soporte más amplio que también incluye la revisión manual rutinaria, la finalización asistida, la revisión de correcciones y la gestión del estado revisado. Para obtener una descripción general completa, consulte Revisión, correcciones y finalización asistida Build Sheet automóvil clásico.
Sin cargo adicional por correcciones Build Sheet
Las correcciones no tienen costo adicional. Si la información de una Build Sheet entregada necesita ser revisada y modificada, ese soporte está incluido en el servicio; no hay ningún cargo adicional por reconsiderar el trabajo.
Conviene aclarar qué significa esto en la práctica. La política de gratuidad cubre el apoyo para la corrección de errores, pero no debe interpretarse como una promesa de investigación manual ilimitada. El acceso a las correcciones y la cantidad de evidencia disponible sobre un tema específico son cuestiones distintas.
La política de correcciones permite que un asunto se vuelva a presentar para su revisión sin costo adicional. El alcance y el resultado de dicha revisión dependen del problema planteado y de la evidencia disponible para abordarlo; la política no implica un compromiso de investigación ilimitado.
¿Tienes un VIN clásico para investigar?
Introdúzcalo para ver qué información del vehículo puede estar disponible.
¿Cuánto tiempo tarda el proceso de corrección y finalización asistida?
Las correcciones y los casos de asistencia para completar formularios que correspondan pueden tardar entre 24 y 48 horas, aunque suelen resolverse antes. Este es el plazo de procesamiento habitual para los casos que corresponda, no un nivel de servicio garantizado ni la promesa de que todos los problemas se resolverán en ese plazo.
Aquí es importante tener en cuenta algunos matices. Que se resuelva con mayor frecuencia no garantiza una respuesta más rápida. Además, los datos del proyecto aprobado actualmente no definen un punto de partida público para el plazo, por lo que debe presentarse como una expectativa general de procesamiento para los casos de corrección y finalización asistida que correspondan.
Una distinción merece especial atención:
| Proceso | Expectativa |
|---|---|
Casos de corrección y finalización asistida aplicables | Hasta 24 a 48 horas (a menudo se resuelve antes) |
Orden Build Sheet inicial / Primera entrega | No está cubierto por este plazo. |
Nota: El plazo de 24 a 48 horas corresponde a la corrección posterior a la entrega y al procesamiento de asistencia para la finalización del pedido. No representa el tiempo que tarda en llegar un nuevo pedido Build Sheet tras la compra. El plazo de entrega inicial queda fuera del alcance de este artículo y no se refleja en la tabla anterior.
Esta distinción es importante porque ambos plazos pueden confundirse fácilmente. Si se acaba de comprar una Build Sheet y aún no ha llegado, el plazo de corrección de 24 a 48 horas no se aplica en ese caso. Dicho plazo cobra relevancia una vez que se ha entregado la Build Sheet y se está revisando y corrigiendo un problema específico con el contenido.
Expectativas de revisión para Build Sheet corregidas
Classic Decoder no tiene límite de revisiones establecido. La política actual no especifica un número máximo fijo de correcciones o solicitudes de revisión. Si una Build Sheet aún presenta problemas sin resolver después de una corrección, puede devolverla para reportar el problema.
Dicho esto, la ausencia de un límite máximo establecido no garantiza que todos los problemas se resuelvan finalmente. El factor limitante no es cuántas veces se puede solicitar una corrección, sino si existen las pruebas necesarias para abordar una deficiencia específica. La siguiente sección explica por qué esta distinción es importante.
Por qué las revisiones no siempre pueden recuperar los datos perdidos
El acceso a la asistencia para correcciones no sustituye la disponibilidad de pruebas que las respalden. Cuando una Build Sheet contiene datos faltantes, dicha información puede complementarse tras la investigación y verificación, siempre que se disponga de las pruebas pertinentes. Si las pruebas necesarias no están disponibles o son insuficientes, el campo podría quedar sin resolver.
Esto significa que algunos campos de una Build Sheet pueden quedar sin resolver tras la revisión de correcciones. La presencia de una laguna no implica necesariamente un fallo en el proceso ni demuestra que la información histórica nunca existió; simplemente significa que la evidencia disponible no justifica una actualización más exhaustiva en ese momento. Si se dispone de evidencia pertinente, es posible complementarla.
Una Build Sheet con pocos datos no activa automáticamente una investigación más exhaustiva. Un resultado escaso no implica por sí solo un fallo técnico ni garantiza la elegibilidad para la finalización asistida. El apoyo adicional, cuando corresponda, se gestiona por separado y depende de la evidencia.
Para los lectores que deseen comprender cómo se evalúan las correcciones una vez enviadas, ese proceso se explica en el artículo relacionado. How automóvil clásico Build Sheet Corrections Are ReviewedLa información sobre el significado de las etiquetas de estado revisadas y cómo interpretarlas está disponible en Explicación de las etiquetas de estado y revisión Build Sheet revisada.