টিকেট ও উপস্থিতি ব্যবস্থার জন্য একটি ইভেন্ট সংগঠক ওয়েব অ্যাপ বানান

লক্ষ্য, ব্যবহারকারী এবং স্কোপ স্পষ্ট করুন

ফিচার বা টেকস্ট্যাক বেছে নেওয়ার আগে নিশ্চিতভাবে জানুন কেন আপনি বানাচ্ছেন এবং সাফল্য কীভাবে দেখাবে। এটা না করলে টিকেটিং প্ল্যাটফর্ম অর্ধেক সম্পন্ন টুলের সংগ্রহে পরিণত হতে পারে।

ব্যবহারকারী ও মূল কাজ নির্ধারণ

প্রাথমিক কাস্টমারের নাম দিন—প্রতিটি ধরণের ব্যবহারকারী ভিন্ন ফলাফল অগ্রাধিকার দেয়:

• সোলো অর্গানাইজার দ্রুততা চান: একটি ইভেন্ট তৈরি, টিকেট বিক্রি, এবং সাপোর্টে ডুবতে না চাওয়া।
• ভেনিউ বারবার ব্যবহারের সেটআপ, ক্যাপাসিটি কন্ট্রোল এবং ফাস্ট অন‑সাইট অপারেশন নিয়ে বেশী চিন্তিত।
• এজেন্সি একাধিক ইভেন্ট ম্যানেজ, ক্লায়েন্ট এক্সেস, এবং পরিষ্কার রিপোর্ট চান।

কোর কাজ এক বাক্যে লিখুন, উদাহরণ: ‘সহজে টিকেট বিক্রি করতে এবং উপস্থিতদের ভুলচুক কম করে চেক-ইন করা সহায়তা করা।’

কোর ওয়ার্কফ্লো (end-to-end) ম্যাপ করুন

যে পথগুলো ঠিকভাবে কাজ করতে হবে তা তালিকাভুক্ত করুন:

Create event → set ticket types/pricing → publish → attendee registers → payment → ticket issued → check-in via QR → exports/reporting.

যদি cualquiera ধাপ বাদ পড়ে বা দুর্বল হয়, অ্যাপ অসম্পূর্ণ মনে হবে যদিও অনেক অতিরিক্ত ফিচার থাকুক।

আপনি যে মেট্রিকগুলো ট্র্যাক করবেন তা ঠিক করুন

ওয়ার্কফ্লোগুলোর সাথে জড়িত কিছু পরিমাপযোগ্য আউটকাম বেছে নিন:

• Checkout conversion rate (registration → completed order)
• Average check-in time প্রতি উপস্থিতি এবং ব্যর্থতার হার (QR স্ক্যান ইস্যু)
• Refund/transfer time (request → resolved)
• Support volume প্রতি ইভেন্ট (এবং প্রধান কারণগুলো)

MVP বনাম v1 সিদ্ধান্ত নিন

MVP হওয়া উচিত “day one এ ব্যবহারযোগ্য”: ইভেন্ট ক্রিয়েট করা, টিকেট সেল, কনফার্মেশন, বেসিক চেক‑ইন, এবং সহজ এক্সপোর্ট। পরবর্তী রিলিজে (v1) চমৎকার‑থাকা আইটেমগুলো (ডিসকাউন্ট রুল, সিটিং ম্যাপ, জটিল ট্যাক্স লজিক) রাখুন—প্রয়োজনীয়তা যাচাই করার পর।

সীমাবদ্ধতা আগে থেকেই চিহ্নিত করুন

স্পষ্টভাবে লিখে রাখুন বাজেট, টাইমলাইন, এবং টিম স্কিলস—এগুলো নির্ধারণ করে কি সব কাস্টম বানাবেন বা কি পরিষেবা ব্যবহার করবেন। কমপ্লায়েন্স চাহিদা (ট্যাক্স ইনভয়েস, GDPR/CCPA, পেমেন্ট রুল) আগে থেকে লক্ষ্য করুন যাতে পরে ডিজাইন পরিবর্তন না করতে হয়।

কোর ফিচার ও ইউজার স্টোরি

স্ক্রিন বা ডাটাবেস বাছাই করার আগে নির্ধারণ করুন অ্যাপকে মানুষকে ঠিক কি করতে দিতে হবে—আর 'মানুষ' কারা। ভালো ইভেন্ট ম্যানেজমেন্ট ওয়েব অ্যাপ সাধারণত কয়েকটি আলাদা রোল রাখে, প্রত্যেকটির ভিন্ন পারমিশন ও প্রত্যাশা থাকে।

রোল এবং পারমিশন (কারা কি করতে পারে)

শুরুতে সহজ রাখুন, পরে বাড়ান:

• Organizer: ইভেন্ট তৈরি, টিকেট প্রকাশ, সেটিংস ম্যানেজ, রিফান্ড/ক্যান্সেল করতে পারে।
• Staff: উপস্থিতি তালিকা দেখতে পারে, QR কোড স্ক্যান করে চেক‑ইন করতে পারে, সীমিত এডিট।
• Finance: অর্ডার, পেআউট, ইনভয়েস/রিসিট দেখে, চার্জব্যাক এবং রিফান্ড হ্যান্ডেল করে।
• Attendee: রেজিস্ট্রেশন, পেমেন্ট, টিকেট পাওয়া, নিজের অর্ডার ডিটেইলস ম্যানেজ করে।

একটা বাস্তব নিয়ম: যদি কেউ মানি‑রিলেটেড ফিল্ড বা ইভেন্ট ভিজিবিলিটি বদলাতে পারে, সেটা আলাদা পারমিশন হওয়া উচিত।

মূল পেজগুলো (“happy path”) পরিকল্পনা করুন

কোর ন্যাভিগেশন ড্রাফট করুন যাতে ফিচার র‌্যান্ডম এন্ডপয়েন্টে বদলে না যায়:

• Event setup (নাম, ভেনিউ/অনলাইন ডিটেইল, তারিখ/টাইমজোন, ক্যাপাসিটি, নীতি)
• Ticket builder (টাইপ, মূল্য, সেল উইন্ডো, লিমিট, প্রোমো কোড যদি দরকার)
• Checkout + confirmation (রেজিস্ট্রেশন ফর্ম, পেমেন্ট, রিসিপ্ট, টিকেট ডেলিভারি)
• Order details (স্ট্যাটাস, পেমেন্ট, রিফান্ড ইতিহাস, অ্যাটেন্ডি অ্যাসাইনমেন্ট)
• Attendee list + check-in (সার্চ, ফিল্টার, QR স্ক্যান, চেক‑ইন লগ)
• Organizer dashboard (সেলস সামারি, ক্যাপাসিটি, অ্যালার্ট, রিসেন্ট অ্যাক্টিভিটি)

