कार्यस्थान setup
Offera company कार्यस्थान, profile, user और इतना catalog data लेकर शुरू होता है कि real कोटेशन बनाया जा सके।
Offera/सहायता/अवलोकन
Offera शुरू करने से पहले साफ जवाब।
साइन इन करने से पहले Offera के मुख्य प्रवाह समझें: कार्यस्थान सेटअप, AI-सहायता से अनुरोध संभालना, चैनल, कोटेशन, बिलिंग, सुरक्षा, इंटीग्रेशन और लॉन्च से जुड़े सामान्य प्रश्न।
Offera FAQ | इस्तेमाल से पहले जवाब
Multi-channel कोटेशन workflow platform
कार्यस्थान setup
Plans और usage limits
AI और request parsing
Customer channels
Topic के अनुसार
Offera के सामान्य प्रवाहों के लिए सहायता विषय
Plans और usage limits
Plan features और quotas तय करता है। Active limits app के billing area से verify होने चाहिए।
AI और request parsing
AI customer message पढ़कर उसे कोटेशन structure में बदलने में मदद करता है जिसे human review कर सके।
Customer channels
Email, WhatsApp और webhook configured हों तो customer requests को Offera workflow से जोड़ते हैं।
कोटेशनs, PDF और signatures
कोटेशन draft से sent, viewed, accepted, rejected, expired, PDF, signature और payment states तक active features के अनुसार जाता है।
Payment और invoices
Payment active provider और company plan rules के अनुसार चलता है।
Security और data separation
Offera tenant separation पर चलता है: एक company का data दूसरी company से mix नहीं होना चाहिए।
API और integrations
Integrations केवल सच में available endpoints, webhooks और published technical docs पर चलने चाहिए।
Troubleshooting
Issue आए तो support से पहले URL, time, account, tenant और steps collect करें।
01 / शुरुआत
कार्यस्थान setup
Offera company कार्यस्थान, profile, user और इतना catalog data लेकर शुरू होता है कि real कोटेशन बनाया जा सके।
Offera account कैसे बनता है?
Registration company कार्यस्थान बनाता है और user को उसी tenant में रखता है। Onboarding operating area, locale और company context पूछता है ताकि सही setup screens दिखें।
- Sector selection suggested attributes और aliases import कर सकता है।
- यह process sample products को automatic catalog में नहीं जोड़ता।
पहले कोटेशन का सबसे छोटा रास्ता क्या है?
कम से कम एक customer और एक product जोड़ें, फिर dashboard या incoming request से कोटेशन बनाएँ।
- Public कोटेशन link केवल customer-facing response surface दिखाता है।
- Internal notes और settings authenticated app में रहते हैं।
02 / Plans
Plans और usage limits
Plan features और quotas तय करता है। Active limits app के billing area से verify होने चाहिए।
क्या सभी features हर company के लिए active हैं?
नहीं। AI, channels, payments, signatures और team limits plan तथा कार्यस्थान configuration पर निर्भर करते हैं।
- Feature inactive हो तो UI को status साफ बताना चाहिए।
- Plan change catalog या customer data नहीं बदलना चाहिए।
Active limits कहाँ दिखेंगे?
Login के बाद Billing और Settings आपकी company का plan, usage और feature status दिखाते हैं।
- Public FAQ real-time plan data का replacement नहीं है।
- App में दिखने वाले numbers source of truth हैं।
03 / AI
AI और request parsing
AI customer message पढ़कर उसे कोटेशन structure में बदलने में मदद करता है जिसे human review कर सके।
Offera AI क्या करता है?
AI products search कर सकता है, stock check कर सकता है, rules हों तो price compute कर सकता है और parse result confirmation के लिए तैयार करता है।
- Step limit है ताकि process infinite न चले।
- Uncertain case human review के लिए mark होना चाहिए।
क्या aliases हमेशा safe हैं?
नहीं। Alias केवल तब लगाएँ जब names वास्तव में उसी catalog item को refer करते हों।
- यदि “board” और “lumber” आपकी company में अलग products हैं, उन्हें alias न बनाएँ।
- Wrong alias AI से wrong product pick करा सकता है।
04 / चैनल
Customer channels
Email, WhatsApp और webhook configured हों तो customer requests को Offera workflow से जोड़ते हैं।
क्या Offera हर channel अपने-आप पढ़ता है?
नहीं। Channel को कार्यस्थान में connect और authorize करना होता है। Connection status चैनल या Settings में दिखता है।
- Disconnected channel active नहीं माना जाता।
- Connection failure setup item के रूप में handle होना चाहिए।
क्या एक channel कई companies में share हो सकता है?
ऐसा नहीं होना चाहिए। Channel ownership clear होना जरूरी है ताकि messages गलत tenant में न जाएँ।
- Security logs ownership conflict flag कर सकते हैं।
- Production use से पहले conflict resolve होना चाहिए।
05 / कोटेशनs
कोटेशनs, PDF और signatures
कोटेशन draft से sent, viewed, accepted, rejected, expired, PDF, signature और payment states तक active features के अनुसार जाता है।
Customer क्या देखता है?
Customer केवल कोटेशन की public response page देखता है। Internal data public link में नहीं दिखता।
- viewed और accepted जैसे statuses flow tracking के लिए हैं।
- कोटेशन content send करने से पहले review होना चाहिए।
क्या electronic signature हमेशा active है?
PDF generation aur e-signature production-ready workflow surfaces hain. Offera Documenso aur DocuSign provider integrations support karta hai; active provider environment aur workspace setup ke hisaab se select hota hai.
- Workspace mein configured e-signature capability promise karein, kisi specific provider ka naam tab tak nahi jab tak woh provider workspace ke liye enabled na ho.
- Signature status related कोटेशन पर साफ होना चाहिए।
06 / Payment
Payment और invoices
Payment active provider और company plan rules के अनुसार चलता है।
कौन सा payment provider इस्तेमाल होता है?
Code provider-based payment flows support करता है। Active provider static FAQ से नहीं, production environment और settings से confirm होना चाहिए।
- Configuration के बिना किसी provider को active assume न करें।
- Payment status सही कोटेशन या invoice से linked होना चाहिए।
क्या invoice automatically बनती है?
Invoice flow कार्यस्थान में active features पर निर्भर है। यह FAQ inactive automation का वादा नहीं करता।
- Actual status Billing में देखें।
- Payment data system trace के बिना manually नहीं लिखना चाहिए।
07 / Security
Security और data separation
Offera tenant separation पर चलता है: एक company का data दूसरी company से mix नहीं होना चाहिए।
क्या मेरी company का data अलग है?
हाँ, app design tenant/कार्यस्थान के आधार पर data separate करता है। External audit claims केवल तब लिखे जाते हैं जब वे सच में मौजूद हों।
- Super admin operational signals देख सकता है।
- दूसरे tenants super admin panel नहीं देखते।
Suspicious device logs का मतलब क्या है?
Same-device multi-account जैसे logs review signals हैं, automatic punishment नहीं।
- Admin को action से पहले context देखना चाहिए।
- Logs के explanations जोड़े गए हैं ताकि बाहर search न करना पड़े।
08 / API
API और integrations
Integrations केवल सच में available endpoints, webhooks और published technical docs पर चलने चाहिए।
क्या public API domain है?
Official configuration में न हो तो domain use न करें। Public API publish हो तो docs में base URL, auth, rate limit और correct payload examples होने चाहिए।
- FAQ fake API domains नहीं लिखता।
- Webhooks validate और log होने चाहिए ताकि audit हो सके।
क्या integration catalog बदल सकती है?
केवल authorized integration और related endpoint data बदल सकते हैं।
- Bulk import को production से पहले validation चाहिए।
- Integration error original request तक trace होना चाहिए।
09 / Help
Troubleshooting
Issue आए तो support से पहले URL, time, account, tenant और steps collect करें।
Support को क्या भेजना चाहिए?
Company name, account email, page URL, time और error से पहले last action भेजें।
- पासवर्ड या secret token न भेजें।
- Sensitive data न हो तो screenshot मदद करता है।
AI request गलत parse करे तो?
कोटेशन send करने से पहले result correct करें और case review के लिए mark करें।
- Product aliases और sector attributes check करें।
- Repeated error हो तो admin parse logs और tool steps देखे।
Member हैं?
Login के बाद मदद चाहिए?
Account और company data वाली requests के लिए app के अंदर Support खोलें।
App में जाएँMember नहीं हैं?
कार्यस्थान खोलने से पहले पूछें
Launch access या product-fit questions के लिए private customer data share किए बिना Offera Studio से contact करें।
Offera से contact करें