Get best of the week

Como durante una semana sin dinero, las conexiones y el software lanzaron un servicio de entrega de alimentos y casi no fallaron

Mi nombre es Dima, soy estudiante de Baumanka y programadora con experiencia empresarial. Junto con los muchachos, especialistas en TI y analistas, creamos Quicq, un único servicio de logística urbana al que cualquier empresa puede conectarse y eliminar la necesidad de mantener su servicio de entrega. Como un fax, solo para bienes físicos. Durante una semana lanzamos MVP en Yaroslavl, gastamos 15 mil rublos al comienzo, completamos unos 250 pedidos y entregamos alimentos por 175 mil rublos. Ahora el servicio funciona con pérdidas, pero sabemos cómo solucionarlo. Escribimos nuestro propio software, nos preparamos para probar nuevas hipótesis y trabajamos en errores.

Te diré cómo pasamos de la idea al lanzamiento: buscamos un nicho, desarrollamos un modelo de negocio, buscamos un enfoque para los clientes y creamos el trabajo con los correos. Quizás nuestra experiencia sea útil para aquellos que enfrentan una tarea similar, y para aquellos que estén interesados ​​en experimentar en el campo de la economía unitaria.



Tecnología alimentaria regional: cómo comenzó todo


El segmento de entrega urbana local en Rusia acaba de comenzar a tomar forma, y ​​en condiciones de cuarentena su importancia para las empresas y las personas ha crecido significativamente. Ahora, esta es una necesidad básica, junto con la electricidad e Internet. La entrega en general es un mercado grande, tecnológico, interesante y de rápido crecimiento. Fijamos una meta: encontrar imperfecciones en este mercado y crear un negocio allí.

El 1 de febrero, teníamos en nuestras manos una lista de 11 hipótesis que se pueden utilizar para iniciar una startup. Comenzamos a sumergirnos en el campo de la logística con la entrega de productos agrícolas. Pensamos que las personas tienen un problema para comprar productos y los agricultores para vender. Para confirmar esta hipótesis, realizamos una docena de entrevistas con agricultores y compradores. Descubrimos que hay un problema para vender, pero no hay problema para comprar. La mitad del costo de un producto agrícola se explica por los costos de logística: dos agricultores que viven en aldeas vecinas entregan sus productos en sus propias máquinas. Sería más lógico combinar esfuerzos, pero por alguna razón no lo hacen.

Nos reunimos con el fundador del servicio "Eat Village" y le ofrecimos encontrar juntos una solución que le permita organizar la logística dos veces más barata. Habiendo profundizado en los detalles del proceso, nos dimos cuenta de que estos tipos no pueden ser salvados por nuestras fuerzas y que el mercado de agricultores es demasiado difícil para nosotros. Luego pensamos en entregar comida de los restaurantes. No tiene sentido competir con los gigantes de la tecnología alimentaria en Moscú, por lo que decidimos mantener CustDev en las regiones. Comenzamos con Yaroslavl, la ciudad en la que crecí y la conozco como el dorso de mi mano. Durante tres días hablé con cinco restauradores locales, y durante cada conversación escuché: “¡Por ​​supuesto, necesitamos esto! Toma el dinero y hazlo. Nos dimos cuenta de que teníamos un problema.

Nos reunimos como equipo y pensamos: "Supongo que esto es bueno, CustDev es un tutorial, pero pensemos en cómo podemos armar un proyecto y lanzar MVP en una semana". Así que acordamos que comenzaremos el próximo lunes. Dividimos los principales bloques de trabajo entre los miembros del equipo: búsqueda de clientes, desarrollo de una aplicación de cliente, búsqueda de correos, organización de un sistema de gestión de mensajería. Participé activamente en ventas y fui responsable de sincronizar todo el proceso. Pero creo que mi tarea principal era crear condiciones bajo las cuales no tendríamos oportunidad de no avanzar. Como resultado, el lunes siguiente, exactamente una semana después de la reunión, nos enviaron pedidos.

Modelo de negocio: cómo funciona