টেস্টেবেল এক্সেপ্ট্যান্স ক্রাইটেরিয়া সহ ইউজার স্টোরি

সংক্ষিপ্ত স্টোরি লিখুন যা একবারে ভেরিফাই করা যায়:

• Organizer publishes tickets: Given একটি ইভেন্ট ড্রাফটে আছে, যখন আমি “General Admission” টিকেট যোগ করে মূল্য ও সেল ডেট দিই, তখন সেটা পাবলিক রেজিস্ট্রেশন পেজে দেখা যাবে এবং শেষ তারিখের পর আর বিক্রি হবে না।
• Attendee buys a ticket: যখন পেমেন্ট সফল, তখন অর্ডার তৈরি হয়, একটি ইউনিক টিকেট/QR ইস্যু হয়, এবং 2 মিনিটের মধ্যে কনফার্মেশন ইমেইল পাঠানো হয়।
• Staff checks in attendee: যখন আমি একটি বৈধ QR স্ক্যান করি, তখন উপস্থিতিকে “checked in” হিসেবে চিহ্নিত করা হবে, টাইমস্ট্যাম্প হয়ে যাবে, এবং একই QR পুনরায় ব্যবহার করা যাবেনা—বাধ্যতামূলক ওভাররাইড পারমিশন না থাকলে।

সমঝা‑বাহ্য কেসগুলো সমর্থন করুন

আগেভাগে পরিকল্পনা করুন যাতে পরে জটিল প্যাচ না করতে হয়: sold out, duplicate orders, partial refunds, chargebacks, canceled/rescheduled events, failed email delivery, offline check-in, এবং transfers/reassigning tickets।

প্রতিটি ওয়ার্কফ্লোতে যে ডাটা স্টোর করতে হবে

কমপক্ষে: ইভেন্ট স্ট্যাটাস ও ক্যাপাসিটি, টিকেট টাইপ রুল (লিমিট, উইন্ডো), অর্ডার/পেমেন্ট স্ট্যাটাস, উপস্থিতি পরিচয় ক্ষেত্র, QR কোড/টোকেন, এবং একটি অ্যাপেন্ড‑ওনলি check-in log (কে কাকে, কখন, কোন ডিভাইসে চেক‑ইন করেছে)। এই ‘পেপার ট্রেইল’ বিরোধে জরুরি।

ইভেন্ট, টিকেট, অর্ডার এবং উপস্থিতিদের জন্য ডেটা মডেল

স্পষ্ট ডেটা মডেল থাকলে প্ল্যাটফর্মটাকে সহজে উন্নত করা যায়। শুরুতে সংরক্ষণযোগ্য সত্তাগুলো নির্ধারণ করুন (events, ticket types, orders, attendees) এবং তাদের সম্পর্ক।

Event: সত্যতার উৎস

একটি Event-এ শিডিউল, লিমিট এবং প্রকাশ সংক্রান্ত তথ্য থাকা উচিত:

• Basics: title, description, organizer_id
• Dates: start_at, end_at, timezone (টাইমস্ট্যাম্প UTC-তে স্টোর করুন, ইভেন্ট টাইমজোন ব্যবহার করে প্রদর্শন করুন)
• Venue: venue_name, address, city, country (পুনঃব্যবহারের জন্য আলাদা Venue টেবিল রাখতে পারেন)
• Capacity: total_capacity (এবং অপশনালি per-ticket caps)
• Status: draft, published, canceled, ended

এই স্ট্রাকচার ড্রাফট ইভেন্ট লুকানো, ক্যাপাসিটি ভর্তি হলে সেল বন্ধ করা, এবং সঠিক লোকাল টাইম দেখানোর মতো চাহিদা সাপোর্ট করে।

Ticket types: কী বিক্রয় হচ্ছে

একটি TicketType অফার সংজ্ঞায়িত করে:

• name, description, price, currency
• quantity_available (এবং quantity_sold)
• sales_window: sales_start_at, sales_end_at
• taxes/fees: tax_rate (বা tax_id), fee_flat/fee_percent, “fees_included” ফ্ল্যাগ
• add-ons: আলাদা TicketTypes বা AddOn টেবিল হিসেবে মডেল করুন
• discount codes: DiscountCode টেবিল (code, type percent/fixed, amount, usage_limit, valid window) Event‑এর সাথে লিঙ্ক করে এবং আংশিকভাবে নির্দিষ্ট TicketTypes‑এর জন্য প্রযোজ্য করতে পারেন

Orders এবং payments: আর্থিক লেনদেন

কমার্সকে দুই স্তরে ভাগ করুন:

• Order: order_number, event_id, buyer_email, subtotal, taxes, fees, total, order_status (pending/confirmed/canceled)
• Payment: provider (Stripe, ইত্যাদি), provider_payment_id, payment_status (requires_action/paid/failed/refunded), amount, captured_at

রিফান্ডগুলো আলাদা রেকর্ড (Refund টেবিল) হিসেবে রাখা ভালো যাতে আংশিক রিফান্ড করা যায় এবং ক্লিয়ার অডিট ট্রেইল থাকে। Order‑এ receipt/invoice ফিল্ড (billing_name, billing_address, vat_id) রাখুন।

Attendees: টিকেট কার কাছে

একটি Attendee (বা TicketInstance) এ থাকতে পারে:

• event_id, ticket_type_id, order_id
• attendee fields (name, email, কাস্টম ফর্ম উত্তর)
• টিকেট অ্যাসাইনমেন্ট + transfer: assigned_to_email, transfer_token, transferred_at
• check-in: check_in_state (not_checked_in/checked_in), checked_in_at, checked_in_by
• ট্যাগ/নোট (স্টাফের জন্য, VIP বা অ্যাক্সেসিবিলিটি রিকোয়েস্টের মতো)

ইম্পোর্ট/এক্সপোর্ট এবং অপারেশনাল ফিল্ড

CSV এক্সপোর্ট পরিকল্পনা আগে থেকেই করুন: consistent ফিল্ড নাম (order_number, ticket_type, attendee_name, checked_in_at) রাখুন এবং ব্যাজ‑প্রিন্টিং ক্ষেত্র অন্তর্ভুক্ত করুন।

