DEV Community: RepairAmigo Team

Cómo manejar equipos abandonados en un taller de reparación

RepairAmigo Team — Fri, 09 Oct 2026 05:57:13 +0000

Todo taller de reparación tiene una repisa que nadie quiere mirar. Ahí están el celular que se reparó y nunca se recogió, la laptop cuyo dueño no aceptó el presupuesto y dejó de contestar, y la consola que lleva tanto tiempo ahí que ya nadie recuerda de quién es.

Esos equipos ocupan espacio, inmovilizan repuestos y mano de obra, y generan un riesgo: el día que el cliente regresa, nadie encuentra la orden o el equipo ya no está donde debería. La buena noticia es que casi todo se resuelve con algo que no cuesta nada: reglas claras, escritas desde el principio y aplicadas igual con todos.

Importante: esta guía es orientación práctica para el mostrador, no asesoría legal. Las reglas sobre bienes no reclamados cambian según el país, el estado o la ciudad. Antes de definir plazos o decidir qué hacer con un equipo, consulte la normativa local o a un profesional de su zona.

Por qué los equipos se quedan en el taller

Entender la causa ayuda a prevenirla. Los motivos más comunes son:

El presupuesto no convenció. El cliente esperaba otro precio y prefirió no volver antes que decir que no.
La reparación tardó más de lo esperado. El cliente compró otro equipo mientras tanto.
Los datos de contacto estaban mal. Un número con un dígito equivocado o un correo que nadie revisa.
Nadie le avisó. El equipo quedó listo, pero el aviso nunca salió.
El equipo vale poco. Para el cliente, recogerlo no compensa el pago pendiente.

Varias de estas causas se resuelven en la recepción, no al final.

Paso 1: escriba su política antes de necesitarla

Una política de equipos no reclamados debe responder preguntas concretas:

¿Cuánto tiempo guarda un equipo después de avisar que está listo o que no se aceptó el presupuesto? Elija un plazo que pueda cumplir y que sea compatible con la normativa de su localidad.
¿Qué avisos enviará y por qué medios?
¿Qué pasa al final del plazo? Por ejemplo, retener el equipo hasta que se pague, aplicarlo al saldo pendiente o disponer de él según lo que permita la ley local.
¿Qué pasa con los datos del cliente que hay en el equipo?
¿Quién en el taller toma la decisión final?

Escríbala en lenguaje sencillo. Si un cliente no la entiende al leerla en el mostrador, tampoco la va a recordar después.

Paso 2: póngala en la orden de servicio y hágala firmar

Una política que solo está en un cartel es fácil de discutir. Una política que aparece en la orden de servicio, firmada o aceptada por el cliente, es mucho más clara para todos.

En la recepción:

Incluya los términos de equipos no reclamados en la orden de servicio o en el comprobante.
Léale al cliente la parte importante en una frase: "Si no recoge el equipo en el plazo indicado después de avisarle, se aplica esta política".
Pida firma o aceptación y guarde una copia.
Confirme los datos de contacto en ese momento: repita el número en voz alta y pida un segundo medio de contacto cuando sea posible.

Si todavía no tiene una orden de servicio por escrito, puede partir de nuestra plantilla gratuita de orden de servicio y agregarle su política.

Paso 3: avise en etapas, y deje constancia

Un solo aviso no basta. Defina una secuencia y aplíquela siempre igual:

Aviso de equipo listo o de presupuesto pendiente, el mismo día.
Recordatorio amable después de un tiempo razonable, mencionando el horario del taller.
Aviso formal que explique con claridad la política y la fecha en que se aplicará.
Aviso final antes de cumplirse el plazo, por el medio más confiable que tenga.

Algunas recomendaciones:

Use un tono informativo, no amenazante. "Le recordamos que su equipo está listo y que, según los términos de su orden, el plazo para recogerlo vence en la fecha indicada".
Use más de un medio si el cliente dio más de uno: llamada, mensaje y correo.
Registre cada aviso en la orden: fecha, medio y quién lo envió. Si el cliente regresa molesto, ese historial es su mejor respaldo.

Paso 4: guarde el equipo con orden mientras tanto

Mientras corre el plazo, el equipo sigue siendo responsabilidad del taller.

Etiquete cada equipo con el número de orden y guárdelo en un lugar separado de las reparaciones activas.
Guarde los accesorios junto al equipo, en la misma bolsa o caja.
Revise la repisa con frecuencia y compare lo que hay físicamente con las órdenes pendientes.
No use piezas de un equipo no reclamado para otras reparaciones mientras no se cierre el caso.

Paso 5: cierre el caso de forma documentada

Cuando se cumple el plazo, la decisión depende de su política y de la normativa local. Sea cual sea, el cierre debe quedar por escrito:

Revise el expediente completo: términos aceptados, avisos enviados y respuestas del cliente.
Haga que una persona responsable apruebe el cierre, no cualquier empleado.
Anote la decisión en la orden: qué se hizo con el equipo, cuándo y quién lo autorizó.
Proteja los datos del cliente. Si el equipo sale del taller por cualquier motivo, borre la información personal de forma segura y anote que se hizo.

Cómo reducir los equipos abandonados desde el inicio

La mejor política es la que casi nunca hay que aplicar:

Cotice antes de reparar y obtenga la autorización del cliente por escrito.
Considere un anticipo cuando haya que encargar piezas.
Avise el mismo día que el equipo está listo.
Mantenga al cliente informado si la reparación se retrasa.
Decida qué hace con los diagnósticos rechazados: cobra la revisión, la descuenta de la reparación o no la cobra, y dígalo desde la recepción.