En las ciudades pequeñas, el restaurante tiene dos formas de entregar alimentos al cliente: a través de agregadores: Yandex y Delivery, o mediante su propio servicio de entrega. Su servicio de entrega le cuesta a la empresa unos 130 mil rublos al mes. En Moscú, los restaurantes básicamente rechazan su propia decisión a favor de los agregadores, pero en las regiones, en particular, en Yaroslavl, esto no funciona. Y es por eso. El radio de entrega del agregador es de 3 kilómetros, mientras que toma el 30% de la verificación. En una ciudad regional donde todos los restaurantes están ubicados en el centro, un radio de 3 kilómetros corta la mayor parte de los clientes que viven en áreas para dormir.

Como resultado, los restaurantes organizan sus propios servicios de entrega. Su servicio puede llevar comida a cualquier parte, pero esta es una gran capa de trabajo adicional. Por el precio, esta solución sale un poco más barata, muchos hacen esto: el restaurante deja su oferta en el agregador, indica el radio de entrega: toda la ciudad, recoge los pedidos y los distribuye de forma independiente. Nuestro modelo de negocio sigue desde aquí. Brindamos al restaurante una solución en caja: un servicio de entrega basado en el principio de una subcontratación clásica. El cliente se conecta a nuestro servicio y obtiene acceso a su cuenta personal en el sitio web Quicq.ru. El administrador del restaurante ingresa toda la información sobre el pedido y presiona el botón "entregar", similar a llamar a un taxi. Crear una aplicación en el sitio lleva un minuto y medio. Después de 15 minutos, llega nuestro servicio de mensajería, recoge el pedido y conduce a cualquier lugar de la ciudad.



Una semana, nuestro servicio le cuesta al cliente unos 10 mil rublos, siempre que el restaurante tenga sus propios correos. Si no hay correos, pero hay muchos pedidos de entrega, el restaurante gasta 30-40 mil por semana para nuestros servicios. Ganamos al recibir dinero del restaurante por cada entrega. No tomamos un porcentaje del pedido, porque no nos importa qué hacer, ya sea una barra de oro o una chuleta. Todo depende del kilometraje. Ahora estamos experimentando con los aranceles, la primera semana trabajamos en un arreglo y entregamos 160 rublos a cualquier parte de la ciudad. La economía en este caso convergerá si envía correos de manera uniforme, tanto lejos como cerca. A este ritmo, los restaurantes cubrían distancias cortas con sus correos y nos enviaban a tierras lejanas. Para algunos clientes, creamos una escala de precios que variaba a intervalos: hasta 5 km, 5-10 km, 10+ km, etc.e. Ahora tenemos planes de probar el modelo con el pago por cada kilómetro.

Consideramos que el servicio de entrega urgente de Dostavista es nuestro principal competidor. Ofrecen servicios similares, lo hacen desde hace mucho tiempo y a gran escala. Y sin embargo, tenemos diferentes modelos de negocio. Dostavista funciona como un taxi con un enfoque en B2C, conectando mensajeros gratuitos y clientes. Si yo, en autoaislamiento, quiero enviar una carga telefónica a un amigo, definitivamente lo haré a través de Dostavista. Si soy una tienda en línea que necesita enviar algunos productos al otro extremo de la ciudad durante el día, lo más probable es que recurra a ellos. Y si necesito una solución para entregas locales de alta frecuencia y alta velocidad, entonces se trata de nosotros.

Es demasiado temprano para competir, pero es hora de inspirarnos y adoptar las mejores prácticas. Inspirados por Dostavista, comenzamos a estudiar la experiencia de crear una plataforma, un mercado. Y Yandex.Lavka nos inspiró a pensar en lanzar la entrega de productos en las regiones.



MVP en Yaroslavl: "si sobrevivimos aquí, sobreviviremos en cualquier lugar"


Yaroslavl: se trata de 600 mil personas, baja solvencia, carreteras terribles, atascos de tráfico pesado durante las horas pico. Elegimos esta ciudad para lanzar MVP de acuerdo con el siguiente principio: "si sobrevivimos aquí, sobreviviremos en cualquier lugar". Por la misma estrategia, crecí en ella. Decidimos que si organizamos el sistema logístico para que la economía converja, será mucho más fácil para nosotros escalar a otras ciudades.