ইন্টিগ্রেশন আশা করলে হালকা “webhook events” বা আউটবক্স টেবিল যোগ করুন যাতে অ্যাডমিন প্যানেল নিরাপদে এক্সপোর্ট বা API হুক টিগার করতে পারে।

টেক স্ট্যাক ও আর্কিটেকচার সিদ্ধান্ত

সবচেয়ে ভালো স্ট্যাক হলো সেইটা যা আপনার টিম নিবার্চিত সময়ে বিল্ড, শিপ এবং সাপোর্ট করতে পারে। ইভেন্ট ম্যানেজমেন্ট অ্যাপে iteration‑এর গতি তাত্ত্বিক পারফেকশন অপেক্ষা বেশি গুরুত্বপূর্ণ—বিশেষ করে রিয়েল ট্রাফিক জানা না থাকলে।

সহজ শুরু: প্রথমে মনোলিথ, পরে স্প্লিট

একক কোডবেইজ (monolith) সাধারণত শুরুতে সঠিক। ডিপ্লয়মেন্ট, ডিবাগ ও ডেটা অ্যাকসেস সহজ থাকে—যা ফিচার ভ্যালিডেশন‑এ গুরুত্বপূর্ণ।

গুরুতর কারণে আলাদা সার্ভিসে ভাগ করুন: কোন অংশ স্বাধীনভাবে স্কেল করা দরকার, টিমগুলো একে অপরের ওপর চড়াপ্পা করছে, বা ডিপ্লয়মেন্ট ঝুঁকিপূর্ণ হচ্ছে। অনেক সময় মনোলিথেই মডিউলারাইজ করে সমস্যার অনেকটাই সমাধান করা যায়।

বাস্তবসম্মত স্ট্যাক বেছে নিন

একটি প্রমাণিত কম্বো দেখতে পারে:

• Frontend: React (Next.js) বা Vue (Nuxt) দ্রুত UI ডেভেলপমেন্ট এবং SEO‑ফ্রেন্ডলি ইভেন্ট পেজের জন্য।
• Backend: Node.js (NestJS/Express) বা Python (Django/FastAPI). আপনার টিম যে ভাষা জানে তা বেছে নিন।
• Database: PostgreSQL সম্পর্কিত ডাটার জন্য (events, orders, attendees) এবং নির্ভরযোগ্য ট্রানজেকশন।
• Hosting: Managed প্ল্যাটফর্ম (Render/Fly.io/Heroku‑স্টাইল) বা ক্লাউড PaaS। Managed ডাটাবেস মূল্যবান।

ট্রেন্ডি টুল বেছে নেওয়ার চেয়ে টিমের অন-কল রাখতে সক্ষম এমন ‘বোরিং’ অপশনই জেতা সুবিধা দেয়।

Koder.ai ব্যবহার করে ইমপ্লিমেন্টেশন ত্বরান্বিত করা (ঐচ্ছিক)

MVP দ্রুত শিপ করা আপনার অগ্রাধ্য হলে (ইভেন্ট সেটআপ, চেকআউট, টিকেট ইস্যু, QR চেক‑ইন, এক্সপোর্ট), Koder.ai মতো ভিব‑কোডিং প্ল্যাটফর্ম সাহায্য করবে স্পেস থেকে কাজকার্য চালু করতে।

Koder.ai‑এর ডিফল্ট স্ট্যাক সাধারণ টিকেটিং চাহিদার সঙ্গে ভালো মানায়—React ফ্রন্টএন্ড, Go + PostgreSQL ব্যাকএন্ড—এবং আপনি Planning Mode, snapshots/rollback, source code export ব্যবহার করে নিরাপদে ইটারের করতে পারেন এবং সম্পূর্ণ কোডের মালিকানা রাখতে পারেন।

স্টোরেজ ও ইমেইল: প্রথম শ্রেণির নির্ভরযোগ্যতা

ইভেন্ট ইমেজ, জেনারেট করা ইনভয়েস ও PDF টিকেট কোথায় রাখবেন তা পরিকল্পনা করুন:

• Object storage (S3‑compatible) আপলোড ও জেনারেটেড ফাইলের জন্য।
• প্রয়োজন হলে CDN দ্রুত গ্লোবাল ডেলিভারির জন্য পরে যোগ করুন।

ইমেইল কনফার্মেশন ও রিমাইন্ডার জন্য ডেডিকেটেড প্রোভাইডার (SendGrid, Postmark, SES) ব্যবহার করুন—বিষ‌ণু ডেলিভারিবিলিটি ও লগস দেয় যখন উপস্থিতি বলে “আমি আমার টিকেট পাইনি।”

এনভায়রনমেন্ট ও কী ম্যানেজমেন্ট

শুরুতেই local, staging, এবং production সেটআপ করুন—প্রতিটির আলাদা:

• পেমেন্ট কী, ইমেইল ক্রেডেনশিয়াল, ওয়েবহুক সিক্রেট
• ডাটাবেস (ডেভে প্রোড ডাটার কপি করবেন না)
• বেস URL এবং কলব্যাক URL

এতে দুর্ঘটনাজনিত চার্জ প্রতিরোধ হবে এবং টেস্টিং বাস্তবসম্মত থাকবে।

স্ট্যান্ডার্ডস ও রিলিজ প্রবাহ

কিছু মৌলিক সিদ্ধান্ত নিন: ফরম্যাটিং (Prettier/Black), লিন্টিং, কমিট কনভেনশন, এবং সিম্পল রিলিজ ফ্লো (ফিচার ব্রাঞ্চ + কোড রিভিউ + CI)। এখানে সামান্য শৃঙ্খলা চেকআউট ও টিকেট ডেলিভারির বাগ কমায়—যেখানে ভুল সবচেয়ে দামি।

UX এবং UI: রেজিস্ট্রেশন, চেকআউট ও অর্গানাইজার ড্যাশবোর্ড

ভাল UX মূলত অনিশ্চয়তা কমানো: উপস্থিতি জানতে চায় তারা কী কিনছে, অর্গানাইজার জানতে চায় বিক্রি ও চেক‑ইন কন্ট্রোল‑এ আছে কি না।

Attendee ফ্লো (পুনরাবৃত্তি সহজ রাখুন)

সোজা পথ ডিজাইন করুন: event page → ticket selection → checkout → confirmation। প্রতিটি ধাপ এক প্রশ্নের উত্তর দেবে:

• Event page: “এই ইভেন্ট কি আমার জন্য?”
• Ticket selection: “কোন টিকেট নেব, এবং এটা এখনও আছে কি?”
• Checkout: “আমি দ্রুত ও নিরাপদে পে করতে পারছি কি?”
• Confirmation: “পরবর্তী কী, এবং কিভাবে প্রবেশ করব?”

টিকেট নির্বাচন অংশে উপলব্ধতা ও নিয়ম স্পষ্ট দেখান। বাকি টিকেট সংখ্যা, সেল স্টার্ট/এন্ড টাইম (টাইমজোনসহ), এবং টিকেট বিক্রি শেষ হলে কী হবে (ওয়েটলিস্ট, বিক্রি বন্ধ, বা অর্গানাইজারের কাছে যোগাযোগ) দেখান।

প্রোমো কোড থাকলে ফিল্ড লুকাবেন না, কিন্তু প্রধান অ্যাকশনের সমান ভিজ্যুয়াল ওয়েট দেবেন না।

ফর্ম: ডিফল্টে সংক্ষিপ্ত, দরকারে বিস্তারিত

চেকআউট ফ্রিকশন রেজিস্ট্রেশন ড্রপের মূল কারণ। প্রাথমিক ফর্ম সংক্ষিপ্ত রাখুন (name, email, payment) এবং বিকল্প প্রশ্নগুলোর জন্য progressive disclosure ব্যবহার করুন।

উদাহরণ:

• “আপনি কি ইনভয়েস চান?” → যদি হ্যাঁ, বিলিং ফিল্ড দেখানো হবে
• “আপনি কার জন্য কিনছেন?” → যদি না, প্রতি টিকেট অ্যাটেন্ডি ডিটেইল দেখান
• “কোন অ্যাক্সেসিবিলিটি প্রয়োজন?” → ঐচ্ছিক, সহায়ক লাইন সহ

একাধিক টিকেট এক অর্ডারে হলে, স্পষ্টভাবে আলাদা করুন buyer ইনফো (রিসিপ্ট, পেমেন্ট) এবং attendee ইনফো (নাম, চেক‑ইন)।

কনফার্মেশন যা সাপোর্ট টিকিট কমায়

পেমেন্টের পর কনফার্মেশনে থাকা উচিত: ইভেন্ট ডিটেইল, টিকেট সারাংশ, QR কোড‑অ্যাক্সেস (বা “ticket attached”), এবং একটি স্পষ্ট পরবর্তী ধাপ (“Add to calendar”, “Manage my order”)। একটি হালকা অর্ডার ম্যানেজমেন্ট পেজ লিংক দিন যেমন /orders/lookup।

Organizer ড্যাশবোর্ড: এক नजरেই প্রশ্নের উত্তর

অর্গানাইজাররা সাধারণত ড্যাশবোর্ড খুলে তিনটি সংখ্যা দেখে: tickets sold, revenue, এবং check-ins। এগুলো টপে রাখুন, তারপর দ্রুত ফিল্টার (তারিখ, টিকেট টাইপ, স্ট্যাটাস, রিফান্ড) দিন।

চেক‑ইন স্টাফদের জন্য মোবাইল‑ফার্স্ট নকশা প্রয়োজন: বড় ট্যাপ টার্গেট, উচ্চ কন্ট্রাস্ট, এবং সুস্পষ্ট “Scan” / “Search attendee” সুইচ। দরজায় ধীর, সংকীর্ণ ইন্টারফেস লাইনে সমস্যা সৃষ্টি করে।

অ্যাকাউন্ট, রোল ও পারমিশন

টিকেটিং অ্যাপ দ্রুত একটি শেয়ার্ড ওয়ার্কস্পেসে পরিণত হয়: অর্গানাইজার ইভেন্ট তৈরি করে, ফাইন্যান্স টিম রিফান্ড হ্যান্ডেল করে, ডোর স্টাফ শুধু স্ক্যান করে—সুতরাং পরিষ্কার অ্যাকাউন্ট ও পারমিশন অভিজ্ঞতা মসৃণ রাখে এবং ব্যয়বহুল ভুল কমায়।

Authentication—নিরাপদ ও সহজ

অর্গানাইজার ও স্টাফ লগিন ইমেইল + পাসওয়ার্ড সমর্থন করুন, এবং ঐচ্ছিক MFA দিন যদি প্রয়োজন হয়।

পাসওয়ার্ড রিসেট‑এ ইমেইলে পাসওয়ার্ড পাঠাবেন না। টাইম‑লিমিটেড ওয়ান‑টাইম রিসেট লিংক (উদাহরণ: 15–60 মিনিট), শুধুমাত্র হ্যাশড পাসওয়ার্ড স্টোর করুন, এবং রিসেট টোকেন ব্যবহারের পর অবৈধ করে দিন। লগইন ও রিসেট রেট‑লিমিট এবং একই উত্তর মেসেজ রাখুন যাতে এটাকাররা ইমেইল অস্তিত্ব অনুমান করতে না পারে।

Role-based access control (RBAC)

রোলগুলো নির্ধারণ করে তারপর ইভেন্ট লেভেলে প্রয়োগ করুন। অনেক টিম একাধিক ইভেন্ট চালায়, একজনের জন্য একটি ইভেন্ট‑এ তিনি ‘finance’ হতে পারেন কিন্তু অন্যটিতে ‘viewer’।

সাধারন পারমিশন বালতি:

• View: রিড‑অনলি অ্যাক্সেস
• Edit: ইভেন্ট ডিটেইল, টিকেট টাইপ, কম্প টিকেট, এবং অ্যাটেন্ডি এডিট
• Finance: রিফান্ড, পেআউট, ট্যাক্স সেটিংস এবং পেমেন্ট‑রিলেটেড এক্সপোর্ট

পারমিশন স্পষ্ট রাখুন (উদাহরণ: order.refund, attendee.update)—ভাগাভাগি ‘admin’ লজিকে ভরসা করবেন না।

চেক‑ইন স্টাফ (মোবাইল‑ফ্রেন্ডলি, সীমিত অ্যাক্সেস)

একটি ডেডিকেটেড Check-in রোল তৈরি করুন যা করতে পারবে:

• QR কোড স্ক্যান
• নাম/ইমেইল দিয়ে অ্যাটেন্ডি সার্চ
• উপস্থিতি চিহ্ন করা এবং নিয়মকৃত আনডু করা