Llevarlo a un sistema

Cuando hay pocos equipos, un cuaderno alcanza. Cuando la repisa crece, conviene un sistema donde cada orden muestre su estado, la fecha en que quedó lista y el historial de avisos. Por eso creamos RepairAmigo, un software gratuito para talleres de reparación de celulares, computadoras y electrónica, hecho en Texas, sin límite de órdenes ni de usuarios y con una edición en español aparte. Funciona como una máquina virtual de VirtualBox en la red del taller, se usa desde cualquier navegador y se instala en alrededor de una hora. Llega próximamente: puede conocerlo en repairamigo.com/es. Si tiene preguntas, escríbanos a support@repairamigo.com.

El equipo de RepairAmigo

Securing a small shop LAN app: network basics for a business VM

RepairAmigo Team — Fri, 09 Oct 2026 05:51:49 +0000

A lot of small businesses now run their core software as a virtual machine on a computer in the back room. Staff open it in a browser from the counter PC, a laptop or a phone, and the data stays in the building. That also means the shop's local network is now the front door to customer records, prices and inventory.

You don't need an IT department to lock that door. You need a handful of habits, done once and checked now and then. This checklist assumes one host machine, one VM and an ordinary small-business router.

1. Split the network: staff on one side, guests on the other

The single most useful change in most shops is a separate guest Wi-Fi.

Customers ask for the Wi-Fi password all day. If they join the same network as the business VM, their phones can see it, and so can whatever is running on those phones. Most routers offer a guest network option that isolates guest devices from the main LAN.

Turn on the guest network and give it its own name and password.
Enable client isolation or "allow guests to see each other / access local network: off," whatever your router calls it.
Put the guest password on the sign at the counter. Keep the staff password off every sign, sticky note and receipt.
Connect the host machine and staff devices to the staff network only, ideally the host by cable.

2. Give the VM an address that doesn't move

Staff bookmark the app's address. If the router hands the VM a new address after a power cut, every bookmark breaks.

Two ways to keep it stable:

DHCP reservation (preferred): in the router's admin page, find the VM's network adapter in the client list and reserve its current address. The VM keeps getting the same address, and the router still knows about it.
Static address inside the VM: pick an address outside the router's DHCP range so nothing else gets it, and set the gateway and DNS to match the router.

Write the address down in your shop's admin notes. For a business VM in VirtualBox, a bridged adapter makes the VM a normal device on the LAN, which is what makes reservations work cleanly.

3. Firewall basics: open only what staff need

On the router:

Do not port-forward the business app to the internet. A LAN app that only staff use in the shop has no reason to be reachable from outside.
Turn off UPnP unless something specific needs it. It lets devices open router ports on their own.
Turn off remote administration of the router from the internet.

On the host machine:

Enable the operating system firewall. On Linux, ufw is a friendly front end; on Windows, keep Windows Defender Firewall on for private and public profiles.
Allow only what you use: remote management from your own admin computer, if you need it at all.
Don't install extra services on the host "just in case." The host's job is to run the VM.

4. Passwords: change the defaults, separate the roles

Default passwords are printed on stickers and in manuals.

Change the router admin password and the Wi-Fi passwords from the factory values.
Use a different, long password for the host computer's admin account, the VM's system account and the app's owner account. One password everywhere means one leak opens everything.
Give each employee their own login in the app. Shared logins make it impossible to tell who changed a price or closed a ticket.
Store admin passwords in a password manager or a sealed envelope in the safe, not in a text file on the counter PC's desktop.

5. Updates without surprises

Unpatched software is how ordinary malware gets in. The trick in a busy shop is to update on purpose instead of letting updates reboot things mid-shift.

Router: check for firmware updates on a regular schedule; many routers can notify you.
Host OS: set updates to install outside business hours, and make sure the VM shuts down cleanly before the host reboots.
VirtualBox: update it during a quiet window, then confirm the VM starts and staff can log in.
The app and the VM's guest system: follow the vendor's update instructions.

Take a backup before any big update. If something breaks, you want a short path back.

6. Decide who has access, and write it down

Security in a small shop is mostly about people.

Physical access: the host machine belongs somewhere customers can't reach, ideally a locked back room or cabinet with airflow. Anyone who can touch it can unplug it, boot it from a USB drive or walk off with it.
App roles: give staff the lowest role that lets them do their job. Counter staff probably don't need to edit the price list. Technicians probably don't need to export the whole customer list.
Departures: when someone leaves, disable their app login the same day, and change any shared password they knew, including the staff Wi-Fi.
A short access list: who has the router password, who has the host admin password, who is an app owner or manager. Review it when staff change.

7. A short monthly check

Put a recurring reminder on the calendar and run through this list:

Guest Wi-Fi still isolated? Join it with a phone and confirm the business app does not load.
VM still at its reserved address?
Any new port forwards or UPnP mappings on the router?
Router, host and VirtualBox up to date?
App user list matches current staff?
Last backup restored successfully somewhere other than production?

None of this requires special gear, just settings you already have and a few minutes of attention.

Where this came from

We wrote this checklist while preparing RepairAmigo, free repair shop software made in Texas. It runs as one VirtualBox VM on the shop network and staff use it from any browser, so the advice above is exactly what we recommend to shops setting it up. We suggest a host with 16 GB of RAM, setup takes about an hour, and there are no ticket or user limits. It was built inside a busy repair shop that has processed more than 50,000 tickets with it, and there is a separate Spanish edition. RepairAmigo is coming soon; you can read more at repairamigo.com or see what free repair shop software means for us. Questions are welcome at support@repairamigo.com.