Llegamos a los restaurantes de la ciudad y dijimos: "Hola, somos Misha y Dima, queremos resolver su problema con la entrega". En algunos casos, funcionó, y obtuvimos un grupo de clientes para comenzar, pero luego nos topamos con una restricción fundamental para trabajar en este modo, ya que la mayoría de las empresas aún no están listas para trabajar con Misha y Dima, necesitan una relación legal y un acuerdo.

Te diré cómo funciona el trabajo con mensajeros. Los buscamos usando anuncios en Avito. Reunimos una gran cantidad de personas con un automóvil personal en la base de datos, dividimos la jornada laboral de 11 a 23 horas en tres bloques y formamos turnos de 4 horas, en cada uno de los cuales o todos a la vez los correos se registran a voluntad. Al comienzo de su turno, los correos llegan al punto de recogida en el centro de la ciudad y esperan la orden. El nuevo pedido se muestra en la aplicación móvil del servicio de mensajería, lo recoge rápidamente y lo toma, y ​​luego regresa al punto de recogida. Hasta que el proceso sea automatizado, tomamos todo el trabajo en la formación de turnos.



Nos dimos cuenta de que está mal pagar a los correos en los pedidos. Para salvar a las personas, cambiamos al modelo no rentable hasta el momento: pagamos la tarifa por hora, compensamos la gasolina y pagamos una motivación adicional por cada pedido completado. Nuestro servicio de mensajería gana alrededor de mil quinientos rublos por día, transferimos dinero a la tarjeta una vez por semana. Es importante tener en cuenta que, independientemente de la cantidad de pedidos que realicemos por día, 5 o 25, el costo para los correos es aproximadamente el mismo, todavía los ponemos en turnos y les pagamos la tarifa.

Si el servicio de mensajería se equivocó, el restaurante llama a nuestro supervisor de turno y resolvemos el problema. Hasta la fecha, hemos completado más de 200 pedidos y nunca nos hemos encontrado con los problemas de los que todos hablan: el mensajero se perdió, convirtió la pizza en sopa de crema, comió comida en el camino.

Los planes: un experimento con la entrega en scooters por analogía con Yandex.Lavka y Delivery. Si no hace frío en invierno, y los mensajeros dicen que no, entonces los scooters son una gran cosa que resuelve problemas clave: tiempo, dinero y encontrar personas. Esto reducirá el costo de un kilómetro y el tiempo de viaje durante las horas pico en 3 veces, podremos atraer estudiantes para trabajar en nuestro tiempo libre. Gane uno y medio o dos mil por día de trabajo en Yaroslavl; esto no es malo ni siquiera para un hombre adulto. Los scooters pueden ser propiedad de compañías de taxis y alquilados a nosotros. Hablé con un par de parques de taxis, me dijeron que desde un automóvil comprado por 600 mil - un millón de rublos, ganan alrededor de 600 rublos por día. Si imagina que comprarán scooters con un valor de más o menos 150 mil, sírvalos y alquilelos,podremos proporcionarles ingresos de 400 rublos por día por unidad. Esto es beneficioso tanto para las compañías de taxis como para nosotros.

Quicq en números


Para comenzar el experimento en Yaroslavl, gastamos 15-20 mil rublos de nuestros fondos personales. Esto es un poco demasiado para MVP. Fuimos más allá del presupuesto planificado de 3 mil rublos, porque acordamos compartir todos los gastos relacionados con todos, de una manera patsansky. Nuestros costos: bolsas térmicas para mensajeros (6,000 rublos por 4 piezas), un dominio para alojar un sitio, pequeños gastos en anuncios en Avito para buscar correos, 7 mil rublos para alquilar un departamento para un colega que me acompañó a Yaroslavl.

Comenzamos el 10 de marzo y el 5 de abril completamos 329 pedidos. Ahora tenemos 5 clientes existentes, 4 en proceso de conexión y más de 20 correos en la base de datos. Ganamos en la región de 20-30 mil rublos por semana. De estos, alrededor de 22 mil se gastan semanalmente en salarios a los correos, 1000 rublos son gastos en Avito, otros 2-3 mil pequeños gastos. La pérdida real que cubrimos de nuestros bolsillos hoy es de 6-7 mil por semana.



Quicq a través de los ojos de TI


