door Adriana Treviño 4 jaren geleden
234
Meer zoals dit
En caso de solicitar recuperación de contraseña, el cliente debe capturar el correo electrónico que registro.
Recibirá por correo una liga que lo llevara una página para cambiar su contraseña, una vez que la ingresa, recibirá mensaje de éxito y tendrá acceso al App y página Web.
Por categoría y los cambios que han tenido por fecha.
Registrar fecha de cambio inicial y cuando se modificó para obtener que el punto tenga un valor distinto.
Categoria: Cerveza
Valor punto: 2%
Fecha asignación: dd/mm/aaaa
Categoria: Cerveza
Valor punto: 2%
Fecha asignación: dd/mm/aaaa (2)
En APP las promociones aparecerán en el siguiente orden:
Automatizadas (Cuando se lancen)
Basadas en Perfil
Generales
El Punch Card tendrá su propia sección a parte.
Evaluar nivel de complejidad y tiempos de desarrollo y entendiendo eso podremos decidir si sale en v1.0 o posterior.
Se requiere a Brick que ellos desarrollen las mecánicas, administración de Folio, asignación a usuarios y avisar a Kiosko será sólo un usuario de la información y realizará consultas a Brick en cada ocasión que un cliente quiera utilizar el beneficio que le otorgó la acumulación en Punch Card.
Se Considera que no se manejaran devoluciones, únicamente cambio físico
Cupones de Beneficio
Los cupones son transferibles entre usuarios
Todo Cupón de beneficio debe tener asignada una vigencia
Devoluciones
ESCENARIOS DE DEVOLUCIONES A PREVER:
- CANCELACIÓN OFFLINE???!!
-CANCELACIONES SIN APP PRESENTE
-CANCELACIÓN PARCIAL DE TICKET
-CANCELACIÓN DE UN SELLO DE UN CUPÓN YA GENERADO (ANTES DE REDIMIRLO)
No aplican devoluciones en producto que el cliente ganó mediante la redención de un PC. Lo que si se puede hacer es un cambio físico.
No habrá devoluciones de productos que otorguen sellos, sólo cambio físico
Habrá dos vigencias configurables: la de acumulación de sellos y la de redención de beneficios.
Sólo otorgan puntos de acumulación cuando los productos que otorgan sellos se adquieren con Precio > $0
Al terminar la vigencia de un periodo de acumulación de sellos se deben resetear los contadores
No debe ser posible que un SKU te otorgue sellos para dos Punch Cards distintos
La acumulación es por artículo adquirido, no por ticket
Acciones a tomar en caso posible fraude
La alarma es un correo para el equipo de administración del programa para revisar el caso sin bloquear la cuenta. También se enviará un mensaje al cliente para informar que su cuenta está en revisión. Si el comportamiento se repite se bloqueará automáticamente la cuenta y se enviará un correo a los administradores para que hagan un nuevo análisis y determinen la sanción que debe aplicarse conforme a los términos y condiciones del programa en caso de que se confirme un fraude.
No se puede redimir una PunchCard con otras promociones en el mismo ticket
No hay entregas parciales de Premios
Sólo guardará los cupones de los Punch Cards que el cliente gane.
En caso de ser necesario podremos usarla para otro tipo de Cupones..
Redimir Cupón
Mis cupones
Lista de Cupones
Filtrar Cupones
Lista de Punch Cards
Indicar status de Punch Cards:
Redimidos
Con acumulación
Activos pero no usados
Filtrar PunchCards
Por redimidos, con acumulación, etc.
Cliente quiere conocer el status de un PC
Entrar a "Mis Cupones"
Encontrar la PC a consultar
Tap sobre la PC
Se despliegan los detalles
Ver detalles
Puntos acumulados hasta ahora
Premio que otorga
Puntos totales
Configuración PC
La configuración de los PC estará a cargo de BRICK.
Para que un PC se configure, Kiosko deberá enviar un formato estandarizado vía correo electrónico en el que se especificarán los parámetros de configuración.
Eliminar PC
Editar PC
Crear PC
Beneficios que otorga (Cupón)
Regla para crear ID Cupón
Éste campo es obligatorio.
Descuento del 100% sobre el producto o productos que tendrán beneficio.
Producto que me regala
Puede ser un producto o una combinación de productos.
Regla de acumulación
Siempre se va a otorgar una unidad del proucto o productos que están definidos como PunchCard
Es el periodo de tiempo durante el cuál los clientes pueden ganar sellos.
Campo obligatorio.
De acumulación
Productos en los que aplican "Sellos"
Un grupo de SKU's te otorgan "sellos"
Tener un campo donde se pueda configurar el código o códigos que otorgan sellos por cada unidad comprada por parte del cliente de esos códigos.
Por ejemplo, cualquier galleta de la marca Gamesa te da un sello.
El usuario tendrá que especificar los códigos EAN dados de alta en Compucaja de Kiosko que otorgan el beneficio.
Pendiente de redactar.
Solicitado por Dir. Comercial.
Cliente solicita canjear un cupón de PC
Cajero le solicita el código de barras del Beneficio
Cliente muestra el código en su dispositivo
Cajero lo escanea usando el lector del PDV
PDV envía dato código de PC a Brick para Validación
BRICK regresa el mensaje que debemos transmitir al cliente
PDV despliega a cajero el mensaje
Código Valido
BRICK devuelve autorización y SKU's sobre los que aplica el beneficio
PDV muestra beneficio autorizado a Cajero
Cajero finaliza la transacción
El cajero hace la transacción y le sale un ticket especial que usa un código de salida para la baja del artículo entregado (Precio $0.00) y las condiciones como que no aplica devolución (sólo cambio físico).
Y se emite otro ticket para que el cliente lo firme y quede para el registro de la tienda.
En caso de que el cliente lleve otros productos que desea comprar y que no estén amparados por un Punch Card se debe realizar un ticket de venta normal para esos productos.
PDV envía a BRICK la información del ticket incluyen un flag de que se redimió un Punch Card y el Folio del PunchCard
Brick descuenta de cuenta del usuario el beneficio
El cliente ganará el punto de acumulación, independientemente de si el producto lo compró a precio lleno, o con descuento, etc.
En un mismo ticket el cliente no se puede llevar el café gratis y
Cliente llega a caja con sus productos
Cajero escanea el QR del Cliente
Cajero Cierra transacción que incluye un producto que otorga puntos de acumulación
PDV Kiosko reporta mediante un WS la venta a BRICK
BRICK identifica el producto y realiza la acumulación para PC de ese usuario
Requieren identificarse como miembro del programa para poderlas redimir.
Son promociones que se lanzan en periodos distintos a los de la parrilla promocional habitual y que requieren trabajarse rápidamente para que aparezcan en el app en poco tiempo (por ejemplo de 3 a 4 días).
Se tendrá una imagen genérica de imagen flash para poder ser mostradas inmediatamente, previo a la creación de la imagen final.
Una vez configuradas, esas promociones pueden caer dentro de cualquiera de las categorías normales para ser comunicadas (Generales, Perfil o Segmentación automátizada).
Admon de Promociones (Desde Kiosko)
El control de qué promociones se comunican por canal se haría desde el aplicativo de "Publicidad en Tienda".
Fase 1: Mandar un correo con las promos y si son generales o si se van a segmentar por perfil, el lineamiento general de la segmentación para que Brick haga la configuración.
Fase 2: Enviar por WS las promociones y su configuración.
Fase 3: Segmentación automatizada
Actualizar desde Kiosko
Cambios en la configuración de la promo
Viajar a APP
Actualizar contenido APP automáticamente
Control Status
Publicar / Despublicar
Canal
Combinación de algunos
Redes Sociales
Insta
FB
Web
En tienda
App
Formato de promoción
Los formatos pueden ser:
Texto
Texto con imagen
Sólo imagen
Carrusel
Posición dentro del APP
Las posiciones pueden ser por ejemplo:
Parrilla
Rappi
Conforme se acumulen datos de los usuarios se le asignará un "Buyer Persona" para mostrarle las promociones que encajen con ese perfil y nos basaremos menos en el input que nos dió inicialmente.
Debemos tener la capacidad de detectar los cambios en patrones de consumo para que un usuario pueda cambiar de Buyer Persona con el tiempo.
Se requeire establecer criterios en conjunto con Kiosko para definir parametros.
Ellos usan el número N de compras anteriores.
Requeriremos establecer los criterios para definir los Buyer Personas que funcionen para nuestra industria.
Aplicar Machine Learning a datos de usuario y patrones de compra para segmentar usuarios y asignar promociones
Estas promociones se muestran sólo a usuarios cuyos datos en su perfil de usuario que el mismo usuario otorga que coincidan con criterios establecidos en la configuración de la promoción.
--> Requiere sesión de trabajo Kiosko-Brick para definir cuáles serán los assumptions que se usarán para segmentar las promociones.
Perfil de Usuario
Pantalla de Intereses de usuario
Como complemento al perfil inicial del usuario, al momento del registro mostrar al usuario una lista de Categorias de producto en las cuáles él señale las que son de su interés.
Esta información se usará para segmentar/filtrar las promociones que se le mostrarán a ese usuario en particular.
Ejemplo de categorias:
Bebes
Cerveza
Etc.
Para poder registrarse deberá seleccionar 3 categorías.
Esto es un punto de partida para personalizar su sección de promociones independientemente de que después los segmentemos más conforme se vayan obteniendo datos históricos.
Al momento de darse de alta en el APP
Población default
Género
Se muestran a todos los usuarios.
Se puede definir el orden en el que aparecen.
Kiosko diseñará el consumo de un WS de Brick a medida que contenga la información que necesite Brick para publicar la promoción.
El sistema estaría trabajando 24/7 para informar de modificaciones, creación o cancelaciones de promociones.
La promoción se vería con una imagen genérica hasta que se sustituya la imagen en el panel de control de promociones.
La promoción debe tener etiqueta de ocasión de consumo y categoria.
--> Para diseñar la solución que nos permita compartir los elementos gráficos que requiere Brick para hacer los artes de las promociones, primero se definirá el proceso desde el punto de vista Comercial, Merca, etc. y se estudiará el caso con TI Kiosko.
Afinar el proceso en el área Comercial para minimizar modificaciones a las promociones debido a errores.
En las promociones debe ir fecha de inicio y fecha final de la promo.
--> A revisar con Brick, cuánto tiempo requiere para poder tener en las promociones "flash" creadas o modificaciones publicadas.
Consulta movimientos y acumulación puntos
Consulta puntos
Privacidad
Informar aviso de privacidad
Aplicar Derechos ARCO
Resolución de problemas
Dudas status canjes
Bloqueo / Desbloqueo por teléfono perdido?
Status de Tickets
Abrir / Cerrar tickets
Resolver dudas sobre funcionalidad
5.3.3.2 Complementaria
Por cada campo que el usuario llena, se le otorgarán una cantidad de puntos.
Esta información se puede usar inicialmente para segmentar al usuario y personalizar su experiencia en la app, especialmente en la sección de presentación de Promociones.
Hijos
Pareja
Si / No
Selección de intereses
Tipos de promociones
Comida Favorita
Tiene Mascota
Animal
Fecha de Cumpleaños
Sexo
5.3.3.1 Al Registro
Población preferida
Número de celular
Edad
Sólo se habilita para que el cliente decida a donde quiere que se envíe un producto exclusivo.
No requiere un acceso desde la pantalla principal.
5.2.2.2 Desplegar tiendas cercanas
Obtener permiso para Activar GPS
Mostrar tiendas cercanas al dispositivo
5.2.2.1 Listado Tiendas
Posteriores
Consola de administración
Alta / Baja /Mod / Activar y Desactivar
v1.0
Se usará WS para comunicar las tiendas y su status
Tablero de Notificaciones activas
Eliminar Notificaciones
Editar Notificaciones
Activar / Desactivar Notificaciones
Crear notificación
Asignar Tipo de Notificación
Envío o repceción de puntos / dinero electrónico
Aviso de Promociones
Status Producto Exclusivo
Crear Notificación manualmente
Plantillas de notificación
Eventos (If / Then)
Periodicidad
Tablero de notificaciones
Botón en pantalla principal
FAQ
El texto requerido para esta sección se colocará en archivos de texto plano que jalará la aplicación desde una ubicación predefinida.
Uso de marcas
Términos y Condiciones
Aviso de Privacidad
Una vez que un ticket se facture, ya sea en Web o en App, se notificará a la contra parte mediante un WS para que ambas partes tengan homologado el catálogo de tickets facturados.
El WS funciona bajo esquema push.
De lado de Kiosko, sólo se hará push a las facturas de tickets marcados como tickets del Programa de Lealtad.
Existe un repositorio donde están guardados tanto los PDF's como CFDI's y se pueden consultar para que los clientes los jalen en caso de ser requerido.
Se habilitará una VPN físico punto a punto que dará acceso a:
WS's
servidor de facturación MasterEDI
Carpeta del repositorio
Kiosko corre con la inversión del Firewall
v1.2
Se activa la cámara del teléfono
Escanear código de barras del ticket
Escaneo fallido
Sugerir a cliente digitar número manualmente
Escaneo exitoso
Mostrar folio del artículo
APP solicita a servidor Kiosko datos de ticket
Servidor Kiosko envía datos incluyendo status de facturación
v1.1
APP Envía el Folio a central BRICK y le devuelve el status del ticket
Mostrar mensaje de error, desplegar botón "Aceptar"
Al "Aceptar" regresar a pantalla principal de facturación
Ticket Facturable
Se despliega información de Ticket y botón para "Facturar"
Colocar Dropdown para mostrar las demás razones sociales.
Cliente presiona "Facturar"
se posterga a v1.1
Ya tiene el sistema de facturación una serie de errores previstos, habrá que "traducirlos" para otorgar a los usuarios una información más entendible y en los casos que sea posible acciones a tomar.
Aviso
Indicar fin del proceso
Un usuario debe poder seleccionar varios tickets para que se genere una sola factura.
Presionar "Facturar"
Mostrar razón social "por Defecto"
Colocar Dropdown para mostrar las demás razones sociales.
Y la opción de dar de alta otra.
Cliente revisa datos de ticket a facturar
Cliente confirma facturación
APP se conecta a servidor de facturación
Proveedor de facturas procesa la petición
Facturación fallida
Enviar mensaje de error
Kiosko enviará el listado de mensajes de error que maneja MasterEDI para que lo tengan.
Se sugiere: que se haga una tabla que "traduzca" el mensaje de error que envía el servidor a lenguaje simple para que lo vean los usuarios.
Sugerir siguientes pasos
Facturación exitosa
Se envía PDF y XML a email de usuario
Cambiar estatus de ticket a "Facturado" en el historial
Se envía mensaje PUSH mediante WS a Kiosko para notificar de la facturación
Se desplegarán todos los tickets relacionados con las compras del cliente donde se haya identificado con su ID de usuario, pero se clasificarán conforme a los siguientes criterios:
Facturado
Sin Facturar
No facturable
Kiosko agregará de su lado el campo "origen de facturación" con valor de "APP" o "Web Kiosko".
No se guardarán datos en el app, todas las facturas se enviarán por Correo Electrónico al correo predeterminado del usuario.
Los tickets facturables tienen una vigencia.
A partir del primer día del posterior al que el ticket se emitió, Para definir si un ticket no es facturable,
Se deben poder manejar múltiples razones sociales.
Todos los correos con XML y PDF se envían al correo registrado del usuario.
Guardar una razón social como valor "Por Defecto"
Por disponibilidad y seguridad el usuario puede bloquear y activar su cuenta desde el portal WEB (Si no recuerda los datos de acceso, puede solicitar recuperación de contraseña al correo electrónico)
El cliente puede asociar un nuevo número a su cuenta, desde la página WEB.
Una vez que esta inactivo el número, el cliente puede asociar uno nuevo desde la página Web tecleando el número SMS de validación que le llegaría al nuevo dispositivo.
Una vez validado, puede descargar el App y entrar con usuario y contraseña, el teléfono anterior ya se sera valido para ingreso.
Requiere desarrollo para las pantallas del Call Center.
Operador "desbloquea el celular"
Apaga switch de "bloquear celular"
Esto puede usarse en caso de robos o extravíos de equipos.
Requiere llamar al Call Center.
BL-La funcionalidad de recuperación debe apoyarse en el correo electrónico.
Cliente llama a Call Center
Operador le hace preguntas de seguridad
Operador "bloquea el celular"
Cliente entra al web con su usuario y contraseña
Se dirige a la sección de datos de usuario
Activa switch de "bloquear celular"
Entrar a sección de editar datos de usuario
Seleccionar opción "Cambiar mi celular"
Digitar nuevo número de celular
BRICK envía SMS para validación
Número Incorrecto
Número Correcto
Debe haber un tiempo para timeout.
Debe haber opción para re-enviar el mensaje en caso de que no llegue.
Cliente digita el código del SMS
Se envía dato a Brick
Se asigna el nuevo número
El usuario podrá guardar su número y los de otras personas.
Deberá capturar en el app el número y compañía y se generará un código individual para cada "número frecuente".
Cliente muestra en la APP el código del número al que desea recargar
El QR ya trae el número de teléfono y la compañía.
BRICK regresa datos para acumulación de puntos
Se despliega número de celular y compañía en casillas correspondientes en PDV
Cajero pregunta Monto, Tipo de recarga
Cliente Paga
Formas de paga con:
Tarjeta
Efectivo
Dinero Electrónico
Forma de Pago: Tarjeta o Efectivo
Se efectúa el cobro
Forma de pago: Dinero Electrónico
Aplicar filtros OpenPay
No recibir tarjetas Extranjeras
Evitar spam de transacciones
Inicialmente se usará sólo para el pago de Productos Exclusivos y Compra de Dinero Electrónico.
Servicio otorgado por el partner OpenPay.
La información para usar los métodos de Openpay para alta, baja o modificación de tarjetas serán comunicaciones directas entre Brick y Openpay sin pasar por el switch de Kiosko.
Selecciona "Cartera"
Seleccionar "Eliminar tarjeta"
Aparece Popup de Confirmación
Cliente confirma eliminación
Cliente cancela eliminación
Regresas a pantalla de datos de tarjeta
Se eliminan los datos guardados de la tarjeta
Encontrar la tarjeta a editar
Seleccionar opción "Editar"
Hacer modificaciones
Seleccionar "Cartera"
Seleccionar nueva tarjeta
Introducir datos de tarjeta
Seleccionar Guardar
Horarios y fechas
Requerir confirmación siempre al transferir
Tiempos de espera entre transferencias
Max / Min x CashIn
Limite por cuenta?
Caduca?
Cliente presenta sus artículos en mostrador
Cajero lo atiende conforme a protocolo
Cajero solicita QR a cliente
Cliente muestra el QR en APP
Cajero escanea el QR usando el PDV
Cajero escanea los artículos
Cliente expresa que quiere pagar con DE
Cajero selecciona Forma de pago "Dinero Electrónico"
PDV envía una notificación a BRICK informando que desea hacer un cargo a la cuenta del cliente
BRICK valida la transacción
Ejemplo de validaciones:
Tiene saldo?
Cuenta esta activa?
Transacción rechazada
Estos errores se describirán en los casos de uso.
Transacción aprobada
APP Despliega mensaje push en el dispositivo del Cliente preguntando si acepta el cargo
Cliente rechaza el cargo
PDV muestra rechazo de transacción
Cajero sugiere otra forma de pago
Cliente acepta el cargo
BRICK avisa a PDV Kiosko que el cargo fue aceptado
PDV muestra autorización de transacción a cajero
Cajero concluye la transacción
PDV avisa a BRICK transacción concluída
BRICK hace los movimientos en el saldo del cliente
KIOSKO realiza reclasificación de ese monto de DE electrónico a otra cuenta pues se realizó la compra.
Actualmente la reclasificación sería manual conforme a los desarrollos actuales.
---
A definir por Kiosko.
Recepción de tranferencia
Notificación push de Transferencia Recibida
Cliente quiere transferir a un número no guardado
Usuario introduce datos de destinatario
Cliente quiere transferir a un número guardado
Desplegar saldo Disponible y Destinatarios guardados
Usuario selecciona destinatario
Usuario introduce monto a transferir
Montos mínimos y máximos
Destinatario existe
Saldo
Etc.
Cuenta bloqueada
Cuenta no existe
Saldo insuficiente
Cambiar atributos de destinatarios
BRICK envía transacciones a Kiosko
Preguntar a Jonathan periodicidad, por ejemplo diario.
Definir formato.
Se recibe información de OpenPay
Bajar archivo del dashboard de Openpay todos los días.
Se concilia información entre OpenPay y Kiosko
Cliente selecciona "Adquirir Dinero Electrónico"
Colocar monto a adquirir
Entre $20 y $3,000
APP muestra las tarjetas del Wallet
Validaciones de OpenPay y APP.
Algunas de las validaciones son:
Transacción dentro rango de montos.
No spamming de tarjeta
Tarjeta no está en lista negra
No es tarjeta extranjera
La información pasa a través de Kioswitch antes de irse a Brick y Open pay y cuando llega de regreso.
APP Aplica cargo a tarjeta de cliente
APP hace abono de DE a Cliente
APP debe informar a Kiosko de una transacción exitosa
Cli deudores div Open pay (Éste movimiento se da en el APP)
Acreedores div dinero electronico
Cargo bancos (Cuando OpenPay nos deposita)
Cli deudores div open pay
----
Se requieren conciliaciones entre PDV (virtual) y Brick
y entre PDV (virtual) y OpenPay
Open pay nos debe dar detalle de cada transacción individual.
1.2.1.1.2 Tarjeta Débito / Crédito
Se activa PIN PAD
Se cobra con tarjeta.
WS service que envía a Brick información como ID de Usuario monto recargado, fecha, hora, folio de transacción.
Error en transacción
Por ejemplo error de conectividad
Iniciar proceso de devolución automática
Pendiente definir proceso interno en Kiosko.
1.2.1.1.1 Efectivo
La transacción representa un ingreso para Kiosko.
Nosotros tendríamos el monto global de la cuenta, pero el detalle de la cuenta que lleva cada cliente la tendrá Brick.
Se va a una cuenta de "Dinero Electrónico en Tránsito" (deudores diversos).
Cliente solicita comprar Dinero Electrónico pagando con Efectivo
Cliente se presenta en Caja y solicita DE
Cajero solicita a Cliente su QR
Cliente muestra su QR en app a Cajero
Cajero escanea el QR usando PDV
Aquí va el flujo de validación del QR donde Kiosko envía el ID de usuario y pregunta si es válido.
Cajero pregunta el monto de la adquisición de DE
Se generará un código de ingreso con un mínimo de $20 y un máximo de $3,000 pesos y el cliente podrá definir dentro de ese rango cuanto abonar.
Cajero realiza el cobro
El cajero recibe el dinero y cierra la transacción en PDV
PDV Kiosko envía info de transacción a Brick
WS service que envía a Brick información como ID de Usuario, monto recargado, fecha, hora, folio de transacción.
Brick realiza validaciones
Por ejemplo:
cliente no excede su límite diario o mensual de abonos a DE.
Cuenta existe
Cuenta no bloqueada
etc
No autorizado
Se cancela transacción
Cajero regresa el dinero
Autorizado
Brick confirma a Kiosko que recibió la información
PDV muestra la confirmación y el cajero que se abonó el monto
Sólo se informa que la transacción fue exitosa y no se muestra el saldo total del usuario en PDV Kiosko.
Kiosko realiza el registro contable
Kiosko hace el cargo la tienda (Cliente), y abono a cuenta de acreedores diversos "Dinero Electrónico en tránsito".
Se permitirá devolución y en la noche se indica en los tickets cuando se debe devolver puntos porque fue cambio de SKU
Kiosko asume que se presentaran casos de puntos negativos y se deberá entrega conciliación de estos caso a fin de mes.
Validación
Siempre se pide conf o clave?
Establecer monto a partir del cuál se pide conf o teclear una clave
Límites
Validaciones
Requerir confirmación siempre al redimir o transferir
Requerir confirmación a partir de un monto a transferir
Montos a transferir
Máximo / Min
Fechas
Max / Min x Día
Max / Min x Compra
Horarios
No hay límite por cuenta
Puntos Caducan a los 6 meses
Estarán disponibles
"Entrega en tienda seleccionada"
"Envío a Domicilio"
Viene del paso "APP Genera Avisos" del flujo "adquirir Producto Exclusivo"
4. Envío a domicilio de cliente desde CEDI BRICK
CEDI Brick recibe aviso de venta y prepara envío
Proveedor envía mercancía a Cliente vía paquetería
Cliente recibe el producto
Paquetería genera acuse de entrega
Brick recibe acuse de entrega de paquetería
BRICK envía mediante WS la recepción del producto por parte del cliente
WS recibe aviso de entrega a cliente y se generan: OC, entrada y salida automáticamente en ERP
Revisar el flujo con Heriberto.
Kiosko envía mediante WS a Brick folio de OC y salida de mercancía
El pago a Brick entra en el flujo de portal de proveedores
Se acordó crédito 30 días.
3. Envío a Tienda desde CEDI BRICK a través de CEDI Kiosko
Update: 19/08/2020
Técnicamente es viable manejar éste flujo mediante OC's centralizadas para ingresar la mercancía directamente en tienda y que por lo tanto BRICK nos envíe estos productos a tienda sin pasar por el CEDI.
Tocar base con operaciones para ver las implicaciones de recibir directo en tienda. Por ejemplo dar entrada y resguardo de mercancía.
Requerimos reglas de negocio para regresar el artículo promocional en caso de que el cliente no pase por el artículo en X días.
update: 15/09/2020
Operaciones rechazó el recibir esta mercancía en tienda vía OC's centralizadas, por lo que se usará la logística de CEDI Central Kiosko
Al momento de la venta, el sistema BRICK notifica por WS a SYNKIO
SYNKIO inyecta OC por la mercancía vendida al ERP
Reponsable de compras Kiosko libera y envía la OC a Brick
Proveedor entrega a Kiosko en CEDI KSK
CEDI Kiosko da entrada a la mercancía
Generar documento de traslado
Falta un mecanismo que permita identificar cuando la mercancía esté en tienda y se pueda disparar un aviso a cliente para informarle que ya puede ir a recoger.
En un escenario idoneo: el sistema en tienda manda aviso de que llegó la mercancía por medio de un Web Service a Brick y la APP lanza un aviso automáticamente al Cliente.
Opción 1:
El responsable del programa de lealtad en Kiosko monitorea los movimientos de mercancía en el inventario de Kiosko y cuando identifica que llegan los productos a la tienda desde su dashboard de administración lanza el aviso estandarizado a cliente.
2. Envío a domicilio de cliente desde CEDI KSK
Responsable MKT KSK monitorea en búsqueda de pedidos nuevos
Usaremos una pantalla que nos proporcionará Brick para poder monitorear los pedidos nuevos y actualizar los status de la mercancía.
Para el golive utilizaremos sólo esta herramienta aunque busquemos como automatizar procesos posteriormente.
Update 11/09/2020:
Solicitar a Brick que lleguen alertas por correo electrónico de pedidos nuevos a correos que se puedan definir en la plataforma.
Responsable MKT KSK avisa a CEDI KSK de requerimiento de envío
Empaque
Salida de inventario
CEDI KSK prepara Guía
Revisar con Heriberto el aspecto administrativo.
Revisar con Jorge los aspectos operativos.
Se programa recolección
Se entrega en CEDI KSK a Paquetería
Paquetería entrega a cliente
Paquetería envía acuses de entrega a Responsable MKT KSK
Responsable MKT KSK actualiza status en dashboard
BRICK Actualiza status a entregado en el APP
1. Envío a Tienda desde CEDI KSK
Terminado en Visio.
Al momento de la venta, el sistema Brick lo notifica por WS a SYNKIO
SYNKIO Central genera una solicitud de transferencia de esa mercancía a tienda y pregunta a Sistema Logística CEDI la fecha de entrega
Sistema Logística CEDI responde a SYNKIO con la fecha calendarizada de entrega
SYNKIO envía mediante un WS a Brick la fecha probable de entrega a Cliente
APP muestra al usuario la fecha estimada de llegada del producto a la tienda destino.
Picking
Cuando llega el día calendarizado de Picking para la tienda de destino.
Embale
Cedi KSK envía mercancía a tienda
Usando los esquemas logísticos normales.
Tienda da entrada a la mercancía
Este punto si se desarrollará en v1.0
Falta un mecanismo que permita identificar cuando la mercancía esté en tienda y se pueda disparar un aviso a cliente para informarle que ya puede ir a recoger.
En un escenario idóneo: el sistema en tienda manda aviso de que llegó la mercancía por medio de un Web Service a Brick y la APP lanza un aviso automáticamente al Cliente.
El código tendrá una configuración donde se indique que no es vendible.
Alternativa 1:
El responsable del programa de lealtad en Kiosko monitorea los movimientos de mercancía en el inventario de Kiosko y cuando identifica que llegan los productos a la tienda desde su dashboard de administración lanza el aviso estandarizado a cliente.
Cliente llega a la caja y solicita su Producto Exclusivo
El cajero solicita al cliente el código de la compra generado por BRICK y lo escanea
PDV KSK envía el código de Producto Exclusivo a BRICK
BRICK valida código
Código No Válido
BRICK devuelve el error y el mensaje que debe dar el cajero al cliente
Cajero explica que el código no es válido y le transmite el mensaje enviado por BRICK.
Código Válido
BRICK regresa a Kiosko información que requiere para la emisión del ticket.
Por ejemplo:
Descripción, piezas, ID Transacción en APP, Puntos, Monto pagado, Forma de pago, MOnto pagado para cada forma de pago.
Cajero cierra la transacción. PDV emite "Ticket de venta" y posteriormente un "Comprobante de entrega" con dos tantos, uno lo debe firmar el cliente para que se lo quede tienda y el otro es para cliente.
El "ticket de venta" debe incluir la descripción de los artículos entregados, las piezas por artículo, el monto pagado y los puntos y el ID de la transacción en el APP.
El "Comprobante de entrega" debe incluir la descripción de los artículos entregados, las piezas por artículo, la fecha de entrega, el ID de transacción de cliente y espacio para firma.
Tienda entrega físicamente la mercancía
PDV KSK avisa mediante WS a BRICK de la entrega de producto
Status de Compra de Producto Exclusivo cambia a "entregado" en APP
Debe haber un catálogo base de productos construído en Brick y Kiosko sólo actualizará diariamente el catálogo disponible en Kiosko y cada vez que un cliente inicie el proceso de Checkout, Brick validará que haya existencias en CEDI Kiosko mediante un web service e informará al cliente en caso de que un producto se encuentre agotado.
Adicionalmente:
Tap sobre la foto o descripción del artículo deseado
Tap en "Comprar"
APP Valida Puntos
Si le faltan puntos al cliente
Mostrar status y puntos faltantes
Mostrarle una barra de progreso donde se ilustre la cantidad de puntos que tiene en proporción del costo en puntos del artículo.
Colocar mensaje donde lo invitamos a seguir comprando en Kiosko y acumulando puntos para que logre su meta.
Al final de la pantalla colocar un botón que tenga la leyenda "OK!", "Enterado" o "Volver al catálogo" y al presionarlo te regrese a la página principal del catálogo.
Regresar al catálogo
Si tiene suficientes Puntos
Ir al carrito
Se muestra productos y total a pagar
Solicitar destino de la mercancía
El cliente debe definir si quiere 1) entrega a domicilio (con costo adicional) o 2. recogerá en tienda (envío gratis); en caso de envío a tienda, debe especificar en qué tienda va a recoger usando el mapa de sucursales descrito en la sección Touchpoints.
Dar opción de guardar destino
Solicitar forma de Pago
Cliente quiere pagar en APP
Se muestran opciones de Pago a Cliente
Cliente quiere pagar con una combinación de Wallet y Dinero Electrónico
Cliente introduce cantidad a pagar con DE
Cliente da tap en "Completar pago con tarjeta"
Mostrar detalles de la transacción
BRICK / Openpay realizan validaciones
APP Aplicar cargos en DE y TC y pago
Se aplica también el cargo de puntos.
Cliente quiere pagar con Dinero Electrónico
Mostrar detalles de transacción
Mostrar saldo de Dinero Electrónico
APP realiza validaciones
Validaciones de APP.
Algunas de las validaciones son:
Saldo suficiente
Transacción dentro rango de montos.
No spammig de transacciones
Cliente esta habilitado
Cuenta no está en lista negra
BRICK aplica pago y descuenta saldo de DE del cliente
Se diferencian los procesos Administrativos de los Operativos.
Posibles casos:
Los casos 2, 3 y 4 requieren un web service de Kiosko que esté escuchando para cuando lleguen los avisos tanto Operativos como Administrativos (por ejemplo: sku vendido, monto de ventas, formas de pago usadas, monto pagado por forma de pago).
En caso de pagos con tarjeta:
Kiosko conciliará versus Openpay los registros de las ventas para garantizar que se nos pague todo lo que se vendió en la tienda virtual.
Para el resto del proceso: Ir a sección de Logística de entrega.
Kiosko reclasifica el DE en Transito de esta transacción porque se realizó la venta
Cliente quiere pagar con Wallet
Mostrar tarjetas del Wallet
Si no hay tarjetas agregadas, se solicita agregar una
Dar opción de guardar la nueva tarjeta
Cliente selecciona tarjeta para la transacción
App muestra detalles de la transacción
SKU
Descripción breve
Piezas en el carrito
Monto en pesos
Monto en puntos
Habilitar botón "Pagar"
Cliente da tap en "Pagar"
APP / Openpay realizan validaciones
Validaciones de OpenPay y APP.
Algunas de las validaciones son:
Transacción dentro rango de montos.
No spamming de tarjeta
Tarjeta no está en lista negra
No es tarjeta extranjera
Se rechaza la transacción
Se muestra mensaje de error a Cliente
Revisar cuáles son los códigos de respuesta que da OpenPay de error para que Brick pueda poner un mensaje entendible para los usuarios.
Se requiere regla de negocio para definir que mensaje mostrar cuando el código recibido no esté previsto.
Se ofrecen alternativas o se regresa a inicio de transacción
No se realiza ningún cargo
Se autoriza la transacción
APP confirma transacción a Cliente
APP Aplica cierra la transacción
La petición sale de Brick hacia Kioswitch y Kioswitch la re-envía a OpenPay. Esto permitirá a Kiosko tener registro de transacciones para conciliaciones e implementar los tokens para el pago.
Brick tendrá que deducir los puntos usados al usuario y hacer los registros de venta correspondiente.
APP Genera Avisos
Cliente quiere pagar en Tienda
APP Generar Folio
Cliente se traslada a tienda
Cajero escanea folio en PDV de tienda
PDV Kiosko solicita la información del pago a Brick:
Cliente paga en tienda
Métodos de pago aceptados:
Tarjeta o Efectivo
En el caso de que no haya conexión cuando PDV envía la información:
Después de N reintentos, el PDV hace una cancelación de la venta y se le regresa el dinero al cliente.
En el caso de que no haya conexión cuando Brick envía la confirmación:
Después de N reintentos o durante X tiempo, Brick hace una cancelación de la transacción (roll back) y Kiosko al no recibir dicha confirmación también cancela la transacción.
PDV envía confirmación de pago a BRICK
BRICK Genera Avisos
Se diferencian los procesos Administrativos de los Operativos.
Posibles casos:
Los casos 2, 3 y 4 requieren un web service de Kiosko que esté escuchando para cuando lleguen los avisos tanto Operativos como Administrativos (por ejemplo: sku vendido, monto de ventas, formas de pago usadas, monto pagado por forma de pago).
Kiosko conciliará versus Openpay los registros de las ventas para garantizar que se nos pague todo lo que se vendió en la tienda virtual.
Para el resto del proceso: Ir a sección de Logística de entrega.
Cliente quiere cambiar el orden en el que se despliegan los productos
Por puntos requeridos
Por Pesos requeridos
Alfabético
Seleccionar "Catálogo"
Se despliegan los productos
Dispuestos como scroll vertical.
Foto, descripción breve de cada uno.
Siempre se desplegarán todos los artículos disponibles, independientemente de si el usuario tiene o no saldo disponible para adquirirlos.
Tap sobre la foto o descripción me permite ver más detalle
Los detalles incluyen:
Fotos adicionales
Descripción ampliada
Costo del Producto en puntos y pesos
Barra de progreso que muestra el avance que tiene el usuario en puntos para adquirir el producto exclusivo
Opción de comprar ahora
Indicador de cuantos puntos caducan y el mes en lo que lo hacen, al estilo de los programas de lealtad de las tarjetas de crédito.
Vigencia inicial de los puntos: 9 meses.
Debe ser configurable.
El botón te lleva a un formulario de solicitud de aclaración donde el "SUBJECT" del mensaje ya esta precargado como "SOLICITUD DE ACLARACIÓN RESPECTO PUNTOS" seguido de un text box.
Poder configurar destinatarios.
Cliente quiere administrar sus destinatarios frecuentes
Atributos de destinatario
ID de Usuario
Teléfono
Imagen?
Apodo
Nombre
Modificar destinatario
Agregar / Quitar destinatarios
Usuario quiere transferir Puntos
Seleccionar destinatario
Introducir monto
Guardar operaciones en historial
Desplegar saldo Disponible
Usuario introduce monto
Realizar transferencia
Operación Fallida
Problema de Conectividad
Mensaje de error
Mostrar siguientes pasos
Operación Exitosa
Mostrar status de transacción y Saldo después de realizar transferencia
Desplegar opción para agregar destinatario a "Frecuentes"
Tablero con listado de promociones
Dar click en nombre y que te lleve al detalle
Num sucursales activas
Mecánica
Status (Activa / Inactiva)
Administración
Activar / Desactivar
Eliminar Bono
Editar Bono
Crear Bono
Mecánica de Bono
Factor
50% de puntos extras
Puntos triples
Puntos dobles
Cuotas
Ejemplo
Compra 5 de un artículo y gana N puntos
Por sucursal
Por población o municipio
Segmentación de clientes
Vigencia
Productos / Categorías en los que aplica
Puntos a asignar
Producto / categoría
Enviar a Brick información de devoluciones de tickets vinculados a un usuario de APP para que Brick haga los ajustes correspondientes en el saldo del usuario.
Cliente solicita devolver mercancía que compró
Devolución parcial de ticket
Por un SKU de valor más bajo
Por un SKU de valor más alto
Devolución total
Flujo actualizado el 29/10/2020,
Para reflejar detalles adicionales que facilitan el manejo de puntos en caso de devoluciones.
Promotor aplica devolución en CompuCaja
Ticket de Programa de Lealtad
No
Concluye el proceso
Si
PdV envía mediante WS el ticket a Brick junto con la definición de los artículos que se devolvieron
Brick identifica el ticket y el usuario que le corresponde
Brick hace la deducción de Puntos y Sellos de PC correspondientes
Cambio Físico
No hay afectación a los puntos del Cliente
Ejemplos
Por # de visitas al mes o semana
No va para v1.0
Cumpleaños
Reglas de negocio
Sólo puede canjearse una vez al año
Aniversario de cliente
Bono de Bienvenida
TI Kiosko revisará flujo propuesto por Brick para darle visto bueno.
Método 2
Cliente llega a Caja
Cajero Saluda
Cajero ofrece promociones de tienda
Se hace escaneo de artículos
Cajero dice el total a pagar
Cajero solicita QR
Se cierra haciendo resumen de la transacción
Su total es de $
Le recibo $
Le entrego $
Acumuló X puntos
Aquí tiene su ticket.
PDV Kiosko envía información a APP
Método 1
Éste será el método que se desarrollará.
Al momento de escanear el QR, Kiosko solicita a Brick mediante un WS la información necesaria del cliente.
Cliente llega a Caja con los artículos que va a comprar
Cajero saluda
Cajero solicita QR al cliente
Cajero escanea QR usando lector de PDV
Se hace el escaneo de los artículos
Cajero cierra la transacción en PDV
El cajero recibe dinero o cobra usando el Pinpad
PDV Kiosko envía información a Brick
Kiosko envía el ticket a Brick, y Brick regresa la cantidad de puntos que esta compra acumuló para mostrarla en pantalla e imprimir en ticket.
En caso de que no haya conexión de internet en la tienda al momento de que se concluye la transacción, Kiosko, acumulará todos los tickets en esa situación del día y hará un procesamiento por lotes para re-intentar enviar a Brick los tickets pendientes de asignarles puntos hasta que todos queden procesados.
Falla de internet (Kiosko envía el ticket, Brick lo procesa y tienda no recibe la confirmación):
Cajero cierra haciendo resumen de transacción
El cajero cierra la transacción diciendo:
Su total es de $
Le recibo $
Le entrego $
Acumuló X puntos con su compra
Aquí tiene su ticket.