The RepairAmigo team

Cómo comunicar el estado de una reparación al cliente: mensajes, tiempos y expectativas

RepairAmigo Team — Fri, 09 Oct 2026 05:06:40 +0000

La mayoría de los clientes molestos en un taller de reparación no están molestos por la reparación. Están molestos porque no sabían qué estaba pasando con su equipo.

Un celular que tarda más de lo esperado se perdona con facilidad si el cliente recibió un aviso a tiempo. El mismo retraso, sin una sola palabra del taller, se convierte en una llamada tensa o en una mala reseña.

Este artículo trata solo de la comunicación: cómo fijar expectativas, qué decir en cada momento y cómo escribir mensajes claros. Sirve igual para talleres de celulares, computadoras o electrónica.

La expectativa se fija antes de que el equipo entre al banco

Todo lo que el cliente espere después depende de lo que escuchó en el mostrador. Si usted dice "se lo tengo rápido", el cliente imagina su propia definición de rápido.

Antes de que el cliente se vaya, deje claras tres cosas:

Cuándo tendrá noticias, no solo cuándo estará listo. "Le escribo hoy antes de cerrar con el diagnóstico" es una promesa que usted controla.
Qué puede cambiar el plan. Una pieza que hay que pedir, un daño oculto o un equipo que no enciende.
Por dónde le va a avisar. Un solo canal acordado evita mensajes perdidos.

Prometa una fecha de contacto antes que una fecha de entrega. Es más fácil cumplir la primera, y cumplirla genera confianza para la segunda.

Defina qué mensajes existen

Si cada técnico escribe a su manera, el cliente recibe mensajes distintos para la misma situación. Conviene tener un pequeño juego de mensajes base que todo el equipo use.

Los momentos que casi siempre necesitan un aviso son:

Equipo recibido.
Diagnóstico listo y presupuesto.
Reparación en curso o pieza pedida.
Retraso.
Listo para recoger.
Recordatorio de equipo pendiente.

No hace falta avisar cada movimiento interno. El cliente no necesita saber que el equipo pasó de una mesa a otra. Necesita saber cuando algo cambia para él: una decisión que tomar, una fecha nueva o que ya puede pasar.

Plantillas que puede adaptar

Escriba las plantillas una vez, revíselas con calma y úselas siempre. Algunos ejemplos:

Diagnóstico y presupuesto

Buenas tardes, [nombre]. Ya revisamos su [equipo]. Encontramos [problema en palabras sencillas]. La reparación tiene un costo de [monto] y estaría lista [fecha estimada]. ¿Desea que procedamos? Puede responder a este mensaje.

Pieza pedida

[Nombre], le confirmamos que la pieza para su [equipo] ya fue pedida. Le avisaremos en cuanto llegue. Si tiene alguna pregunta, con gusto le atendemos.

Listo para recoger

[Nombre], su [equipo] ya está listo. Puede pasar por él en nuestro horario de [horario]. Por favor traiga su comprobante de recepción.

Observe lo que tienen en común: nombre del cliente, equipo concreto, una sola idea por mensaje y un siguiente paso claro.

Cómo avisar un retraso sin perder al cliente

Los retrasos pasan. Lo que el cliente recuerda es cómo se enteró.

Algunas reglas que funcionan:

Avise antes de que venza la fecha prometida. Un aviso anticipado se lee como responsabilidad; uno tardío se lee como excusa.
Explique el motivo en una frase. "La pieza no ha llegado" es suficiente. No hace falta una historia larga.
Dé una nueva fecha o una fecha de contacto. Si no sabe cuándo estará listo, diga cuándo volverá a escribir.
Ofrezca una opción si existe. Por ejemplo, devolver el equipo mientras llega la pieza.
No culpe a nadie. Ni al proveedor ni al técnico. El cliente trató con su taller.

Un ejemplo:

[Nombre], le escribimos para avisarle que la pieza de su [equipo] todavía no llega. Esperamos tenerla [nueva fecha]. Le confirmaremos ese día cómo va. Si prefiere llevarse el equipo mientras tanto, con gusto se lo entregamos.

Palabras que generan llamadas

Algunas frases parecen amables pero dejan al cliente con más preguntas:

"Pronto" o "en estos días". Cada persona entiende algo distinto.
Términos técnicos sin explicar. "Falla en el IC de carga" no le dice nada a la mayoría. "La pieza que controla la carga está dañada" sí.
Mensajes sin acción. "Su equipo tiene un problema" obliga al cliente a llamar para saber qué sigue.
Mayúsculas y exceso de signos. Se leen como enojo o urgencia.

La prueba es sencilla: después de leer el mensaje, ¿el cliente sabe qué pasa y qué tiene que hacer? Si no, reescríbalo.

Registre cada mensaje en la orden

Un mensaje enviado desde el teléfono personal de un técnico es un mensaje que nadie más puede ver. Cuando el cliente llama, quien contesta no sabe qué se le dijo.

Por eso conviene:

Enviar los avisos desde un canal del taller, no desde números personales.
Anotar en la orden de servicio qué se avisó, cuándo y qué respondió el cliente.
Guardar las autorizaciones de presupuesto tal como llegaron.

Así, cualquier persona del mostrador puede responder con la misma información y el cliente no recibe versiones distintas.

Cuando el cliente no recoge

Los equipos olvidados ocupan espacio y generan riesgos. La comunicación también ayuda aquí:

