سامانه تاکسی آنلاین چگونه ساخته میشود؟
وقتی کسی میگوید «میخواهیم یک اسنپ بسازیم»، معمولاً تصویر ذهنیاش دو اپلیکیشن است: یکی برای مسافر، یکی برای راننده.
آن دو اپلیکیشن، کمتر از یکسوم کارند. سامانهٔ حملونقل درخواستی دستکم پنج جزء دارد و سختترینشان آن است که هیچکس نمیبیند.
پنج جزء
اپلیکیشن مسافر. درخواست سفر، دیدن راننده روی نقشه، پرداخت، امتیازدهی.
اپلیکیشن راننده. دریافت پیشنهاد سفر، مسیریابی، مدیریت وضعیت، گزارش درآمد. سختتر از اپ مسافر است، چون ساعتها بازمیماند و باید موقعیت بفرستد بدون اینکه باتری را تمام کند.
موتور تخصیص. قلب سامانه. تصمیم میگیرد کدام راننده کدام سفر را بگیرد.
پنل مدیریت. رانندگان، احراز هویت، شکایات، تسویه، گزارشها. معمولاً از هر دو اپلیکیشن بزرگتر میشود و همیشه در برآورد اولیه کمبها داده میشود.
سرویسهای پایه. نقشه، مسیریابی، پرداخت، پیامک، اعلان.
سختترین بخش: تخصیص
اینجاست که سامانههای خوب از بد جدا میشوند و اینجاست که بیشترین وقت مهندسی میرود.
مسئله در نگاه اول ساده است: نزدیکترین راننده را پیدا کن. در عمل، «نزدیکترین» تقریباً هیچوقت جواب درست نیست:
- رانندهای که از نظر خط مستقیم نزدیک است، ممکن است آنطرف بزرگراه باشد و رسیدنش پانزده دقیقه طول بکشد. فاصلهٔ رانندگی مهم است، نه فاصلهٔ هوایی.
- رانندهای که در حال اتمام سفر است، شاید بهتر از رانندهای باشد که بیکار و دورتر است.
- اگر همیشه نزدیکترین را بدهید، رانندگان مناطق کمتقاضا هیچ سفری نمیگیرند و از سامانه خارج میشوند. توزیع عادلانه یک الزام کسبوکاری است، نه یک ویژگی اخلاقی.
- سفر کوتاه در ساعت اوج ممکن است برای راننده صرف نکند و رد شود؛ ردهای پیاپی یعنی مسافر منتظر میماند.
پس تخصیص یک مسئلهٔ بهینهسازی چندهدفه است: زمان انتظار مسافر، درآمد راننده، نرخ پذیرش، و پوشش جغرافیایی.
توصیهٔ ما برای شروع: ساده شروع کنید — نزدیکترین بر اساس زمان رانندگی تخمینی، با سقف شعاع — و از روز اول همهچیز را ثبت کنید: چه پیشنهادی به چه کسی رفت، رد شد یا قبول، چقدر طول کشید. بدون این داده، بهبود الگوریتم حدسزدن است. با آن، بعد از سه ماه میدانید دقیقاً کجا ضعف دارید.
ردیابی زنده، و مسئلهٔ باتری
موقعیت راننده باید مدام بهروز شود. سه محدودیت با هم میجنگند: دقت، مصرف باتری، و مصرف داده.
آنچه در عمل کار میکند: نرخ ارسال متغیر. رانندهای که سفر فعال دارد هر چند ثانیه، رانندهای که منتظر است هر نیم دقیقه یا فقط وقتی جابهجا شده. اگر راننده بیحرکت است، ارسال بیفایده است.
موقعیت خام را مستقیم نشان ندهید. GPS شهری نویز دارد و نشانگر روی نقشه میپرد. هموارسازی و چسباندن به مسیر جاده، تفاوت بین «حرفهای» و «آماتور» را در تجربهٔ کاربر میسازد.
و برای شبکهٔ ضعیف طراحی کنید. در ایران قطع و وصل شبکه در تونلها و پارکینگها عادی است. اپ راننده باید موقعیتها را در صف نگه دارد و بعد از وصلشدن بفرستد، وگرنه مسیر سفر ناقص ثبت میشود و محاسبهٔ کرایه محل اختلاف میشود.
قیمتگذاری
از نظر فنی ساده است و از نظر کسبوکاری حساسترین بخش.
کرایهٔ پایه + مسافت + زمان. بخش زمان لازم است، وگرنه سفر در ترافیک برای راننده ضرر است.
ضریب اوج. بحثبرانگیز و کارآمد: بدون آن، در ساعت اوج تقاضا چند برابر عرضه میشود و همه منتظر میمانند. با آن، بخشی از تقاضا جابهجا میشود و رانندگان بیشتری آنلاین میشوند.
دو قاعده برای بازار ایران: قیمت را پیش از سفر و قطعی اعلام کنید — کاربر ایرانی به کرایهٔ نامعلوم حساس است — و ضریب اوج را صریح نشان دهید. ضریبی که پنهان باشد، در شبکههای اجتماعی گرانتر تمام میشود از خود ضریب.
پرداخت و تسویه
اینجا نکتهای هست که در راهنماهای خارجی نمیبینید و در ایران تعیینکننده است.
پرداخت نقدی حذف نمیشود. سهم قابل توجهی از سفرها نقدی است. یعنی سامانه باید حسابی برای راننده نگه دارد که گاهی بدهکار است — راننده پول نقد گرفته و کمیسیون سامانه را بدهکار است — و گاهی بستانکار. این حساب دوطرفه، پیچیدهترین بخش مالی سامانه است و اگر از روز اول در مدل داده نباشد، بعداً افزودنش یعنی بازنویسی.
کیف پول راننده با گردش شفاف: هر سفر، هر کمیسیون، هر برداشت. رانندگان دقیقترین کاربران شما در بررسی اعداد هستند و کوچکترین ناهماهنگی را میبینند.
تسویهٔ دورهای بهصورت کار پسزمینه و حتماً قابل اجرای دوباره بدون اثر مضاعف — به دلیلی که در کارهای پسزمینه گفتیم. تسویهای که دوبار اجرا شود، دو بار پول میدهد.
چیزهایی که در برآورد جا میمانند
- احراز هویت راننده: مدارک، گواهینامه، معاینهٔ فنی، تأییدها. یک زیرسامانهٔ کامل با گردش کار.
- پشتیبانی و شکایات: پنلی که اپراتور بتواند سفر را ببیند، مسیر را بازپخش کند و کرایه را اصلاح کند.
- ایمنی: دکمهٔ اضطراری، اشتراکگذاری سفر، ثبت کامل مسیر. در حملونقل مسافر این اختیاری نیست.
- مجوزها و گزارشهای نهادهای شهری.
- پنل سازمانی، اگر مشتری شرکتی دارید: سفر با حساب شرکت، سقف ماهانه، گزارش و فاکتور واحد. معمولاً پرحاشیهسودترین بخش کسبوکار است و دیر به آن فکر میشود.
بسازیم یا از سامانهٔ آماده شروع کنیم؟
سؤال درستی است و جواب به یک چیز برمیگردد: آیا تمایز شما در الگوریتم است یا در بازار؟
اگر شهر یا حوزهٔ مشخصی را هدف گرفتهاید و تمایزتان در جذب راننده و مشتری است، ساختن همهٔ اینها از صفر یک تا دو سال تأخیر است که رقیب در آن مدت بازار را میگیرد. سواری دقیقاً برای این حالت ساخته شده — پایهٔ آماده با امکان تغییر در قواعد تخصیص و قیمتگذاری.
اگر مدل کسبوکارتان اساساً متفاوت است — حمل بار، سرویس مدارس، ناوگان سازمانی با قواعد خاص — ساخت اختصاصی منطقی است.
نمونهٔ اجراییاش را در APT Rides میبینید: سامانهای که برای بازار ونکوور راهاندازی شد و همان اجزایی را دارد که در این مقاله شمردیم، با قواعد محلی خودش.
جمعبندی
اگر یک چیز از این مقاله بماند: موتور تخصیص و حساب مالی راننده را جدی بگیرید. دو اپلیکیشن، بخش قابل تخمین کارند. این دو، بخشی هستند که کیفیت سامانه و رضایت رانندگان — که بدون آنها سامانهای نیست — به آنها بستگی دارد.