কিন্তু রাজস্ব দেখা, রিফান্ড ইস্যু করা বা টিকেট দাম বদলানো দেখতে পারবে না। এতে অস্থায়ী স্টাফকে ফোন হস্তান্তর করা নিরাপদ হয়।

সংবেদনশীল অ্যাকশনের জন্য অডিট লগ

রিফান্ড, কম্প টিকেট, অ্যাটেন্ডি ডিটেইল বদল বা অ্যাটেন্ডি তালিকা এক্সপোর্টের মতো কাজের জন্য কে, কখন, কী করেছে তা রেকর্ড করুন। ইভেন্ট ID, অ্যাক্টর অ্যাকাউন্ট, টাইমস্ট্যাম্প, এবং আগে/পরে মান অন্তর্ভুক্ত করুন। অডিট লগ বিরোধ ও সাপোর্টকে সহজ করে তোলে।

পেমেন্ট, টিকেট ইস্যু এবং QR কোড

পেমেন্ট হল যেখানে আপনার অ্যাপ ‘রিয়েল’ হয়: টাকা চলে, প্রত্যাশা বাড়ে, এবং ভুল দামি হয়ে যায়। চেকআউট ও টিকেট ইস্যুকেই একটি কড়াকড়ি কাজ হিসেবে দেখুন—স্পষ্ট স্টেট ও অডিট ট্রেইল সহ।

পেমেন্ট প্রোভাইডার বেছে নিন (এবং কার্ড ডেটা স্টোর করবেন না)

ওয়েবহুক ও রিফান্ড সাপোর্ট করে এমন প্রোভাইডার ব্যবহার করুন (Stripe, Adyen, PayPal)। আপনার ডাটাবেস কখনো র‑কার্ড নম্বর বা CVV স্টোর করবে না। পরিবর্তে শুধুমাত্র প্রোভাইডার‑জেনারেটেড রেফারেন্স রাখুন যেমন:

• payment_intent_id / charge_id
• customer_id (ঐচ্ছিক)
• receipt_url (ঐচ্ছিক)

এতে সিস্টেম সরল থাকে এবং কমপ্লায়েন্স এক্সপোজার কমে।

চেকআউটকে স্টেট মেশিন হিসেবে মডেল করুন

অর্ডার/পেমেন্ট স্টেট আগে থেকেই সংজ্ঞায়িত করুন যাতে সাপোর্ট, রিপোর্টিং ও ইমেইল সঙ্গত থাকে। সাধারণ স্টেট:

• pending (অর্ডার তৈরি, পেমেন্ট নিশ্চিত হওয়ার অপেক্ষা)
• paid (প্রোভাইডার পেমেন্ট কনফার্ম করে; টিকেট ইস্যু করা যাবে)
• failed (পেমেন্ট চেষ্টা প্রত্যাখ্যাত)
• expired (চেকআউট সেশন টাইমআউট)
• refunded এবং partially_refunded (রিফান্ড পরিমাণ ও কারণ ট্র্যাক করুন)

প্রোভাইডার ওয়েবহুককে paid ও refunded‑এ ট্রানজিশন করার সোর্স রাখুন এবং একটি অপরিবর্তনীয় ইভেন্ট লগ (সিম্পল order_events টেবিল) রাখুন ট্রেসেবিলিটির জন্য।

টিকেট ইস্যু: ইউনিক কোড + QR কোড

শুধুমাত্র যখন অর্ডার paid হয় (বা অর্গানাইজার স্পষ্টভাবে comp ইস্যু করলে) টিকেট জেনারেট করুন। একটি ইউনিক টিকেট কোড তৈরি করে এটিকে QR‑তে এনকোড করুন।

প্র্যাকটিক্যাল নিয়ম: QR লোডে নিজে অর্থহীন (উদাহরণ: র্যান্ডম টোকেন বা সাইনড স্ট্রিং) রাখুন, এবং সার্ভার যাচাই করেই প্রবেশ অনুমোদন করুন।

ডিসকাউন্ট, ফ্রি টিকেট ও কম্প

ডিসকাউন্ট কোড কড়াকড়ি নিয়মে বাস্তবায়ন করুন: ভ্যালিডিটি উইন্ডো, ইউসেজ লিমিট, অর্গানিক টিকেট টাইপ, এবং স্ট্যাকিং কিনা। ফ্রি টিকেট/কম্প হলেও একটি অর্ডার রেকর্ড তৈরি করুন (total = 0) যাতে রিপোর্টিং ও অ্যাটেন্ডি ইতিহাস সঠিক থাকে।

রিসিট ও কনফার্মেশন এক সোর্স

রিসিট ও কনফার্মেশন ইমেইল পাঠান সবসময় order record‑এর উপর ভিত্তি করে—UI‑র “success” স্ক্রিনের উপর নয়। পেমেন্ট কনফার্মেশনের পরে সিস্টেম টিকেট জেনারেট করবে, সেভ করবে, তারপর ইমেইল পাঠাবে যার মধ্যে টিকেট ভিউ লিংক থাকবে (উদাহরণ: /orders/{id}) ও QR কোড।

ইমেইল নোটিফিকেশন ও কমিউনিকেশন

ইমেইল হলো আপনার রেজিস্ট্রেশন সিস্টেমের কঙ্কাল: এটি ক্রেতাকে নিশ্চিত করে, টিকেট ডেলিভার করে, এবং সাপোর্ট রিকোয়েস্ট কমায়। এটাকে প্রোডাক্ট ফিচার হিসেবে বিবেচনা করুন, না যে পরে যোগ করা হবে।

অপরিহার্য টেমপ্লেট (এবং কি থাকা আবশ্যক)

চTransactionাল টেমপ্লেটের ছোট সেট দিয়ে শুরু করুন:

• Order confirmation: ইভেন্ট নাম, তারিখ/সময়, ভেনিউ (বা “online”), অর্ডার সারাংশ, পেমেন্ট স্ট্যাটাস, এবং স্পষ্ট “View order” লিংক।
• Ticket delivery: প্রতিটি টিকেট/অ্যাটেন্ডির নাম, টিকেট টাইপ, QR কোড (বা সিকিউর চেক‑ইন লিংক), এবং মৌলিক চেক‑ইন নির্দেশনা।
• Reminders: গুরুত্বপূর্ণ লজিস্টিকস (দরজা কখন খোলা হবে, পার্কিং/এন্ট্রি নীতি), এবং টিকেট আবার দেখার সহজ উপায়।
• Refund/cancellation notice: রিফান্ডকৃত আইটেম, পরিমাণ, টাইমলাইন, এবং কাদের সাথে যোগাযোগ করবেন।