Avise que está listo el mismo día en que termina la reparación.
Envíe recordatorios amables y espaciados, cada vez con el horario de entrega.
Si su política tiene un plazo para recoger, menciónelo desde la recepción y recuérdelo en los avisos, con tono informativo, no amenazante.
Anote cada intento de contacto. Si algún día debe aplicar su política, tendrá el historial completo.

Revise las leyes de protección al consumidor de su país o estado sobre equipos no reclamados. Esas reglas están por encima de cualquier política interna.

Una lista rápida para el equipo

Puede imprimir esto y dejarlo junto al mostrador:

[ ] ¿El cliente sabe cuándo tendrá noticias?
[ ] ¿Se acordó un solo canal de contacto?
[ ] ¿El mensaje usa el nombre del cliente y el equipo concreto?
[ ] ¿Tiene una sola idea y un siguiente paso claro?
[ ] ¿El retraso se avisó antes de la fecha prometida?
[ ] ¿Quedó anotado en la orden?

Herramientas que ayudan

Una buena comunicación depende más del hábito que del programa, pero tener el historial de cada orden en un solo lugar facilita mucho el trabajo. RepairAmigo en español es un programa gratis para talleres que se instala como una máquina virtual de VirtualBox en la red del taller y se usa desde cualquier navegador, sin límite de órdenes ni de usuarios.

Al final, el cliente no mide su taller solo por la reparación. Lo mide por cómo se sintió mientras esperaba.

Garantía en reparaciones de celulares y computadoras: cómo definirla y registrarla para evitar conflictos con clientes

RepairAmigo Team — Fri, 09 Oct 2026 05:01:15 +0000

"Usted me dijo que tenía garantía." Pocas frases ponen tan tenso un mostrador. A veces el cliente tiene razón, a veces no, y muchas veces nadie puede saberlo con certeza porque la garantía nunca quedó registrada.

En un taller de reparación de celulares y computadoras, la garantía no es solo un letrero en la pared. Es una promesa que se hace en cada orden. Y como toda promesa, funciona mejor cuando está escrita, es fácil de encontrar y todos en el taller la explican igual.

Este artículo no es asesoría legal. Las leyes de protección al consumidor cambian según el país o el estado, y siempre están por encima de cualquier política que usted escriba. Lo que sigue es un enfoque práctico para organizar la garantía dentro del día a día del taller.

El problema no es la duración, es la ambigüedad

Muchos talleres discuten cuántos días de garantía dar. Pero los conflictos casi nunca empiezan por el número de días. Empiezan por preguntas que nadie respondió antes:

¿La garantía cubre la pieza, la mano de obra o ambas?
¿Desde cuándo cuenta: desde que se recibió el equipo o desde que se entregó?
¿Qué pasa si el equipo vuelve con un golpe nuevo?
¿La garantía cubre otras fallas del equipo que no se repararon?
¿Una reparación por garantía reinicia el plazo?

Si su equipo de trabajo responde distinto a cada una, el cliente recibirá respuestas distintas según quién lo atienda. Ahí nace la desconfianza.

Defina la garantía en pocas reglas

Antes de pensar en cómo registrarla, deje por escrito unas cuantas reglas internas. No necesita un documento largo. Necesita claridad.

Qué se cubre. Normalmente la pieza instalada y el trabajo realizado en esa reparación específica.
Qué no se cubre. Daños nuevos, contacto con líquidos después de la reparación, aperturas hechas por otra persona y partes del equipo que no se tocaron.
Cuándo empieza. Lo más claro es el día de la entrega, porque es la fecha que el cliente recuerda.
Cómo varía según la reparación. Una batería, una pantalla y una reparación de tarjeta no tienen el mismo riesgo. Es razonable que tengan plazos distintos.
Cómo varía según la calidad de la pieza. Si ofrece piezas genéricas y premium, decida si tienen la misma garantía y explíquelo al cotizar.
Qué pasa con una reparación por garantía. Decida si conserva la fecha original o si empieza un plazo nuevo, y aplíquelo siempre igual.

Para los equipos que llegan mojados o con daños en la tarjeta, muchos talleres prefieren ser más prudentes. Lo importante es decirlo antes de reparar, no después.

Registre la garantía en cada orden

Una política general no basta. La garantía tiene que quedar ligada a la reparación concreta. Cuando el cliente regresa, usted debe poder responder en segundos: qué se hizo, con qué pieza, cuándo se entregó y hasta cuándo está cubierto.

En cada orden conviene registrar:

La reparación realizada, con palabras precisas: "cambio de batería", no "arreglo general".
La pieza y su calidad, por ejemplo, pantalla genérica o pantalla premium.
La fecha de entrega, que es cuando empieza la garantía.
El plazo de garantía que aplica a esa reparación.
Las condiciones especiales, como "equipo con daño por líquido: garantía limitada".
El estado del equipo al recibirlo, con fotos si es posible.

Ese último punto es clave. Si el equipo llegó con el marco doblado y eso quedó anotado, nadie podrá decir después que el taller lo dobló.

Marque las piezas que instala

Una práctica sencilla que evita muchas discusiones es marcar de forma discreta las piezas que se instalan, por ejemplo con una pequeña etiqueta o una marca interna. Así, cuando el equipo regresa, es fácil confirmar que la pieza en garantía es la misma que el taller colocó.

Avísele al cliente que lo hace. No es desconfianza: es parte de un proceso ordenado que también lo protege a él.

Explique la garantía en el momento correcto

Hay dos momentos ideales para hablar de garantía:

Al cotizar, sobre todo si el cliente elige entre calidades de pieza.
Al entregar, con el equipo funcionando frente a él.

