hamid
2.5 KiB
Future Ideas & Backlog
Raw product thinking captured for later — not committed MVP scope. Original notes were in Farsi
(additional-info.txt); kept verbatim with light framing.
1. Platform-owned pricing flow (آینده / future)
فلوی قیمت باید سمت ما باشه:
- وقتی فرد میخواد دستمزد ساعتی و روزانهاش رو مشخص کنه، باید یه رنجی از بازار بهش نشون بدیم و چند تا نکته بنویسیم: اگر زیاد گذاشت یا کم، که «رنج مناسبی نذاشتی و مشتریهات کم میشه»؛ و نسبت به سابقه و مهارتها یه عدد پیشنهادی توی بازه بهش نشون بدیم که کار رو راحتتر کنه.
- در آینده باید داستان بوست (boost) رو برای هر دو طرف مشخص کنیم — اگر مشتری بخواد زودتر کسی رو پیدا کنه، یا پرستار بخواد زودتر کار بگیره (مرحلهٔ خیلی بعد).
- کل پروسهٔ بید زدن (bidding) پرستارها رو بذاریم برای بعداً — چون مشتری رو ناراضی میکنه و الان وقتش نیست.
Relates to today's MVP, where nurses set their own transparent prices per variant — see Service Catalog & Pricing. Surge/boost/bidding are explicitly deferred there.
2. Installments only above a meaningful threshold
سیستم اقساطی باید بصرفه باشه — نباید برای یک روز خدمات قسطی بدیم. برای درخواستهای بالای سه روز (شاید حتی بالاتر) منطقیتره که عددش معنیدار بشه — کسی ۴–۵ تومن رو قسطی نمیکنه. (این گمان هست؛ باید دیتای بیشتری ببینیم.)
پس نیاز داریم بتونیم برای بازههای قیمتی متفاوت، گزینههای پرداخت (کارت / BNPL) رو فعال یا غیرفعال کنیم.
Implementation hook: a config-driven rule that enables/disables BNPL by booking total / duration. See the BNPL business area and
platform_configsin audit, config & reference.
3. Blog (آینده / future)
برای آینده، یک بلاگ در نظر داشته باشیم.