Las herramientas que estamos utilizando actualmente en el marco del proyecto: el sitio, del lado del cliente, la aplicación móvil B2Field finalizada, del lado del servicio de mensajería para monitorear dónde está y en qué estado. Nos reunimos con representantes de B2Field y solicitamos una versión gratuita durante dos meses. Conectamos los pedidos con los correos utilizando el panel de administración de B2Field: este es un panel de control de vuelo, su gerente de logística, recibe pedidos, crea rutas y nombra correos. Ahora el problema de la automatización es urgente para nosotros, de modo que el servicio de mensajería se designa automáticamente cuando aparece el pedido.

Entendemos que en el futuro no podremos competir con jugadores fuertes en este mercado utilizando software de terceros. Por lo tanto, nuestra tarea principal es crear nuestro propio software con buenos algoritmos, que optimiza la ruta no peor que otros.
No tenemos presupuestos de desarrollo, escribimos quién puede hacer qué, porque hay que empezar por algún lado. Afortunadamente, casi todos los chicos tienen experiencia en TI, y es muy diferente. En total, nosotros como equipo tenemos habilidades bastante buenas tanto en aplicaciones web como en desarrollo móvil, así como en aprendizaje automático o sistemas informáticos complejos, como la optimización de rutas. Cada miembro del equipo escribe su propio bloque, en este sentido, inmediatamente decidimos dividir el sistema en varios módulos que se comunican por API.

Quicq es una plataforma cuyo núcleo es el servidor principal que implementa la lógica empresarial de todos los proyectos. Inicialmente desarrollamos una cuenta personal única para el cliente, y a medida que se lanzan nuevos productos, simplemente levantamos una nueva interfaz. En este sentido, nos inspira Gojek, una empresa indonesia, uno de los ecosistemas más grandes del mundo. El cliente tiene una cuenta desde la cual puede pedir un taxi, comida, llamar a un médico o una tintorería en casa, enviar un paquete, etc.



Como una unidad separada, asignamos un servidor de enrutamiento en el que se resuelven todas las tareas relacionadas con la logística: se construyen y optimizan rutas, se predicen los tiempos de entrega del servicio de mensajería, se distribuyen los pedidos. Para construir rutas, ahora usamos el motor OpenRouteService en los mapas OSM. Ambas soluciones son de código abierto, y las rehacemos para nosotros mismos. Largo atormentado con la elección de tarjetas y motor de enrutamiento. Al principio eran escépticos de OSM, pero las tarjetas resultaron ser sorprendentemente buenas, precisas y, en nuestras condiciones, es importante que también sean gratuitas. Probablemente perdimos un poco al elegir OpenRouteService, ahora tomaría Valhalla, son mucho más fáciles de personalizar. Pero gran parte de su funcionalidad ya se ha arruinado en ORS, y las jambas principales, en general, se han resuelto.

Todas nuestras aplicaciones cliente y programas internos están conectados al servidor principal. Por ejemplo, hemos escrito una cuenta personal de un logista / operador, desde la cual puede monitorear los movimientos de los correos y administrar rutas manualmente, si es necesario. Además, los pedidos de la cuenta personal de los restaurantes y del sitio de entrega de alimentos vuelan a este servidor. En el lado del cliente, solo escribimos versiones web, esto es mucho más rápido. Por ejemplo, para entregar productos, escribimos un sitio web desde cero para los primeros usuarios en dos días hábiles. El tiempo de desarrollo frontend es una métrica muy importante para nosotros, y esto es exactamente lo que ahora nos estamos centrando en la pila de desarrollo. Escribimos el servidor en el nodo js, ​​porque es bastante rápido, además tenemos mucha experiencia trabajando en el nodo, esto elimina retrasos innecesarios. La interfaz se ejecuta en VueJS porque es cursi más simple que React and Angular,y lo más importante, ayuda a escribir reactivamente solo una parte del sitio, lo que significa reutilizar parte del código de proyectos antiguos.

En el futuro, estamos pensando en la integración con iiko u otro sistema popular para restaurantes a fin de automatizar el proceso de creación de una aplicación por parte de un cliente. Esto es fácil de organizar, pero hasta ahora no hay solicitud, porque los restaurantes en sí no están automatizados por dentro. Antes de nuestra llegada, hicieron todo de la misma manera, solo que peor: enviaron información sobre el pedido al SMS messenger.