En la entrega basta con tres frases: qué está cubierto, hasta cuándo y qué no cubre. Por ejemplo: "La pantalla que le pusimos tiene garantía hasta tal fecha. Cubre fallas de la pieza, como que deje de responder al tacto. No cubre golpes ni contacto con agua".

Si además entrega un comprobante impreso o un mensaje con esa información, el cliente tiene a la mano la misma respuesta que usted.

Cómo atender un reclamo sin discutir

Cuando un cliente vuelve con un reclamo, el objetivo es revisar con calma y decidir con base en lo registrado, no en la memoria de nadie.

Un proceso que funciona bien:

Busque la orden original. Revise la reparación, la pieza, la fecha de entrega y las notas de recepción.
Revise el equipo frente al cliente. Compare con las fotos y el estado anotado.
Confirme que la pieza es la que instaló el taller.
Separe la falla reclamada de otras fallas. Si la cámara dejó de funcionar y lo que se cambió fue la batería, son temas distintos.
Explique la decisión con hechos. "Aquí está la foto del día que lo recibimos" vale más que cualquier argumento.
Registre el reclamo. Anote qué se revisó, qué se decidió y qué se hizo, ligado a la orden original.

Si la falla es de la pieza o del trabajo, resuélvala sin rodeos. Un reclamo bien atendido suele convertir a un cliente molesto en un cliente fiel.

Si no corresponde a la garantía, ofrezca una alternativa: un diagnóstico nuevo o una cotización para la nueva reparación. Así el cliente se va con una solución, no solo con un "no".

Errores comunes que conviene evitar

Prometer de palabra lo que no está escrito. Si no está en la orden, no existe.
Dar garantías distintas según el humor del día. La consistencia genera confianza.
Usar frases vagas como "garantía total" o "garantía sin condiciones".
Ignorar la ley local. Su política no puede quitarle al cliente derechos que la ley le da. Si tiene dudas, consulte a un profesional de su zona.

Del papel al sistema

Registrar la garantía en cada orden es mucho más fácil cuando todo vive en un mismo lugar. Para eso creamos RepairAmigo, un software gratuito para talleres de reparación de celulares y computadoras, hecho en Texas, con una edición en español y sin límite de boletas ni de usuarios. Llega próximamente; conozca más en repairamigo.com/es o vea por qué es software gratis para talleres. Para dudas, escríbanos a support@repairamigo.com.

Backups people actually test: a practical 3-2-1 routine for a small business VM

RepairAmigo Team — Fri, 09 Oct 2026 04:57:46 +0000

Small businesses rarely skip backups on purpose. Someone set up a copy job once, then a drive filled up or a password changed. Nobody noticed, because nobody ever tried to restore anything.

This post assumes a common setup: one business application running in a virtual machine on a back-office computer, used by staff from their browsers. The ideas apply to almost any small server.

The rule, translated for a small shop

The classic 3-2-1 rule says:

3 copies of your data: the live one plus two backups.
2 different kinds of storage, so one failure mode can't take out everything.
1 copy outside the building, so fire, theft or a flooded back room doesn't end the business.

In a small shop, that usually becomes:

The live data inside the VM.
A copy on a NAS or a second computer on the local network.
A copy on an external drive that rotates off-site.

None of this needs special software. It does need a schedule, a written owner and a habit of checking.

Know what you are backing up

There are two different things worth protecting, and they fail differently.

The data. Customers, tickets, invoices, inventory, notes. This changes every day and is the part you truly cannot recreate.

The machine. The VM itself: operating system, application, configuration. You can usually rebuild this, but it takes time you would rather not spend on a busy morning.

That suggests two kinds of backup:

Application-level exports, taken often. If your software has a built-in export or backup feature, use it. These files are small, fast to create and usually easy to restore into a fresh install.
Full VM exports, taken less often. An exported appliance (for example an .ova file) captures the whole machine, so you can bring the system back on new hardware without reinstalling anything.

If you only do one, do the application export. A VM export without current data is just a nicely configured empty box.

Snapshots are not backups

Hypervisor snapshots are great before an update: if something breaks, you roll back in seconds. But a snapshot lives on the same disk as the VM. If that disk dies, the snapshot dies with it.

Use snapshots as an undo button, then delete them once you're happy.

A schedule you can keep

Pick a rhythm that matches how much work you can afford to redo. A reasonable starting point:

Daily: application export, copied automatically to the NAS or second computer.
Weekly: application export copied to the external drive that is currently on-site.
Monthly, or before any big change: full VM export, with the VM shut down cleanly first.

On a Linux host running VirtualBox, a clean full export looks like this:

VBoxManage controlvm "Business VM" acpipowerbutton
# wait until it is really off
VBoxManage showvminfo "Business VM" --machinereadable | grep VMState=
VBoxManage export "Business VM" -o "/srv/backups/business-vm-$(date +%F).ova"

Shutting down first matters. Exporting a running database can give you a file that looks fine and restores into a mess. Do it after closing.

Rotate the external drives

The off-site copy is the one people get lazy about, because it involves physically moving something.

Make it boring:

Buy two external drives and label them clearly, for example "A" and "B".
One stays in the shop and receives the weekly copy. The other is somewhere else: the owner's home or another trusted place.
On a set day, swap them. The drive that comes back gets the next copy; the one that leaves takes the latest data with it.
Encrypt both drives. A backup drive in a bag is customer data in a bag.

Write the swap day on the calendar. If the drive that is supposed to be off-site is sitting on the desk, the rule is broken.

Use the NAS, but don't trust it blindly

A NAS or second computer is the convenient copy: always on, always reachable, fast to restore from.

