Recepción de pedidos en una granja pequeña

El flujo de recepción que sobrevive al contacto con los clientes es más soso que el que la gente pide. Una dirección de correo, un único sitio donde aterriza cada archivo que entra y una regla que dice que nada se lamina antes de tener número de pedido. La mayoría de las granjas dejan atrás la hoja de cálculo mucho antes de dejar atrás esa forma de trabajar.

Conviene decirlo pronto, porque decide la arquitectura: PrintStash no tiene página de subida para clientes. Todas las rutas de escritura de su API exigen una cuenta, y un enlace compartido es un GET de solo lectura. Así que la recepción es algo que montas delante de la biblioteca, y el trabajo de la biblioteca empieza en el momento en que un archivo se convierte en un modelo que puedes laminar, imprimir y al que puedes poner un coste.

Decide sin qué datos un pedido está incompleto

Elige los campos antes que el canal, porque el canal es solo una forma de recogerlos. Un pedido que de verdad puedas presupuestar necesita el contacto, los archivos, el material y el color, la cantidad, la fecha límite y una frase sobre a qué tiene que encajar o qué tiene que aguantar la pieza. Esa última evita casi todo el trabajo repetido: un soporte que va atornillado a algo necesita paredes distintas que una pieza decorativa, y los clientes casi nunca cuentan la diferencia por su cuenta.

Los dos campos que la gente olvida son los que cuestan dinero después. Pregunta quién paga una reimpresión si la pieza está bien de medidas pero el cliente esperaba otra cosa, y pregunta si ya han impreso esto antes, porque un archivo que falló en la máquina de otro suele fallar en la tuya por el mismo motivo.

Empieza con una dirección de correo

Una dirección como print@yourfarm.example y una plantilla de respuesta cubren más volumen de lo que parece. La plantilla es el formulario: las mismas preguntas, en el mismo orden, siempre, así que una respuesta o las contesta o está visiblemente incompleta.

Lo primero que se rompe no es el volumen, son los adjuntos. Los servidores de correo suelen limitar los mensajes en torno a los 25 MB, un límite que un solo STL con detalle supera sin esfuerzo, y los clientes responden mandando un enlace de Google Drive que caduca o uno de WeTransfer que caduca antes. Cuando empieces a descargar archivos de las cuentas en la nube de tres personas distintas, pasa a la opción siguiente.

Usa un buzón de archivos cuando los adjuntos dejen de servir

Un destino de subida autoalojado arregla a la vez el límite de tamaño y los enlaces que se caen. El tipo de compartición File drop de Nextcloud es lo más parecido a una respuesta hecha a medida: quien recibe el enlace puede subir a una carpeta sin ver lo que ya hay dentro, así que un enlace por cliente o uno por pedido mantiene los envíos separados sin crear cuentas. Comprobado el 19 de agosto de 2026.

Nombra las carpetas por el pedido, no por el cliente. 2026-0184-hendricks ordena, evita duplicados y sobrevive al cliente que pide doce veces. Si ya tienes Nextcloud para documentos, esto es casi gratis; si no, un servicio de formularios genérico con subida de archivos funciona y te cuesta la contrapartida de privacidad de dejar los archivos del cliente en el servidor de otro antes de haberlos mirado.

Discord, si tus clientes ya viven ahí

Para una granja que sirve a una comunidad y no a empresas, un canal donde la gente publica un STL y una descripción es la recepción con más tasa de respuesta, porque es donde ya ocurren esas conversaciones. También es la que tiene el peor historial: los hilos se van hacia arriba, los archivos adjuntos a un mensaje de Discord no son sitio para guardar nada, y una petición no tiene más estado que si te acordaste de contestar.

Trátalo como una puerta de entrada, no como una cola. Contesta en el canal y luego mueve los archivos y los requisitos a lo que sostenga el pedido, antes de comprometerte con él. Un bot que copie los adjuntos a una carpeta al recibirlos es poco código y quita lo peor del riesgo, que es la única copia del archivo de un cliente viviendo en un registro de chat.

Meter los archivos en la biblioteca

