Files
baya-monorepo/product/notes/future-ideas.md
T
2026-06-24 01:32:46 +03:30

46 lines
2.5 KiB
Markdown

# Future Ideas & Backlog
[← Product docs home](../index.md)
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](../business/03-service-catalog-and-pricing.md). 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](../business/09-installments-bnpl.md) and
> `platform_configs` in [audit, config & reference](../data-model/12-audit-config-and-reference.md).
---
## 3. Blog (آینده / future)
برای آینده، یک **بلاگ** در نظر داشته باشیم.