A few precautions keep it useful:

Use a dedicated account for backup jobs, with write access only to the backup folder.
Don't map the backup share as a drive letter on everyday workstations. Ransomware loves mapped drives.
Keep versions. If the NAS supports snapshots or versioned folders, turn them on, so a bad file today doesn't overwrite a good one from last week.
Prune with a rule, not by hand. Something like: keep recent daily copies, a handful of weeklies and a few monthlies. Write the rule down.

Restore drills: the part that actually matters

A backup is a theory until you restore it. The goal of a drill is simple: prove that someone other than the person who set it up can bring the data back.

A practical drill:

Pick a backup at random, not the newest one. You want to know older copies work too.
Use a spare machine or a separate test VM. Never restore over the live system to "see if it works".
Disconnect it from the shop network before starting it, or put it on an isolated network. You don't want a test copy sending notifications or fighting the real server for an address.
Import the VM or a fresh install, then load the application export.
Check real things: search for a recent customer, open a ticket from last week, compare a total against what you remember. Write down what you checked.
Time it. Not to hit a target, but so you know how long the shop would be without its system.
Delete the test copy when you are done, or keep it powered off and clearly labeled.

Rotate who runs the drill. The written steps improve every time someone gets stuck.

The monthly checklist

Put this on a single page near the server:

[ ] Latest daily export exists on the NAS and opens without errors.
[ ] Weekly copy is on the on-site external drive.
[ ] Drives were swapped on schedule; the off-site drive is actually off-site.
[ ] Free space on the NAS and external drives is comfortable.
[ ] Backup job logs show no errors or silent skips.
[ ] Monthly VM export completed after a clean shutdown.
[ ] Old snapshots removed from the hypervisor.
[ ] Passwords and encryption keys for the backups are stored somewhere the owner can reach without the server.
[ ] Restore drill done this quarter, with notes.

Sign and date it. When something goes wrong, that sheet tells you what was last known to be good.

Where this fits

If you run a repair shop, this routine fits RepairAmigo well: it is free repair shop software that runs as one VirtualBox VM on your shop network and is used from any browser, with no ticket or user limits. Setup takes about an hour.

Whatever software you use, the important part is the habit: copy, rotate, restore, write it down. Then do it again next month.

Cómo organizar el flujo de órdenes de servicio en un taller de reparación de celulares: de la recepción a la entrega

RepairAmigo Team — Fri, 09 Oct 2026 04:48:12 +0000

En un taller de reparación de celulares, casi todos los problemas con clientes se pueden rastrear hasta el mostrador. Una grieta que nadie vio, un cargador que "sí dejé", un precio que cambió sin que nadie avisara o un cliente que llamó varias veces porque nadie le dijo nada.

La reparación en sí suele salir bien. Lo que falla es el flujo alrededor de ella.

Este artículo se enfoca en esa parte: la recepción, las fotos, los accesorios, la autorización del cliente y los mensajes de seguimiento. No hablaremos de cómo diagnosticar ni de cómo nombrar los estados de cada orden, sino de cómo debe trabajar la persona del mostrador para que el resto del taller no tenga que adivinar.

La recepción es una conversación, no un formulario

El error más común es llenar la orden de servicio mientras el cliente mira su celular, con prisa y sin explicar nada. Así se pierde información que después vale mucho.

Conviene seguir siempre el mismo orden en la conversación:

Saludar y escuchar. Deje que el cliente cuente qué pasó con sus propias palabras.
Repetir la falla. "Entonces, se le cayó y desde ese día la pantalla no responde abajo, ¿correcto?". Esa frase evita malentendidos.
Revisar el equipo frente al cliente. Nada de llevárselo atrás antes de anotar cómo llega.
Explicar qué sigue. Diagnóstico, cotización, tiempo aproximado y cómo le van a avisar.

Cuando todos en el mostrador siguen la misma secuencia, el cliente recibe la misma experiencia sin importar quién lo atienda.

Qué registrar en el mostrador

No hace falta un expediente enorme. Hace falta lo que el técnico y el cliente van a necesitar después.

Datos de contacto y canal preferido. Pregunte cómo prefiere que le avisen: mensaje, llamada o correo. Anótelo.
La falla en palabras del cliente. Copie su descripción, aunque suene poco técnica. Luego el técnico agrega su propia nota.
El estado al recibir. Grietas, golpes, marco doblado, señales de humedad, tornillos faltantes o reparaciones anteriores.
Lo que se pudo probar y lo que no. Si el celular no enciende, escriba que no se pudieron probar cámaras, bocinas o carga. "No se probó" no es lo mismo que "funciona".
Bloqueos y datos. Si tiene bloqueo de cuenta y si el cliente entiende que una reparación puede borrar información.
Fecha prometida. Mejor una fecha realista que una promesa optimista.

Evite guardar contraseñas en papeles que se archivan. Es preferible que el cliente desbloquee el equipo al recogerlo o que use un código temporal.

Fotos: pocas, claras y siempre iguales

Las fotos ayudan mucho, pero solo si se toman con un método. Una foto borrosa tomada a la carrera no resuelve ninguna discusión.

Un método sencillo:

Siempre el mismo recorrido: frente, reverso, cada costado, puerto de carga y cualquier daño visible de cerca.
Con la pantalla encendida, si se puede, para mostrar manchas, líneas o zonas muertas.
Ligadas a la orden. Una foto que vive solo en el celular personal de un empleado no le sirve al taller. Guárdela junto al número de orden.

