¿Cómo reducir el impacto de factores humanos en una tienda online?

Evitar errores del personal utilizando un nivel nuevo de validación. 11 ejemplos que puedes aplicar en tu negocio ahora mismo
01.07.2020
¿Cómo reducir el impacto de factores humanos en una tienda online?
El factor humano es la principal causa de problemas en las tiendas online. Por eso las estadísticas en el sistema no suelen coincidir, suele incrementarse el coste de envío, se puede perder la lealtad de clientes, entre otros problemas más.

Cuando una tienda online acaba de comenzar, se pueden resolver estos problemas tratando de encontrar managers responsables, pero a medida que el negocio va creciendo, se puede desarrollar un sistema para la capacitación con pruebas complejas y solo se puede unir al personal después de completar las pruebas con resultados del 100%. También se puede crear un sistema de multas, de modo que los managers lleven con mucho cuidado los datos y no se olviden de lo principal, la comunicación con los clientes y las ventas. Existe casos en que los directores de ventas realizan verificaciones manuales de cada pedido.

Para no incrementar las tareas y complicarse aún más, es posible configurar la validación en retailCRM. La validación en el sistema sirve para verificar de forma automática los cambios en los pedidos y en los perfiles de clientes realizados por los managers.

En el contenido de este artículo podrás encontrar códigos de validación listos para usar, simplemente es necesario copiar/pegar en la sección de configuraciones del sistema. Todas estas validaciones solo se pueden aplicar para el grupo de usuarios que están como "Administradores" (código de símbolo "administrador"). La información de como crear un grupo de usuarios, la puedes encontrar en nuestra documentación.

¿Cómo configurar validaciones en retailCRM?

Para crear una nueva validación, la cual servirá para comprobar algo en concreto, es necesario ingresar en la área de "Administración", después a "Ajustes", posteriormente en la sección de "Validación" y click en "Añadir".
Crear validaciones en retailCRM
Todas las condiciones serán aplicables para los pedidos. La opción de "Actividad" está marcada por defecto.
Crear validaciones en retailCRM
En el campo "Nombre" debemos de escribir el nombre de la validación. Más adelante, los ejemplos pueden ser utilizados para copiar/pegar el nombre.

El "Código simbólico" es un código con caracteres latinos, que permiten la sincronización con la página web y así evitar que estos llegen con errores. Se lo puede deja en blanco, el sistema creará un código de forma automática a partir del nombre de la validación.

El campo de "Condición" sirve para copiar los códigos de los ejemplos que estarán más adelante.

El campo de "Mensaje", es el texto que podrá ser visto en caso de que la validación sea activada.

11 ejemplos de validaciones

1. El manager no puede cambiar el estado de pago del pedido
Condiciones:
changeSet.hasChangedField("payments.status") and user().hasGroup("manager")
Es importante no habilitar esta validación sin antes configurar la estado de pago, ya que por ejemplo, algunos sistemas de pago cambian automáticamente el estado del pedido a "Pagado".

La validación solo funcionará en caso de que un manager cambie de forma manual el estado de pago del pedido. Es posible que el manager, al crear el pedido, establezca de inmediato el estado "Pagado", en este caso la validación no funcionará. Excluimos esto de la siguiente manera.
2. Pedido agregado con estado "Pagado"
Condiciones:
((changeSet.isCreate() or order.status.code == "new")
and order.payments | contains(item => item.type.code == "bank-card"
and item.status.code == "paid"))
La validación funcionará si a un pedido que se encuentra en estado "Nuevo", el manager agrega como forma de pago "Tarjeta bancaria" inmediatamente cambia el estado de pago a "Pagado".
3. No guardar un pedido sin indicar la forma de pago
Condiciones:
(order.payments | length) < 1 and user().hasGroup("manager")
La validación funcionará si el manager se olvidó agregar el método de pago por el pedido.
4. Cuando hay una diferencia entre el importe recibido y el importe total del pedido
Condiciones:
not (order.payments | reduce( (sum, x) => sum + x.amount ) == order.totalSumm) and user().hasGroup("manager")
No se puede editar y guardar los cambios si el manager agregó el importe recibido, pero este es diferente al importe total del pedido. Así se excluye el riesgo de no recibir el total del importe por el pedido.
5. Los managers no pueden hacer descuentos en los pedidos o cambiar la suma total en los pedidos
Condiciones:
changeSet.hasChangedField("total_summ") and user().hasGroup("manager")
La validación funcionará si el manager cambia el monto total de la orden, por ejemplo, le da un descuento. Esto también funciona si se cambia el importe por la entrega.

Incluye a los pedidos que provienen directamente desde la página web con el estado "Pagado" y los managers no intentan realizar Upsells relacionados con el pedido.
6. No traspasar pedidos que aún no han sido pagados
Condiciones:
changeSet.hasChangedField("status")
and changeSet.newValue("status").code == "assembly"
and order.payments | contains(item => item.type.code == "bank-card"
and not item.status.code == "paid")
La validación funcionará si el estado del pedido cambia a "Preparando el pedido" (código "assembly") y la forma de pago es con tarjeta bancaria (código "bank-card"), pero el estado de pago del pedido no es el de "Pagado" (código "paid").
7. No hacer cambios en pedidos que están siendo preparados o están en proceso de ser repartidos
Condiciones:
order.status.groupCode in ["assembly", "delivery"]
and changeSet.isUpdate()
and user().hasGroup("manager")
La validación funcionará si el pedido se encuentra en alguno de los estados del grupo "Preparando" (código "assembly") o "Entrega a reparto" (código "delivery") y el manager quiere realizar cambios en el pedido.
8. Nunca enviar a preparar un pedido, sin antes haber elegido la forma de entrega
Condiciones:
changeSet.hasChangedField("status")
and changeSet.newValue("status").code == "assembly"
and not order.deliveryType
La validación funcionará si el pedido se encuentra en el estado "Preparando el pedido" (código "assembly") y no se ha especificado el tipo de entrega.
9. No se pueden guardar cambios en los pedidos sin antes haber escrito un comentario con respecto al estado del pedido
Condiciones:
order.status.code == "cancel"
and not order.statusComment
La validación funcionará cuando el estado del pedido es cambiado a "Cancelado" (código "cancel") si el manager se olvidó escribir un comentarios sobre el estado "Cancelado". Es en especial importante para realizar el control de calidad, se recopilan los comentarios y se puede hacer una análisis.
10. Si el cliente tiene la etiqueta "BAD", prohibir el envío del pedido sin antes recibir el 100% del pago por este
Condiciones:
order.customer.bad
and order.payments | contains( item => item.type.code == "cashondelivery"
and item.status.code != "paid")
and changeSet.hasChangedField("status")
and changeSet.newValue("status").code == "assembly"
La validación funcionará si el cliente lleva en su perfil la etiqueta "Bad" y la forma de pago del pedido es a contrareembolso (código "cashondelivery"). Para clientes con esta etiqueta, los pedidos son enviados sólo después de haber realizado el importe.
10. Si el cliente tiene la etiqueta "BAD", prohibir el envío del pedido sin antes recibir el 100% del pago por este
Condiciones:
order.quantity < 1
and not order.status.groupCode == "cancel"
La validación funcionará si el manager intenta guardar cambios en los pedidos, pero en estos no existe ningún artículo, sólo se excluye cuando el pedido está con el estado "Cancelado" (código "cancel").
Evalúe el artículo
Compartan el artículo en redes sociales
Conoce cómo retailCRM puede beneficiar tu negocio
Te realizamos una demostración individual de cómo se resolverán las tareas con el sistema, para garantizar el crecimiento de tu negocio