Desde el primer día, nos dimos cuenta de que nuestro objetivo principal es acumular datos. Recopilamos todo lo que se puede recopilar, rastreamos el tiempo de todas las etapas de los pedidos al minuto. Cuando no hay suficiente información de la aplicación de mensajería, colocamos parches en forma de SMS de los correos, que nos envían al recibir el pedido. Ponemos todos los datos en una base de datos y luego los analizamos en Excel. Gracias a los datos recopilados, creamos un excelente airbag para las iteraciones posteriores.

El equipo del proyecto


Los chicos y yo nos conocimos en Skolkovo en el programa Moove, donde llegamos a impulsar habilidades empresariales y empresariales. Nos unimos en el principio de "reunir tipos con cerebros". Nuestro punto débil era que somos muy similares, carecemos de cerebros no técnicos. Esto interfiere y ayuda al mismo tiempo. Si fuéramos humanidades, sería poco probable que recopilemos fanáticamente datos y estadísticas, pero ahora parece obvio.

Nuestro equipo no tuvo conflictos serios y ataques de pánico, el trabajo se lleva a cabo de la manera más moderada y constructiva posible. Percibimos situaciones problemáticas como parte del trabajo y no nos preocupamos por ello.

Dedico mucho tiempo a la sincronización de comandos. Después de cada reunión y llamada, cuando decidimos cómo seguir adelante con el proyecto, escribo un mensaje largo, largo, describo lo que está sucediendo con nosotros, para que quede claro a las personas fuera de contexto, y lo pongo en nuestro chat general. En condiciones de autoaislamiento, cuando nos comunicamos solo por Skype, esto nos ayuda a todos a estar en la misma página.



Planes de desarrollo


Yaroslavl es nuestro sandbox, donde queremos encontrar la mejor solución que se pueda escalar. Ahora estamos escribiendo software y registrando IP, lo que nos dará un aumento de 2-3 veces en clientes. Tan pronto como comprendamos que nuestro modelo está funcionando, comenzaremos a abrir en 2-3 ciudades.
Trabajamos con restaurantes, y varias veces por hora recibimos una aplicación en la que hay una dirección precisa del apartamento, el nombre y el número de teléfono de la persona que está utilizando la entrega ahora. Por lo tanto, obtenemos una ventaja específica, por la cual no pagamos. ¿Cuál es el punto de detenerlo?

Esta semana estamos lanzando el Yandex.Lavka regional, un servicio de entrega a domicilio en una hora. Los competidores que encontramos en Yaroslavl entregan mañana y no aceptan pedidos los fines de semana. El presupuesto al inicio es de 3 mil rublos. El plan de acción es el siguiente: llevamos las tiendas de comestibles más cercanas a la casa, analizamos qué productos tienen mayor demanda ahora, analizamos la información de los mismos en los catálogos en línea y los cargamos en nuestro sitio web, en un constructor gratuito. Al mismo tiempo, estamos pensando en cómo organizar la logística, imprimimos 300 folletos y los distribuimos en las casas del distrito. Si recibimos al menos 10-20 pedidos con 300 folletos, esta es una excelente conversión, hay razones para comprar tráfico para esta historia y comenzar a desarrollarse. Si no, toma otra hipótesis.

Manejo de errores


Como reflejo de la experiencia adquirida durante el lanzamiento de este y un par de proyectos anteriores, saqué varias conclusiones que pueden ayudarlo a no pisar mi rastrillo:

  • . , — . , , MVP, . , , — , . , . , . 20 — . , , . — .

  • . , , , . , , . , — / . , , . , .

  • . , , - , . : , , 100 . . , , .

  • = . , , – . , , , . , - , . , .

  • . , “!”. 100% , , . , , .

  • – . , , -. , , , .

  • , , CEO, . , -: , , . , , . , , . : « , - ». . , : «, , - . , ?» , . .

  • , : , . , , - . : « ?» , .

  • , . , , . , - . , « » , , , . , - golama, , , - , .

  • , , . , . , . , .

  • , , , . .

  • , , , , .

More articles:


All Articles