Si el cliente ve que usted toma las fotos frente a él, entiende que el taller es ordenado. Eso por sí solo reduce reclamos.

Accesorios: lo que entra debe salir

Fundas, cargadores, bandejas SIM, tarjetas de memoria y lápices se pierden con facilidad. Y cuando se pierden, la conversación es incómoda para todos.

Algunas reglas prácticas:

Pregunte si de verdad hace falta dejarlo. La mayoría de las veces la funda y el cargador pueden irse con el cliente.
Retire la SIM y la tarjeta de memoria y entréguelas al cliente, salvo que se necesiten para la prueba.
Si algo se queda, anótelo en la orden con una descripción corta: "funda negra de silicón", no solo "funda".
Use una bolsa o caja con el número de orden y mantenga el equipo y sus accesorios juntos.
Revise la lista al entregar. El cliente confirma que recibió todo antes de irse.

Autorización del cliente: clara, por escrito y con límite

La autorización es el punto donde más conflictos nacen. El cliente aceptó "arreglar la pantalla", pero el técnico encontró además un conector dañado. ¿Se avanza o se llama?

Para evitar dudas:

Cotice con detalle. Diga qué se cambia y qué calidad de pieza se usará. "Pantalla" y "pantalla genérica" no son la misma promesa.
Pregunte un monto máximo. Anote hasta cuánto puede subir la cotización sin volver a llamar al cliente. Así el técnico sabe exactamente dónde detenerse.
Pida la firma o una confirmación escrita. Si el cliente aprueba un cambio por mensaje, guarde esa respuesta en la orden.
Anote quién autorizó y cuándo. Si el equipo lo deja un familiar, registre quién tomó la decisión.

Cuando aparece un problema adicional, la regla debe ser simple: si supera el monto autorizado, se detiene la reparación y se llama al cliente. Sin excepciones.

Mensajes de seguimiento que evitan llamadas

Un cliente informado no llama para preguntar. Un cliente sin noticias llama, y cada llamada interrumpe el mostrador y el banco de trabajo.

No es necesario escribir mucho. Basta con avisar en los momentos clave:

Al recibir: "Recibimos su celular, orden número ___. Le avisaremos cuando tengamos el diagnóstico".
Con la cotización: qué se encontró, qué se recomienda, precio y tiempo. Pida una respuesta clara: sí o no.
Si hay retraso: avise antes de la fecha prometida, no después. Explique el motivo, por ejemplo, que la pieza todavía no llega.
Cuando está listo: horario para recoger y qué debe traer.
Recordatorio: si pasan los días y no recoge, un aviso amable a tiempo evita equipos olvidados en el estante.

Tenga estas plantillas escritas para que todos usen el mismo tono. Personalice solo lo necesario: nombre, equipo y número de orden.

La entrega también es parte del flujo

Muchos talleres cuidan la recepción y descuidan la entrega. Es el último momento para evitar un malentendido.

Pruebe el equipo frente al cliente: pantalla táctil, cámaras, audio, carga y lo que se haya reparado.
Entregue los accesorios que se quedaron en el taller y confirme que están completos.
Explique la garantía de forma breve: qué cubre y qué no.
Pida la firma de recibido o confirme la entrega en la orden.
Cierre la orden el mismo día. Una orden abierta de un equipo que ya se fue confunde al siguiente turno.

Llevar el flujo a un sistema

Cuando el papel se queda corto, conviene pasar este flujo a un sistema. Por eso creamos RepairAmigo, un software gratuito para talleres de reparación, hecho en Texas, sin límite de boletas ni de usuarios y con una edición en español. Funciona como una máquina virtual de VirtualBox en la red del taller y se usa desde cualquier navegador. Llega próximamente: puede conocerlo en repairamigo.com/es o ver cómo encaja en un taller de celulares. Si tiene preguntas, escríbanos a support@repairamigo.com.

Running small-business software on a LAN: a practical checklist for an always-on VirtualBox host

RepairAmigo Team — Fri, 09 Oct 2026 04:45:31 +0000

Plenty of small-business tools ship as a ready-made virtual machine: import the appliance, start it, and staff open the app in a browser from any device on the LAN. The data stays in the building and nothing gets installed on workstations.

The catch is that the VM is only as reliable as the box underneath it. A host that suspends, renumbers itself on the network, or loses power mid-write turns "the app is down" into a weekly conversation.

Here's the checklist I'd hand to anyone setting up that host. It's Linux first (any systemd distro), with short Windows notes where steps differ.

1. Firmware and hardware

[ ] Dedicated machine. Not someone's daily laptop. A plain desktop with an SSD and wired Ethernet is ideal.
[ ] Enough RAM for host plus guest. Check the vendor's sizing and add headroom for the host OS.
[ ] Hardware virtualization on. In UEFI setup, enable Intel VT-x / "Virtualization Technology" or AMD SVM / AMD-V.
[ ] Restore on AC power loss = Power On. Most boards have this under power management. It lets the host come back by itself after an outage.

Confirm virtualization from Linux:

lscpu | grep -i virtualization
# Expect "VT-x" or "AMD-V". No output usually means it is off in firmware.

Windows note: Task Manager → Performance → CPU shows "Virtualization: Enabled/Disabled".

2. Install VirtualBox cleanly

[ ] Install VirtualBox from one source (distro repo or official packages) with kernel headers and DKMS. After kernel updates, systemctl status vboxdrv should be green.
[ ] Secure Boot: if it is enabled, unsigned modules will not load. Either enroll a signing key (many distros walk you through this during install) or decide deliberately to turn Secure Boot off.
[ ] KVM conflicts: depending on your kernel and VirtualBox versions, loaded kvm_intel/kvm_amd modules can stop a VM from starting. Check with lsmod | grep kvm and resolve it before go-live, not during.
[ ] Create a dedicated, unprivileged user to own the VM, and add it to the vboxusers group.