সাবজেক্ট লাইন নির্দিষ্ট রাখুন (“Your tickets for {EventName}”) এবং বেশি মার্কেটিং ভাষা থেকে বিরত থাকুন—ডেলিভারিবিলিটি ঝুঁকি কমে।

অর্গানাইজার ব্র্যান্ডিং কিন্তু ডেলিভারিবিলিটির যত্ন নিন

অর্গানাইজারদের লোগো, অ্যাকসেন্ট রঙ এবং শর্ট ফুটার দেওয়ার অনুমতি দিন—একই সময়ে একটি নির্দিষ্ট HTML স্ট্রাকচার রাখুন। “ব্র্যান্ড স্লট” ব্যবহার করুন পুরো কাস্টম HTML‑এর বদলে; এতে ভাঙা রেন্ডারিং ও স্প্যাম সিগন্যাল কমে।

প্রেরকের ঠিকানা স্থিতিশীল রাখুন যেমন [email protected] এবং “Reply‑To” হিসেবে অর্গানাইজার দিন (বা_verified sender identity)। এতে প্রাপককে পরিচিত প্রেরক মিলে এবং কথোপকথনও সম্ভব হয়।

ট্র্যাকিং এবং সাপোর্ট‑সাহায্যকারী টুল

সর্বনিম্নভাবে প্রতিটি মেসেজ‑এর স্ট্যাটাস রাখুন: queued, sent, delivered (যদি প্রোভাইডার রিপোর্ট করে), bounced, complaint। এটা অর্গানাইজার‑ফেসিং টাইমলাইন চালাতে সহায়তা করে এবং টিমকে সমস্যা ডায়াগনোজ করতে দেয়।

অর্গানাইজার ড্যাশবোর্ডে দুটি সেলফ‑সার্ভ অ্যাকশন রাখুন:

1. Resend tickets (রেট‑লিমিট ও অডিট লগ সহ)
2. Update attendee email এবং পুনরায় ডেলিভারি—মূল পেমেন্ট/অর্ডার রেকর্ড বদল না করে

ঐচ্ছিক SMS (অনুমতি‑ভিত্তিক)

শুধুমাত্র স্পষ্ট প্রয়োজনে SMS যুক্ত করুন (উদাহরণ: শেষ‑মুহূর্ত ভেনিউ চেঞ্জ)। এটি অবশ্যই opt‑in হবে, প্রতি অ্যাটেন্ডির সম্মতি সংগ্রহ করুন, এবং মেসেজ শুধুমাত্র তথ্যবহুল রাখুন ও সহজ opt‑out নির্দেশ দিন।

অন‑সাইট চেক‑ইন ও অ্যাটেন্ডি লুকআপ

অন‑সাইট চেক‑ইন ফ্লো এপসায় সেকেন্ডে মূল্যায়িত হয়। স্টাফদের এমন স্ক্রিন চাই যা দ্রুত লোড হয়, ভিড়‑ভাড়া এলাকায় কাজ করে, এবং একটাই প্রশ্নের উত্তর দেয়: “এই ব্যক্তি প্রবেশের যোগ্য কি?”

দ্রুত চেক‑ইন স্ক্রিন

একটি ডেডিকেটেড “Check-In” ভিউ ডিজাইন করুন (অর্গানাইজার ড্যাশবোর্ড থেকে আলাদা)। গতি এবং বড় টাচ টার্গেটকে অগ্রাধিকার দিন।

দুইটি ইনপুট মোড রাখুন:

• Search নাম, ইমেইল, অর্ডার নম্বর, বা টিকেট কোড দিয়ে—টাইপ করার সময় রেজাল্ট দেখান
• Scan QR ডিভাইস ক্যামেরা ব্যবহার করে, সরাসরি টিকেট/অ্যাটেন্ডি রেকর্ড রেজল্ভ করে

অফলাইন‑ফ্রেন্ডলি অপারেশনের জন্য নির্দিষ্ট ইভেন্টের অ্যাটেন্ডি তালিকা ডিভাইসে ক্যাশ করুন (এবং শুধু এন্ট্রি‑র জন্য প্রয়োজনীয় ডাটা)। কানেকটিভিটি বন্ধ হলে লোকালি ভ্যালিডেট করে এবং পরে সিঙ্ক‑আপডেট কিউ করবে।

ডাবল এন্ট্রি প্রতিরোধ (নিয়ন্ত্রিত ওভাররাইডসহ)

প্রতিটি টিকেটের স্পষ্ট স্টেট থাকবে: Not checked in → Checked in। ইতিমধ্যে ব্যবহার হওয়া টিকেট স্ক্যান করলে শক্ততর সতর্কবার্তা দেখান—টাইমস্ট্যাম্প ও স্টাফ ম্যান থাকলে দেখান।

ওভাররাইড শুধুমাত্র স্পষ্ট পারমিশন থাকা ব্যবহারকারীদের জন্য অনুমোদিত রাখুন (যেমন “Check-in manager”)। ওভাররাইড করার সময় একটি কারণ নোট বাধ্যতামূলক রাখুন যাতে পরে বিরোধ সমাধান করা যায়।

গ্রুপ অর্ডার ও একাধিক টিকেট টাইপের আংশিক চেক‑ইন

একাধিক টিকেট থাকা অর্ডারের জন্য এক‑এক করে টিকেট চেক‑ইন সমর্থন করুন। UI‑তে বাকি টিকেট এবং টিকেট টাইপ দেখান (উদাহরণ: “2 of 4 General Admission left”)। এতে গ্রুপ আলাদা আলাদা পৌঁছালে সবগুলো একসঙ্গে চেক‑ইন করতে বাধ্য করা হবে না।

সহায়ক প্রসঙ্গ দেখান

স্ক্যান/সার্চের সময় প্রদর্শন করুন:

• টিকেট টাইপ ও অ্যাক্সেস লেভেল (VIP, workshop add-on)
• অ্যাটেন্ডি নোট (ডায়েটারি, বিশেষ নির্দেশ)
• অ্যাক্সেসিবিলিটি চাহিদা (সংগ্রহ করলে, সীমিত রেখে দেখান)

প্রতিটি চেক‑ইন লগ করুন

