Апликација за мајсторе: шта треба да садржи

Шта заправо градите — апликацију или двострану платформу?

Код обичне мобилне апликације постоји један главни корисник и један главни сценарио. На пример, клијент резервише термин или шаље формулар. Код апликације за мајсторе постоје најмање две стране: клијент и извођач. Између њих је оператер који прати квалитет, спорове, плаћања и незавршене упите.

То производ чини двостраном платформом. Клијент може да креира упит, који се филтрира по услузи и подручју, шаље већем броју одговарајућих мајстора, претвара у понуду, разматра у чету, прихвата, реализује и оцењује. Свака фаза треба да има сопствени статус и историју.

Добар пример је студија случаја FIX. Пројекат обухвата мобилну апликацију, веб портал и претрагу засновану на AI-ју за повезивање клијената са професионалним мајсторима. Важна лекција је да је кориснички интерфејс само видљиви део. Суштински посао је у правилима за упаривање, управљању упитима и контроли администратора.

Које профиле и провере треба да има?

Профил клијента обично садржи име, телефон, адресе, историју упита и жељени начин комуникације. Код осетљивих услуга можете додати фотографије, опис објекта и приступ за одабране чланове домаћинства.

Профил мајстора је сложенији. Треба да приказује услуге, подручја, радно време, слободне термине, фотографије обављених радова, цене или ценовне распоне и оцене. Интерно систем може да чува додатне податке о фирми, ЕИК-у, документима, осигурању и статусу провере.

Није неопходно да све провере буду аутоматске. У MVP-у може постојати ручно одобравање од стране администратора и јасна поља за документа која недостају. Касније се могу додати аутоматске провере, али само ако заиста смањују обим посла, а не стварају још изузетака.

Како клијент проналази одговарајућег мајстора?

Претрага треба да комбинује услугу и локацију. Клијент може да изабере „поправка бојлера“, насеље, жељени термин и хитност. Систем може да користи радијус, поштански број или мапу, али мора да постоји начин да оператер коригује резултат.

AI претрага је корисна када клијент описује проблем својим речима. Уместо да бира из дугог каталога, може да напише да бојлер цури или да тражи некога за кречење две собе. AI може да класификује упит и предложи категорију, али не сме самостално да обећава цену или рок ако подаци то не омогућавају.

Треба предвидети и заштиту од лошег упаривања. Мајстор без слободних термина, ван подручја или без потребне квалификације не треба да добије упит само зато што има високу оцену.

Како један упит пролази од почетка до краја?

1. 01
   Креирање упита

   Клијент описује услугу, адресу, жељено време, буџет, фотографије и додатне услове. Формулар треба да буде кратак, али да прикупи довољно података за почетну расподелу.

2. 02
   Класификација и расподела

   Систем одређује категорију, подручје и хитност. Затим предлаже одговарајуће мајсторе на основу услуге, слободних термина, удаљености и статуса профила.

3. 03
   Пријем понуда

   Извођачи виде само информације које су им потребне и шаљу цену, рок, опис и евентуалне услове. Клијент упоређује понуде на једном екрану, уместо да прикупља поруке са различитих канала.

4. 04
   Комуникација и потврда

   Чет чува историју и може да омогући слање фотографија, додатних појашњења и обавештења. Након прихватања, понуда се претвара у ангажман са термином, адресом и одговорном страном.

5. 05
   Завршетак и повратне информације

   Мајстор означава рад као завршен, клијент потврђује резултат, а обе стране могу да добију оцену. У случају спора, администратор види целу историју.

Да ли су чет, плаћање и оцене потребни од самог почетка?

Чет је важан, али не треба да буде једини канал. Систем треба да зна да ли је упит само покренуо разговор или већ постоји прихваћена понуда. Обавештења путем имејла, SMS-а или Viber-а могу да подсете на непрочитану поруку и промену статуса.

Плаћања зависе од пословног модела. Ако платформа само прослеђује упите, можете почети без онлајн плаћања. Ако клијент резервише услугу уз депозит, плаћа преко платформе или систем задржава провизију, биће потребни payment gateway, фактурисање, отказивање и правила за случај спора.

Оцене треба да буду повезане са стварним упитом. У супротном, свако може да креира фиктивне профиле или објављује оцене без обављене услуге. Корисни су и интерни сигнали за притужбу, кашњење или недолазак.

Шта администратор треба да види?

Администраторски панел је оперативни центар платформе. У њему се одобравају профили, уређују категорије, прате захтеви и решавају спорови. Панел не треба да приказује само списак, већ радну листу: нове захтеве, понуде на чекању, закашњеле одговоре и нерешене случајеве.

Радње које се обављају ручно су веома корисне. Оператер треба да може да дода мајстора у захтев, промени категорију, блокира профил, пошаље подсетник и исправи адресу или време, уз видљиву историју измена.