sudo useradd -m -s /bin/bash vmhost
sudo usermod -aG vboxusers vmhost

Import the appliance as that user so the VM files live in its home directory:

sudo -iu vmhost VBoxManage import /path/to/appliance.ova
sudo -iu vmhost VBoxManage list vms

3. Never sleep

[ ] Mask the sleep targets so nothing (desktop environment, idle timer, power button) can suspend the box:

sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target

[ ] If the host is a laptop, set HandleLidSwitch=ignore in /etc/systemd/logind.conf and restart systemd-logind.
[ ] Letting the display blank is fine.

Windows note: set sleep to "Never" on AC power, disable hibernation with powercfg /h off, and set Active Hours so update restarts land outside business hours.

4. Network: bridged, with a stable address

NAT is VirtualBox's default, and it hides the guest behind the host. Other machines on the LAN can't reach it without port forwards. For a shared app you want the guest to look like its own device on the network.

[ ] Find the host's wired interface name (ip -br link), then bridge the VM's first adapter to it:

sudo -iu vmhost VBoxManage modifyvm "Shop VM" --nic1 bridged --bridgeadapter1 enp3s0

[ ] Avoid bridging over Wi-Fi; many wireless drivers handle it poorly.
[ ] Grab the guest's MAC address:

sudo -iu vmhost VBoxManage showvminfo "Shop VM" --machinereadable | grep macaddress1

[ ] In the router or DHCP server, create a DHCP reservation for that MAC. VirtualBox prints it without colons, so add them when you type it in.
[ ] Reserve an address for the host too, so you can always SSH or RDP into it.
[ ] Don't port-forward the app to the internet unless the vendor documents that setup.

5. Autostart headless with systemd

The VM should come up after every boot with nobody logged in. First, a stop helper that asks the guest to shut down gracefully and waits:

sudo tee /usr/local/bin/shop-vm-stop >/dev/null <<'SH'
#!/bin/sh
VM="Shop VM"
VBoxManage controlvm "$VM" acpipowerbutton 2>/dev/null || exit 0
for i in $(seq 1 90); do
  VBoxManage list runningvms | grep -q "\"$VM\"" || exit 0
  sleep 2
done
# Guest ignored the request: save state rather than hard power-off
VBoxManage controlvm "$VM" savestate
SH
sudo chmod +x /usr/local/bin/shop-vm-stop

Then the unit, /etc/systemd/system/shop-vm.service:

[Unit]
Description=Shop VM (VirtualBox, headless)
After=network-online.target vboxdrv.service
Wants=network-online.target

[Service]
User=vmhost
ExecStart=/usr/bin/VBoxHeadless --startvm "Shop VM"
ExecStop=/usr/local/bin/shop-vm-stop
TimeoutStopSec=300
Restart=on-failure

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now shop-vm.service

[ ] Reboot the host and confirm the app loads from another device without logging in to the host.

Windows note: a Task Scheduler task triggered "At startup", set to run whether or not a user is logged on, calling VBoxManage startvm "Shop VM" --type headless.

6. Clean shutdown, every time

With the unit above, sudo systemctl stop shop-vm or a normal host shutdown triggers an ACPI shutdown inside the guest, then waits for it. That is the only shutdown path anyone should use.

[ ] Put a note on the host: "Shut down from the OS, never the power button."

7. UPS that actually triggers shutdown

A battery that only buys time until it's flat just moves the hard power-off a little later.

[ ] Plug the host and the network switch/router into the UPS.
[ ] Connect the UPS's USB data cable to the host.
[ ] Install NUT (nut) or apcupsd, and configure it to shut the host down on low battery. Because the VM is a systemd service, the host shutdown stops the guest cleanly first.
[ ] Test it: NUT can simulate a forced shutdown with upsmon -c fsd. Do it after hours.

Windows note: use the UPS vendor's agent, and make sure your shutdown path stops the VM gracefully before Windows powers off.

8. Backups you have actually restored

Snapshots are rollback points stored right next to the disk they protect. They don't count as backups.

[ ] Prefer the application's own backup/export if it has one, and schedule it.
[ ] Also take periodic full-VM copies while the guest is stopped:

sudo systemctl stop shop-vm
sudo -iu vmhost VBoxManage export "Shop VM" -o /mnt/backup/shop-vm-$(date +%F).ova
sudo systemctl start shop-vm

[ ] Keep at least one copy off-site (a rotated USB drive works).
[ ] Restore test: import a backup on a spare machine with networking disconnected and check the data is there. A backup you have never restored is still a guess.

9. Go-live verification

[ ] Cold boot: power off at the wall, power on, and wait. The app comes back with no keyboard touched.
[ ] Address check: the app is on the reserved IP after a reboot.
[ ] Every staff device has a bookmark to that address.
[ ] journalctl -u shop-vm shows clean starts and stops.
[ ] The UPS test passed, and a restore test passed.

Wrapping up

None of this is exotic, but together it turns "the VM" into infrastructure the business can lean on.

We put this list together while building RepairAmigo, free software for repair shops that runs as one VirtualBox VM on the shop network and is used from any browser. We recommend a host PC with 16 GB of RAM, since the VM is allocated 8 cores and 8 GB. Release is coming soon; details are at repairamigo.com. Questions go to support@repairamigo.com.

The RepairAmigo Team