চেক‑ইন ইভেন্ট লগ (স্ক্যান/সার্চ, ডিভাইস/ব্যবহারকারী, সময়, ফলাফল, ওভাররাইড কারণে) রেকর্ড করুন। এই লগ পোস্ট‑ইভেন্ট রিপোর্টিং ও বিরোধে অডিট ট্রেইল হিসেবে কাজ করে।

রিপোর্টিং, এক্সপোর্ট ও অ্যাডমিন টুল

ভাল রিপোর্টিং আপনার অ্যাপকে ‘টিকেট বিক্রির জায়গা’ থেকে এমন একটি টুলে পরিণত করে যা অর্গানাইজার পরিকল্পনা, ইভেন্ট‑দিন এবং পোস্ট‑ইভেন্ট র‍্যাপ‑আপে নির্ভর করে।

অর্গানাইজার যে রিপোর্টগুলো চাইবে

একটি ছোট সেট উচ্চ‑নির্ভরযোগ্য রিপোর্টে শুরু করুন:

• Sales by ticket type: ইউনিট বিক্রি, বাকি (যদি ক্যাপড), এবং গ্রস বনাম নেট
• Revenue breakdown: subtotal, discounts, fees, taxes, এবং পেআউট টোটাল
• Order status: paid, pending, canceled, refunded, chargeback
• Attendance rate: চেক‑ইন করা উপস্থিতি বনাম মোট ইস্যুকৃত টিকেট, টিকেট টাইপ অনুযায়ী বিভক্ত

সংখ্যাগুলো অর্ডার রিসিপ্ট ও পেআউট সামারির সঙ্গে সঙ্গতিপূর্ণ রাখুন যাতে সাপোর্ট টিকিট না বাড়ে।

ফিল্টার ও এক্সপোর্ট যা কাজে লাগে

কিছু স্ট্যান্ডার্ড ফিল্টার রিপোর্টকে মূল্যবান করে:

• তারিখ রেঞ্জ (অর্ডার তৈরি, পেমেন্ট তারিখ, বা চেক‑ইন টাইম)
• টিকেট টাইপ
• অর্ডার/অ্যাটেন্ডি স্ট্যাটাস (paid/refunded, checked-in/not)

এক্সপোর্ট CSV (এবং ঐচ্ছিক XLSX) দিন। প্রতিটি এক্সপোর্টে স্পষ্টভাবে বলুন কি আছে: order ID, buyer info, attendee info, ticket type, price, taxes/fees, discount codes, এবং check-in timestamps।

এছাড়া স্পষ্ট করুন এক্সপোর্টে PII (ইমেইল/ফোন) আছে কি না এবং শেয়ারিং‑এর জন্য একটি “minimal” এক্সপোর্ট অপশন দিন।

ফানেল মেট্রিক (হালকা, উচ্চ প্রভাব)

প্রতি ইভেন্ট একটি সহজ ফানেল ট্র্যাক করুন: event page views → checkout started → payment completed। এমন বেসিক কাউন্ট অর্গানাইজারকে সমস্যা ধরতে সাহায্য করে (উদাহরণ: অনেক চেকআউট শুরু কিন্তু কম পেইড অর্ডার) এবং প্রচারণা কার্যকারিতা যাচাই করতে দেয়।

সাপোর্ট ও অপারেশনসের জন্য অ্যাডমিন টুল

ইন্টারনাল অ্যাডমিন প্যানেলটি গতিশীল রাখুন:

• অর্ডার ID, buyer email, attendee name, বা শেষ 4 ডিজিট দিয়ে সার্চ
• পূর্ণ অর্ডার টাইমলাইন দেখুন (created, paid, emails sent, refunds)
• Resend confirmation email এবং reissue tickets
• পেমেন্ট প্রোভাইডার থেকে রিফান্ড শুরু করুন এবং আউটকাম রেকর্ড করুন

ডাটা রিটেনশন ও এক্সপোর্ট পলিসি

কতদিন অর্ডার, অ্যাটেন্ডি রেকর্ড, এবং লগ রাখবেন তা ডকুমেন্ট করুন, এবং রিটেনশন এক্সপায়ার হওয়ার পরে কি হয় তা দেখান। হেল্প ডকস‑এ (উদাহরণ: /help/data-retention) এবং এক্সপোর্ট ডায়ালগে এটি দেখা যাক যাতে অর্গানাইজাররা জানেন তারা কী ডাউনলোড করছে ও সংরক্ষণ করছে।

সিকিউরিটি, প্রাইভেসি ও নির্ভরযোগ্যতার বুনিয়াদি

সিকিউরিটি ও নির্ভরযোগ্যতা টিকেটিং অ্যাপের জন্য ‘বরোক’ বিষয় নয়। আপনি নাম, ইমেইল এবং অনেক সময় পেমেন্ট‑রিলেটেড মেটাডেটা সংরক্ষণ করবেন—কয়েকটি মৌলিক সিদ্ধান্ত আগেভাগে নেওয়া হলে পরে ব্যাপক রাইটরাইটিং এড়িয়ে যাওয়া যাবে।

অ্যাটেন্ডি ডাটা সুরক্ষা (least privilege + encryption)

লিস্ট‑প্রিভিলেজ অ্যাক্সেস দিয়ে শুরু করুন: অর্গানাইজার শুধু তাদের ইভেন্ট দেখুক, স্টাফ শুধু চেক‑ইনের জন্য প্রয়োজনীয় তথ্য দেখুক, এবং অ্যাডমিন সীমিত থাকুক। ব্যাকএন্ডে RBAC ব্যবহার করুন (শুধু UI‑হিডিং নয়)।

ট্রানজিটে সবকিছু HTTPS দিয়ে এনক্রিপ্ট করুন, ওয়েবহুক এবং অভ্যন্তরীণ সার্ভিসও। সিক্রেট (API কী, ওয়েবহুক সাইনিং সিক্রেট, DB ক্রেড) ম্যানেজড সিক্রেট স্টোরে রাখুন—রিপো বা ফ্রন্টএন্ডে নয়।

ইনপুট ভ্যালিডেশন ও সাধারণ আক্রমণ ব্লক করা

প্রতিটি ফিল্ড অবিশ্বস্ত হিসেবে বিবেচনা করুন: ইভেন্ট ডিসক্রিপশন, অ্যাটেন্ডি নাম, কাস্টম প্রশ্ন, কুপন কোড।

