Системи · Продуктов дизайн и full-stack разработка
Bookyra - Платформа за графици в салони
Платформа за резервации в салони с графици, напомняния, фактуриране, публични профили и табло за оператора.
Накратко
Bookyra е платформа за графици за бюти специалисти и салони. Проектирахме я и я изградихме: публични профили на салони, графици за услуги, клиентски резервации, напомняния по SMS, управление на екип и роли, отзиви, абонаментно фактуриране и таблото за оператора, което свързва всичко.
Бизнес контекст
Бюти специалистите водят графиците си през телефон, хартиен тефтер, кутия със съобщения в социална мрежа и отделен начин на плащане. Всеки от тези инструменти работи; никой от тях не знае за останалите. Резултатът са двойни записвания, неявявания, за които никой не е напомнил, и собственик, който не може да види какво е направил бизнесът миналия месец, без да го събере на ръка.
Предизвикателството
Платформата трябваше да е достатъчно проста за клиент, който си запазва час от телефон за под минута, и достатъчно пълна за собственик на салон, който управлява няколко служители, техните графици, услугите им и правата им. Продуктите обикновено решават това напрежение, като са добри в единия край и неизползваеми в другия. Освен това трябваше да е наистина многофирмена: всеки салон има нужда от собствени данни, собствен екип и собствено публично присъствие в рамките на една система.
Потребителско изживяване и интерфейс
Клиентският поток е съзнателно кратък: избор на услуга, кой може да я направи и кога, избор на час, потвърждение. Салонната част е организирана около календара, защото това е първото, което собственикът отваря, и мястото, към което се връща цял ден. Управлението на екипа, услугите и правата стои зад него, вместо да се бори с него за внимание. Състоянията, които имат оперативно значение - чакаща, потвърдена, отказана, изпълнена - се различават с поглед, а не с четене.
Разработка
Изградено на React и TypeScript като многофирмено приложение. Входът, достъпът на база роли и обхващането по фирма са основа, а не добавен по-късно слой. Логиката на графиците обработва наличността на всеки служител, продължителността на услугата и застъпванията. Абонаментното фактуриране управлява жизнения цикъл на плана, включително състоянията, които пораждат запитвания - неуспешно плащане, смяна на план и прекратяване.
Архитектура и интеграции
Един модел на данните с обхващане по фирма в слоя на достъпа, така че данните на един салон да не могат да бъдат достигнати от сесия на друг, независимо какво заявява интерфейсът. Изпращането на SMS и абонаментното фактуриране са външни услуги, като приложението записва състоянието на доставката и на плащането, вместо да приема, че са успешни. Жизненият цикъл на резервацията задейства известията, така че напомняне не може да бъде изпратено за отказан час.
Скорост и търсене
Публичните профили на салоните и представителните страници се генерират на сървъра с уникални заглавия, описания и заглавни нива, за да могат да бъдат индексирани и споделяни като реални страници. Всичко зад вход - таблата, управлението на екип, фактурирането - е изключено от индексиране и държано извън sitemap, така че ресурсът за обхождане отива към страниците, които реално могат да привлекат клиенти.
Какво беше доставено
Една платформа, покриваща графици, напомняния, управление на екип, отзиви и абонаментно фактуриране, която замества набор от разкачени инструменти, с многофирмената структура и фактурирането, нужни да се управлява като продукт. Нямаме проверени данни за брой потребители, задържане или приходи, които да публикуваме.
Обхват
- Многофирмена структура на профилите и правата
- Публични профили на салони и списък с услуги
- Графици за услуги и наличност на служителите
- Клиентски резервационен поток
- Напомняния по SMS
- Управление на екип и роли
- Отзиви
- Абонаментно фактуриране
- Табло за оператора
Подход и ключови решения
Два продукта, една система
Клиентската и салонната част бяха проектирани като отделни продукти с отделни цели - скорост на записване срещу дълбочина на контрола - върху общ модел на данните. Опитът и двете да се обслужат от един интерфейс е обичайният начин, по който продуктите в тази категория се провалят.
Правата живеят в слоя на данните
Разделянето между фирмите и правилата за роли се налагат там, където се достъпват данните, а не в интерфейса. Интерфейс, който крие бутон, е предложение; правило в слоя на данните е гаранция, а в многофирмен продукт тази разлика е целият модел на сигурност.
Напомнянията са част от резервацията, не добавка
Неявяванията са разходът, който бизнесът реално усеща, затова напомнянията по SMS бяха вградени в жизнения цикъл на резервацията от самото начало, а не добавени после като интеграция, която може тихо да спре.
Публичните профили са повърхността за привличане
Публичният профил на всеки салон е реална страница, генерирана на сървъра, а не изглед вътре в приложение - за да може да бъде свързван, споделян и намиран. Това прави платформата полезна за намиране на клиенти, а не само за управлението им.
Това описание представя извършената работа и изградените възможности. Не съдържа данни за трафик, конверсии или приходи, защото нямаме проверени измервания след пускането, които да публикуваме.
Имаш подобен проект?
Разкажи ни какво искаш да изградиш и ще върнем ясен и честен план.