دراسة حالة · Hart College
كيف استبدلت UnlockLive ثلاث أدوات منفصلة وصندوق بريد مشتركاً واحداً بنظام معلومات طلابي مخصص وموحّد لكلية مهنية كندية — كتالوج دورات عام بـ Next.js، وبوابة للطلاب للتسجيل ودفع الرسوم الدراسية عبر Stripe، ولوحة إدارة بـ Django للدفعات والدورات والقسائم والمرشحين والمرفقات. النتيجة: تحصيل 100% من الرسوم الدراسية إلكترونياً، وتسجيل أسرع 5 مرات، وبلا جداول بيانات للمطابقة.
“Their work is satisfactory on all counts.”كانت Hart College تدير القبول عبر موقع تسويقي عام، وتسجيل الدورات في جدول بيانات منفصل، وتحصيل الرسوم الدراسية بالشيكات والتحويل الإلكتروني، والتواصل مع الطلاب عبر صندوق بريد مشترك. لم يكن شيء منها متطابقاً. كان المسؤولون يعيدون إدخال كل طالب جديد في ثلاثة أماكن، ولم يكن لدى أمين السجل إجابة موحدة عن سؤال «من المسجّل في هذه الدفعة؟»، وكانت الإدارة المالية تقضي أسبوعاً كاملاً كل شهر في ملاحقة المدفوعات المفقودة ومطابقتها مع أسماء لا تتطابق تماماً بين الأنظمة.
كان المطلوب بسيطاً في ظاهره: استبدال كل ذلك بنظام معلومات طلابي (SIS) واحد يستطيع فيه المرشح اكتشاف دورة من صفحة تسويقية عامة، والتسجيل في دفعة محددة، ودفع الرسوم الدراسية إلكترونياً، ورؤية جدوله وسجل مدفوعاته في بوابة ذاتية الخدمة — ويستطيع المسؤول إنشاء الدفعات والدورات والقسائم والمرشحين والمرفقات من لوحة واحدة دون جداول بيانات موازية ودون أعمال مطابقة في نهاية الشهر.
بنينا نظام SIS واحداً مخصصاً عبر ثلاث واجهات منسقة: كتالوج دورات عام بـ Next.js، وبوابة للطلاب للتسجيل والرسوم الدراسية، ولوحة إدارة بـ Django + Django REST Framework — وكلها مدعومة بـ PostgreSQL وتكامل Stripe Payments + Webhooks الذي يُبقي نظام SIS مصدراً وحيداً للحقيقة لكل دولار.
يقدم الموقع العام كتالوج Next.js سريعاً ومحسّناً لـ SEO: لكل دورة صفحة تفاصيل قابلة للفهرسة وجدول الدفعة والمتطلبات المسبقة وتفصيل الرسوم الدراسية ودعوة مضمّنة «سجّل الآن» — فيصبح الموقع التسويقي أيضاً أعلى مسار التسجيل لا كتيباً منفصلاً. وبمجرد نقر المرشح، يصل إلى جلسة Stripe Checkout تُنشأ على الخادم بالمبلغ والعملة والقسيمة ومعرّف الدفعة الصحيحة مضمّنة في البيانات الوصفية.
عند نجاح الدفع، يصل webhook من Stripe إلى واجهة Django API ويُنشئ الطالب أو يحدّثه بشكل غير مكرر الأثر، ويربطه بالدفعة المختارة، ويرفق الإيصال، ويرسل رسالة تأكيد بالبريد — كل ذلك في معاملة موقّعة واحدة. ثم تعرض بوابة الطالب «دوراتي» و«جدولي» و«رسومي الدراسية» (مع سجل المدفوعات والمبالغ المستردة كاملاً) وتبويباً للمستندات الخاصة بالكشوف الدراسية والهوية والاتفاقيات الموقّعة.
توفر لوحة إدارة Django لأمين السجل مكاناً واحداً لإدارة البرنامج بالكامل: إنشاء دفعة، وربط الدورات وأعضاء هيئة التدريس بها، وتحديد رموز القسائم (نسبة مئوية أو مبلغ ثابت، بنطاق لكل دفعة أو لكل دورة)، ورفع سجلات المرشحين والمرفقات، ونشر الإعلانات، واستخراج تقارير التسجيل والإيرادات دون فتح Excel. وتفصل الأدوار بين أمين السجل والإدارة المالية وهيئة التدريس والمسؤول بحيث لا يرى كل مستخدم إلا الواجهة التي يحتاجها.
وأخيراً، ربطنا webhooks الخاصة بـ Stripe بشكل غير مكرر الأثر، وقفلنا سجلات الرسوم الدراسية بمجموع اختباري (checksum) ليتمكن القسم المالي من إثبات تطابق SIS مع Stripe، وزودنا كل نقطة نهاية بـ Sentry + CloudWatch، وخزّنا كل ملف PDF موقّع / هوية مرفوعة في S3 بروابط موقّعة محددة المدة (دون وصول مباشر إلى الكائنات).
جلسنا مع فريقي شؤون التسجيل والمالية لمدة أسبوع ورسمنا كل نقطة أُنشئ فيها سجل الطالب أو عُدِّل أو دُفع عنه — عبر موقع التسويق وجدول التسجيل والبنك وصندوق البريد والمجلد المشترك. ونتج عن ذلك نموذج بيانات يراعي القبول، بمفاهيم أساسية هي `Batch` و`Course` و`Coupon` و`Candidate` و`Tuition`، بدلًا من إلحاق حالة الطالب بنظام CRM عام.
سلّمنا كتالوجًا عامًا سريعًا بـ Next.js ومحسّنًا لـ SEO بصفحة قابلة للفهرسة لكل دورة، وأزرار «Enrol now» مضمنة تنقل إلى جلسة Stripe Checkout تُنشأ على الخادم وتتضمن بيانات القبول والقسائم. ثم تعرض بوابة الطلاب الجدول والمدفوعات السابقة والإيصالات ورفع المستندات. فالموقع التسويقي هو قمع التحويل لا مجرد كتيّب.
على جانب العمليات، سلّمنا لوحة إدارة مبنية على Django + Django REST Framework: إدارة الدفعات والمقررات والكوبونات والمرشحين والمرفقات (CRUD)، وفصل الأدوار بين شؤون التسجيل والمالية وأعضاء هيئة التدريس والمسؤولين، وواجهة تقارير للتسجيل والإيرادات. وتصل webhooks الخاصة بـ Stripe بطريقة idempotent إلى نقطة نهاية Django واحدة تنشئ الطالب أو تحدّثه، وتربطه بالدفعة الصحيحة، وتسجّل صف الرسوم الدراسية، وترسل رسالة التأكيد بالبريد الإلكتروني ضمن معاملة موقّعة واحدة.
ثبّتنا صفوف الرسوم الدراسية بمجموع اختباري (checksum) ليتمكن القسم المالي من إثبات تطابق نظام معلومات الطلاب مع Stripe في أي لحظة، وخزّنا كل ملف PDF موقّع وكل هوية مرفوعة في S3 بروابط موقّعة محدودة المدة، وزوّدنا كل نقطة نهاية بأدوات Sentry + CloudWatch. وحصل أمين السجل على دليل تشغيل لفتح دفعة قبول جديدة، وإصدار قسيمة، واسترداد دفعة رسوم دراسية، وتصدير تقرير التسجيل، وبقينا معه بعقد دعم مستمر لإجراء التحسينات.
ضمانتان. (1) معالج webhook هو idempotent: يُفحص كل `event.id` من Stripe مقابل جدول `processed_webhooks` قبل أي كتابة، فتصبح إعادة المحاولة بلا أثر. (2) يخزّن كل صف رسوم دراسية قيمة تحقق مشتقة من `(student_id, batch_id, amount, currency, coupon_code, stripe_payment_intent)`. يستطيع القسم المالي تشغيل استعلام مطابقة من سطر واحد في أي وقت لإثبات اتفاق صفوف SIS مع رسوم Stripe — بلا Excel ولا مطابقة يدوية ولا ذعر نهاية الشهر.
نتعامل مع `Batch` (الدفعة) ككيان أساسي مستقل، لا كوسم على الطالب. تحمل الدفعة تاريخ بدايتها وسعتها ومقرراتها وتكليفات هيئة التدريس. ينتمي الطالب إلى دفعة واحدة أو أكثر، ويمكن تحديد نطاق القسيمة لكل دفعة قبول أو لكل مقرر، وتُصفّى التقارير حسب الدفعة بنقرة واحدة. وهذا هو الفرق بين "نظام CRM فيه حقل للقبول" ونظام معلومات طلابية حقيقي، ولهذا لم يعد أمين السجل يحتفظ بجدول بيانات موازٍ.
نعم. نموذج البيانات مستقل عن المؤسسة — فـ `Batch` و`Course` و`Coupon` و`Candidate` و`Attachment` و`Tuition` ليست خاصة بـ Hart. يمكن إدخال مؤسسة ثانية بإعادة تغليف واجهة Next.js الأمامية وتهيئة حساب Stripe جديد؛ أما لوحة إدارة Django والمخطط الأساسي فقابلان لإعادة الاستخدام. وقد صمّمناه بحيث يكون التوسع إلى التعليم الأساسي والثانوي (K-12) والتدريب المهني وبرامج التعليم المستمر تغييرًا في الإعدادات وليس إعادة بناء.
خمسة أشهر من البداية إلى النهاية مع فريق من أربعة أشخاص (مدير منتج/PM واحد، ومهندسان Full-stack، ومصمم واحد). بشكل تقريبي: 3 أسابيع للاستكشاف ومرافقة موظفي القبول والتسجيل؛ و12 أسبوعًا لواجهة Django REST API + كتالوج Next.js العام + بوابة الطلاب + لوحة الإدارة؛ و3 أسابيع لتحصين webhooks الخاصة بـ Stripe وأعمال مرفقات S3 والمراقبة وتدريب موظفي التسجيل؛ وأسبوعان للقبول التجريبي قبل فتح باب القبول الحي التالي على نظام معلومات الطلاب (SIS) الجديد.
موقع عام ببوابات للطلاب والمسؤولين مبني على Next.js (React)، وواجهة API بـ Django + Django REST Framework، وPostgreSQL للبيانات المعاملاتية، وStripe Payments + Webhooks للرسوم الدراسية، وAWS S3 لمرفقات المستندات، وSentry + CloudWatch للمراقبة — وكلها في حاويات Docker ومنشورة عبر البنية التحتية ككود.
التعليم80% انخفاض في العبء الإداري للدعم التعليميكيف بنت UnlockLive منصة آلية بالكامل لتسجيل المحاضرات تتكامل مع Canvas LMS وPanopto باستخدام Python وFastAPI — بنشر نحو 3,000 محاضرة تلقائياً في كل فصل، وخفض العبء الإداري بنسبة 80%، ومنح كل تسجيل مسار تدقيق قابلاً للتحقق.
التعليم50K+ استدعاءات Canvas API اليومية — ضمن حصة الجامعة بارتياحكيف استبدلت UnlockLive مزامنة ليلية هشة مع Canvas LMS بتكامل قائم على الأحداث بـ Python وFastAPI يعالج أكثر من 50 ألف استدعاء API يومياً، دون أي حوادث تجاوز لحدود المعدل، ونافذة مزامنة أصغر بنسبة 90% — دون تعطيل أي نظام لاحق.
الرعاية الصحية / SaaS لرعاية كبار السن70% انخفاض في متوسط وقت إعداد الملاحظات السريرية (18+ دقيقة → أقل من 5)كيف استبدلت UnlockLive خليطاً من جداول البيانات والملاحظات الورقية وأدوات السجلات الطبية الإلكترونية المتفرقة في 5 مرافق لرعاية كبار السن بمنصة واحدة متعددة المستأجرين متوافقة مع HIPAA مبنية على Next.js + Django + PostgreSQL على AWS — مع خفض زمن تدوين الملاحظات السريرية بنسبة 70%، وتسريع الاستقبال ثلاث مرات، ومنح المشغّل مصدراً واحداً للحقيقة جاهزاً للتدقيق منذ اليوم الأول.
تحدّث إلى الفريق نفسه الذي بنى نظام معلومات الطلاب (SIS) مخصص لكلية مهنية كندية — كتالوج المقررات، والتسجيل متعدد الدفعات، ورسوم Stripe الدراسية، وإدارة قائمة على القسائم (Next.js + Django + PostgreSQL). سنحدد نطاق مشروعك، ونقدّم لك عرضًا بسعر ثابت، ونُريك أقرب مثال من أعمالنا.
احجز مكالمة استراتيجيةUnlockLive IT Limited — المقر الرئيسي في Toronto المواجه للعملاء وإدارة المشاريع؛ ومركز هندسي مخصص في Dhaka، Bangladesh. شركة مسجلة في المملكة المتحدة برقم #15563368 (UnlockLive IT Limited، لندن).
حقوق النشر© UnlockLive . جميع الحقوق محفوظة 2008 - 2026