• ইনজেকশন রোধ করতে প্যারামিটারাইজড কুয়েরি/ORM নিরাপত্তা ব্যবহার করুন।
• XSS রোধ করতে ইউজার‑জেনারেটেড কনটেন্ট এস্কেপ করুন এবং Content Security Policy প্রয়োগ করুন।
• স্টেট‑চেঞ্জিং রিকোয়েস্টে CSRF রোধ করুন (বিশেষ করে যদি কুকি ব্যবহার করেন)
• লগইন, পাসওয়ার্ড রিসেট, এবং “resend ticket email”‑এ রেট‑লিমিট চালান।

প্রাইভেসির মৌলিক ব্যাখ্যা

শুধুমাত্র প্রয়োজনীয় তথ্য সংগ্রহ করুন (উদাহরণ: টিকেটের জন্য নাম ও ইমেইল) এবং ঐচ্ছিক ফিল্ড স্পষ্টভাবে ‹ঐচ্ছিক› লেবেল দিন। ট্রান্স‌্যাকশনাল ইমেইল (রিসিপ্ট, টিকেট, শিডিউল পরিবর্তন) ও মার্কেটিং ইমেইল আলাদা রাখুন।

মার্কেটিং opt‑in রাখলে স্পষ্ট সম্মতি স্টোর করুন এবং সহজ আনসাবস্ক্রাইব লিংক দিন।

ব্যাকআপ ও রিকভারি—প্রকৃতভাবে টেস্ট করা

ব্যাকআপস তখনই বাস্তব যখন রিস্টোরও কাজ করে। ডাটাবেস ব্যাকআপ অটোমেট করুন, বিভিন্ন রিটেনশন উইন্ডো রাখুন, এবং রিস্টোর টেস্টগুলো স্টেজিং‑এ শিডিউল করুন।

একটি সরল রিকভারি চেকলিস্ট লিখে রাখুন: কে রিস্টোর করে, কোথায় রিস্টোর করে, এবং কিভাবে টিকেট স্ক্যানিং কাজ করে যাচাই করা হবে।

মনিটরিং যা সমস্যা আগে ধরে

ব্যাকএন্ড ও ফ্রন্টএন্ডে এরর ট্র্যাকিং, কিচেড এন্ডপয়েন্টের আপটাইম চেক (checkout, webhook handler, check-in API), এবং স্লো কুয়েরির জন্য অ্যালার্ট সেট করুন। কম শব্দযুক্ত, কার্যকরী অ্যালার্টস একটি গোলমালপূর্ণ ড্যাশবোর্ডের চেয়ে ভালো।

টেস্টিং, লঞ্চ ও ইটারেশন প্ল্যান

টেস্টিং ও লঞ্চই সেই পর্যায় যেখানে টিকেটিং অ্যাপ বিশ্বাস অর্জন করে। চেকআউট বা QR ভ্যালিডেশনে ছোট বাগ কেবল ব্যবহারকারীকে বিরক্ত করবে না—এটা দরজায় প্রবেশ বাধাগ্রস্ত করতে পারে। এই পর্যায়টাকে প্রোডাক্টের অংশ হিসেবে দেখুন, না যে শেষ বাধা।

ক্রিটিক্যাল পাথের জন্য অটোমেটেড টেস্ট

এগুলোতে ফোকাস করুন যেগুলো সরাসরি টাকা বা প্রবেশকে প্রভাবিত করে:

• Checkout: সফল পেমেন্ট, বাতিল পেমেন্ট, ব্যর্থ পেমেন্ট, প্রোমো কোড এজ‑কেস
• Ticket issuance: প্রতিটি ক্রয়ের সময় টিকেট তৈরি হয়, সঠিক টাইপ, ইমেইল পাঠানো, PDF/PKPass লিংক (যদি থাকে) বৈধ
• Check-in: QR স্ক্যান বৈধ টিকেট গ্রহণ করে, ইতিমধ্যে‑ব্যবহৃত টিকেট প্রত্যাখ্যান করে, অফলাইন/ল্যাটেন্সি gracefully হ্যান্ডেল করে
• Refunds/voids: স্টেট আপডেট, টিকেট ইনভ্যালিডেশন, ইমেইল, অডিট লগ

পেমেন্ট প্রোভাইডার ওয়েবহুক নিয়ে কিছু “কন্ট্রাক্ট টেস্ট” রাখুন যাতে পে‑লোড পরিবর্তন মশগুলভাবে ব্রেক না করে।

পাবলিক লঞ্চের আগে স্টেজিং পাইলট

একটি ছোট ইভেন্ট (এমনকি ইনটারনাল মিটআপ) দিয়ে পাইলট চালান। অর্গানাইজার ও ডোর স্টাফকে স্টেজিং অ্যাপ দিন বাস্তব রিহার্সালের জন্য: ইভেন্ট তৈরি, কয়েকটি টিকেট বিক্রি, লোকজন চেক‑ইন, রিফান্ড ইস্যু, টিকেট রিসেন্ড।

একটি সরল ফিডব্যাক ফর্মে ফিডব্যাক সংগ্রহ করুন এবং যেখানে স্টাফ hésitate করছে সেগুলো ইউআই‑ফিক্স হিসেবে অগ্রাধিকার দিন।

লঞ্চ চেকলিস্ট ও অপারেশনাল রেডিনেস

লাইভ করার আগে নিশ্চিত করুন:

• ডোমেইন + SSL, রিডাইরেক্ট নিয়ম, এরর পেজ
• ইমেইল সেন্ডার সেটআপ (SPF/DKIM/DMARC) এবং ডেলিভারিবিলিটি চেক
• লাইভ পেমেন্ট কী ও ওয়েবহুক এন্ডপয়েন্ট
• লগিং, অ্যালার্ট, এবং ফেইলড জব (ইমেইল সেন্ড, টিকেট জেনারেশন) ইনস্পেকশনের উপায়

সাপোর্ট ও ইটারেশন

সামান্য বাগে canned response এবং অভ্যন্তরীণ ধাপগুলো প্রস্তুত রাখুন (বিরোধ, রিফান্ড, টিকেট রিসেন্ড)।

লঞ্চের পরে ছোট ব্যাচে ইটারেট করুন—waitlists, seating, ইন্টিগ্রেশন (CRM/ইমেইল), এবং মাল্টি‑ইভেন্ট অ্যাকাউন্ট—রিয়েল সাপোর্ট টিকিট ও অর্গানাইজার ফিডব্য্যাকের ভিত্তিতে।