Ту CRM систем има смисла. Он обједињује разговоре, задатке, захтеве и историју клијента на једном месту. Ако предузеће има складиште, фактуре, провизије или сопствене тимове, платформа може да се повеже и са ERP системом. За пример погледајте демо универзалног ERP система, где су обједињени контакти, пројекти, задаци, фактуре, календар и извештаји.

Када је мобилна апликација довољна?

Мобилна апликација је разуман почетак када је основни сценарио јасан: клијент шаље захтев, мајстор га прихвата, а оператер прати процес кроз администраторски панел. У овом приступу сервер, база података, обавештења и контрола приступа су обавезни, чак и ако их корисник не види.

Сама апликација није довољна када клијенти више воле да претражују преко Google-а, мајстори раде са рачунара или оператери истовремено обрађују велики број захтева. Тада је потребан веб портал за профиле и захтеве, а понекад и посебан портал за администраторе и партнере.

Интеграција са CRM или ERP системом оправдана је када постоје клијенти који се враћају, провизије, фактуре, тимови на терену, залихе или потреба за извештавањем. Израда софтвера по наруџбини омогућава повезивање ових процеса, уместо да оператер преписује податке између табела, четова и рачуноводственог система.

Како да планирате MVP без изградње половине ERP система?

MVP не значи апликацију са произвољно малим бројем функција. То је најмања верзија којом можете да проверите да ли клијенти шаљу стварне захтеве и да ли мајстори одговарају на време. За прву верзију обично су довољни регистрација, профили, претрага по услузи и области, захтев, понуда, обавештења, основни чет, оцене и администраторски панел.

Немојте одмах укључивати све категорије, сложену динамику цена, претплате, аутоматско фактурисање, мапу у реалном времену и десетине улога. Прво опишите једну услугу и једну област. Тако ћете видети где се захтев губи: приликом попуњавања, расподеле, одговора мајстора или избора понуде.

За упите који стижу преко сајта можете да користите и демо четбота за упите. Он приказује кратак разговор по сценарију, референтни број и администраторски панел са упитима. Ово не замењује платформу, али представља практичан улаз за клијенте који још нису инсталирали апликацију.

Како се одређује буџет за апликацију за мајсторе?

Цена зависи од броја улога, платформи, начина претраге, чета, плаћања, провера и интеграција. Само мобилни део може да буде у распону 200–15.000 €. Када додате веб портал, серверску логику, администраторске процесе и CRM или ERP интеграцију, пројекат већ представља софтверску платформу и процењује се у распону 3.000–29.300 €.

Ови распони нису цена готовог производа. На њих утичу број екрана, дизајн, логика упаривања, избор између готове и прилагођене интеграције, потреба за одржавањем и начин прихватања плаћања. Зато добра понуда раздваја MVP, следећу верзију и одржавање, уместо да обећава „све“ у једном укупном износу.

Како да избегнете неуспех због недостатка критичне масе?

Технички функционална апликација не гарантује тржиште. Ако има много клијената, а мало мајстора, захтеви остају без одговора. Ако има много мајстора, а мало клијената, извођачи престају да прате платформу.

Планирајте почетак за уски сегмент: конкретну услугу, област и обећање за обе стране. Обезбедите оператера који ће ручно проверавати прве захтеве и помагати у споровима. Пратите стварне показатеље, као што су време до првог одговора, удео прихваћених понуда и завршене услуге, а не само регистрације и преузимања.

То је и разлог зашто маркетплејс не треба да градите као каталог. Вредност је у поузданом упаривању, јасном процесу и поверењу. Ако ове три ствари не функционишу ручно, аутоматизација ће само брже проширити проблем.

Често постављана питања

Следећа питања се обично постављају пре поверавања оваквог пројекта.

Може ли апликација за мајсторе да ради без вебсајта?

Да, за ограничени MVP можете да почнете са мобилном апликацијом, сервером и администраторским панелом. Веб портал постаје важан када клијенти претражују преко Google-а, мајстори удобније раде са рачунара или имате јавне профиле услуга.

Како се мајстори проверавају на платформи?

На почетку је најпоузданији приступ често ручно одобравање профила и докумената од стране администратора. Након тога могу да се додају аутоматске провере, оцене завршених захтева и правила за блокирање у случају притужби.

Да ли онлајн плаћање треба да буде доступно већ у MVP-у?

Не увек. Ако платформа само повезује клијента и извођача, можете почети са захтевом и понудом. Онлајн плаћање је неопходно када наплаћујете депозит, задржавате провизију или желите да гарантујете резервацију.

Колико кошта израда апликације за мајсторе?

Мобилни MVP се креће у распону 200–15.000 €. Комплетна платформа са веб порталом, административним процесима и CRM или ERP интеграцијама процењује се у распону 3.000–29.300 €, а тачна цена зависи од обима и интеграција.