Прыкладанне для майстроў: што яно павінна ўключаць

Што вы насамрэч ствараеце — прыкладанне ці двухбаковая платформа?

У звычайным мабільным прыкладанні ёсць адзін асноўны карыстальнік і адзін асноўны сцэнарый. Напрыклад, кліент браніруе час або адпраўляе форму. У прыкладанні для майстроў ёсць як мінімум два бакі: кліент і выканаўца. Паміж імі знаходзіцца аператар, які сочыць за якасцю, спрэчкамі, плацяжамі і незавершанымі заяўкамі.

Гэта робіць прадукт двухбаковай платформай. Заяўку можа стварыць кліент, адфільтраваць па паслузе і раёне, адправіць некалькім падыходным майстрам, ператварыць у прапанову, абмеркаваць у чаце, прыняць, выканаць і ацаніць. Кожны этап павінен мець уласны статус і гісторыю.

Добры прыклад — кейс 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 €.

Гэтыя дыяпазоны не з’яўляюцца коштам гатовага прадукту. На іх уплываюць колькасць экранаў, дызайн, логіка супастаўлення, выбар паміж гатовай і custom інтэграцыяй, патрэба ў падтрымцы і спосаб прыёму плацяжоў. Таму добрая прапанова падзяляе MVP, наступную версію і падтрымку, а не абяцае «ўсё» за адну агульную суму.

Як пазбегнуць правалу праз адсутнасць крытычнай масы?

Тэхнічна працуючае прыкладанне не гарантуе наяўнасці рынку. Калі кліентаў шмат, а майстроў мала, заяўкі застаюцца без адказу. Калі майстроў шмат, а кліентаў мала, выканаўцы перастаюць сачыць за платформай.

Плануйце запуск для вузкага сегмента: канкрэтная паслуга, раён і абяцанне абодвум бакам. Забяспечце ручнога аператара, які правярае першыя заяўкі і дапамагае пры спрэчках. Адсочвайце рэальныя паказчыкі: час да першага адказу, долю прынятых прапаноў і завершаных паслуг, а не толькі рэгістрацыі і спампоўванні.

Вось чаму не варта будаваць маркетплейс як каталог. Каштоўнасць — у надзейным супастаўленні, зразумелым працэсе і даверы. Калі гэтыя тры рэчы не працуюць уручную, аўтаматызацыя толькі хутчэй распаўсюдзіць праблему.

Часта задаваныя пытанні

Наступныя пытанні звычайна ўзнікаюць перад даручэннем такога праекта.

Ці можа прыкладанне для майстроў працаваць без сайта?

Так, для абмежаванага MVP можна пачаць з мабільнага прыкладання, сервера і адміністрацыйнай панэлі. Вэб-партал становіцца важным, калі кліенты шукаюць праз Google, майстрам зручней працаваць з камп’ютара або ў вас ёсць публічныя профілі паслуг.

Як правяраюць майстроў на платформе?

На пачатку самым надзейным падыходам часта з’яўляецца ручное ўхваленне профілю і дакументаў адміністратарам. Пазней можна дадаць аўтаматычныя праверкі, ацэнкі па завершаных заяўках і правілы блакіроўкі пры скаргах.

Ці патрэбна анлайн-аплата ўжо ў MVP?

Не заўсёды. Калі платформа толькі злучае кліента і выканаўцу, можна пачаць з заяўкі і прапановы. Анлайн-аплата патрэбна, калі вы збіраеце дэпазіт, утрымліваеце камісію або хочаце гарантаваць браніраванне.

Колькі каштуе распрацоўка прыкладання для майстроў?

Мабільны MVP трапляе ў дыяпазон 200–15 000 €. Поўная платформа з вэб-парталам, працэсамі адміністратара і інтэграцыямі з CRM або ERP ацэньваецца ў дыяпазоне 3 000–29 300 €, а дакладны кошт залежыць ад аб’ёму і інтэграцый.