Cuando los archivos aterrizan en algún sitio que controlas, hay que convertirlos en modelos. A mano, eso es una subida en la que fijas la colección y las etiquetas a la vez. Las colecciones son la frontera de permisos en PrintStash, así que una colección por cliente tiene sentido cuando tienes unos pocos clientes recurrentes y alguien de fuera necesita acceso solo a sus archivos. Más allá de eso, una sola colección customer-work con una etiqueta por cliente escala mejor que un árbol de cuarenta ramas, y el montaje para un makerspace explica cómo se comportan los roles View, Edit y Admin en cuanto hay más de una persona.

Si los archivos llegan a una carpeta, un script gana a los clics. Crea una clave de API con nombre en Ajustes -> Usuarios y acceso para una cuenta que tenga acceso de edición a la colección de recepción y a nada más, cámbiala por un token y envía cada archivo al endpoint de ingesta:

TOKEN=$(curl -s -X POST http://localhost:3000/api/v1/auth/login \
  -H "Content-Type: application/json" \
  -d '{"username":"intake","api_key":"<api-key>"}' | jq -r .access_token)

curl -X POST http://localhost:3000/api/v1/ingest/model \
  -H "Authorization: Bearer $TOKEN" \
  -F "file=@2026-0184-bracket.stl" \
  -F "model_name=2026-0184 mounting bracket" \
  -F "tags=customer-work,hendricks,2026-0184"

La ingesta es asíncrona y devuelve un identificador de trabajo, así que un script que tenga que informar de un éxito consulta GET /api/v1/ingest/jobs/{job_id} en lugar de dar por hecho que la subida terminó el trabajo. Automatizar con la API tiene el resto de los endpoints y el motivo por el que una clave de API es una credencial de inicio de sesión y no un token Bearer.

La otra vía es saltarse la subida por completo. Apunta un volumen compartido a la carpeta en la que escribe tu buzón de archivos y PrintStash indexa los envíos nuevos donde ya están, según un calendario. Eso deja los bytes originales del cliente exactamente donde tu política de copias de seguridad ya los cubre, a cambio de un intervalo de escaneo entre la subida y la aparición del archivo.

Seguir un trabajo del pedido al resultado

Esta es la parte para la que sirve de verdad la biblioteca. El modelo del pedido guarda la malla del cliente como origen, cada laminado adjunto como revisión de G-code con una etiqueta que dice por qué existe, y una revisión marcada como recomendada en cuanto imprime bien. En una repetición del pedido, esa revisión recomendada es la respuesta a “qué lanzamos la última vez”, que si no es una pregunta sobre el nombre de un archivo en una carpeta de hace cuatro meses.

Los resultados de impresión van en la revisión, no en el pedido: needs_test mientras lo estás afinando, known_good cuando funciona, failed en el intento que no salió. Cada trabajo de impresión registra su coste, congelado al terminar, así que un cambio en el precio del filamento el trimestre que viene no reescribe lo que este pedido te costó de verdad. Con Spoolman conectado, el coste usa el precio real de la bobina en lugar de un preajuste de material, y el consumo de filamento y la duración medidos solo vuelven de Moonraker: los proveedores en beta recurren a las estimaciones del slicer, algo que la matriz de compatibilidad desglosa proveedor por proveedor. Para presupuestar, esa distinción importa más de lo que parece: una estimación vale para el presupuesto y no vale para el margen.

Para el despacho, encola la revisión recomendada en lugar de mandarla a una máquina concreta y deja que la cola de flota la coloque, con enrutado manual, por impresora predeterminada o por la menos ocupada según cuánto control quieras.

Mandar una vista previa para que la aprueben

Antes de imprimir cuarenta unidades de algo, casi todos los desacuerdos salen más baratos si se resuelven en una pantalla. Crea un enlace compartido sobre el modelo con las descargas desactivadas y el cliente recibe una página de solo lectura con la vista previa, las etiquetas de las revisiones y los ajustes extraídos, sin cuenta y sin acceso a nada más de la biblioteca. Pon una caducidad acorde con la conversación y revócalo cuando se cierre el pedido. Enlaces compartidos con caducidad explica qué expone la página y qué no.

Con trabajo que aporta el cliente, desactivar las descargas es el valor que vale la pena tener por omisión, porque un enlace que devuelve la malla de origen es un enlace que se puede reenviar.

Lo que esto no te da

Nada de lo anterior es un sistema de pedidos. PrintStash no tiene tabla para un cliente, un presupuesto, una factura, un pedido de compra o un pago, y una colección con el nombre de un cliente no es una ficha de cliente. El estado del pedido vive en tu hoja de cálculo, en tu software de contabilidad o en un ERP de verdad, y si una granja pequeña necesita uno es un umbral real que llega más tarde que el número de impresoras que suelen citarte.

Así que la división sobre la que construir es que la recepción y el dinero pasan fuera de la biblioteca y la producción pasa dentro. Elige el canal de recepción que encaje con la forma en que tus clientes ya te contactan, y deja la biblioteca como lo que puede responder qué archivo se imprimió y cuánto costó.

Preguntas que suelen surgir

¿Pueden los clientes subir archivos directamente a PrintStash?

No. No hay ningún endpoint de subida anónimo ni orientado al cliente, y todas las rutas de escritura de la API exigen una cuenta autenticada. Los enlaces compartidos son de solo lectura y exponen un modelo. El patrón práctico es un destino de subida aparte, como un File drop de Nextcloud o un formulario, y luego una persona o un script que mueva los archivos a la biblioteca, o un volumen compartido que indexe la carpeta del buzón en su sitio para que no haya que copiar nada.

¿Cada cliente debería tener una colección o una etiqueta?

Colecciones cuando importa el control de acceso, etiquetas en el resto de los casos. La colección es donde se enganchan los permisos View, Edit y Admin de PrintStash, así que un cliente o un subcontratista que solo deba ver sus propios archivos necesita una. Si nadie de fuera de la granja inicia sesión nunca, una sola colección para el trabajo de clientes más una etiqueta por cliente se navega mucho mejor que docenas de colecciones casi vacías, y las etiquetas se pueden combinar en un filtro, cosa que un árbol de colecciones no.

¿Cómo sé lo que costó un pedido de verdad y no lo que presupuesté?

Cada trabajo de impresión guarda su coste al terminar, así que el número no se mueve cuando el precio del filamento cambia después. Lo exacto que sea depende de la impresora: Moonraker informa de la duración y del consumo de filamento medidos, mientras que los proveedores en beta informan de las estimaciones del slicer, y una estimación que asumió que no habría fallos se queda corta con un trabajo que necesitó tres intentos. Registra también los intentos fallidos como impresiones, porque si no el pedido parece más barato de lo que fue y el siguiente presupuesto hereda el error.

¿Cuál es el montaje más pequeño que vale la pena hacer?

Una dirección de correo, una carpeta por pedido en almacenamiento que controles, y una biblioteca donde la malla del cliente y el laminado que funcionó vivan en el mismo modelo. Eso cubre las dos preguntas que cuestan dinero de verdad cuando no tienen respuesta: cuál es el archivo actual y qué pasó la última vez que lo imprimiste. Añade un formulario, un bot o un ERP cuando puedas señalar lo concreto que se rompió, no antes.

¿Se puede automatizar la recepción de principio a fin?

En parte. El lado de la subida se automatiza limpiamente, porque un script puede vigilar una carpeta y enviar al endpoint de ingesta con una clave de API, y los volúmenes compartidos quitan hasta ese paso. Lo que no se automatiza es el criterio: decidir si una malla es imprimible, si el material pedido le va bien a la pieza y cuánto debería costar el trabajo. Esos son los pasos en los que una granja se gana su margen, y una tubería que se los salta automatiza sobre todo la producción de presupuestos malos.

Fuentes

• La documentación de compartición de archivos de Nextcloud para el tipo de compartición File drop. Comprobado el 19 de agosto de 2026.
• Las rutas de ingesta, compartición y flota de PrintStash en la versión publicada v0.11.4, en el repositorio, para el requisito de autenticación en las rutas de escritura y los endpoints de compartición de solo lectura.
• La referencia de la API y la matriz de compatibilidad de PrintStash para el detalle de los endpoints y los valores medidos por proveedor.