چطور یک ابزار داخلی بسازیم: پنل مدیریت، تأییدها و جایگزینی صفحه‌گسترده

برای ساخت یک ابزار داخلی، یک گردش کار را انتخاب کنید که الان دردسرساز است — معمولاً یک صفحه‌گسترده مشترک، یک رشته ایمیل یا یک کانال چت که کار پایگاه داده را انجام می‌دهد — و آن را به یک اپ کوچک با فرم مناسب، فهرستی با وضعیت، دسترسی درست برای هر نقش و تاریخچه‌ای از اینکه چه کسی چه چیزی را تغییر داده تبدیل کنید. یک ابزار ساخت اپ با AI می‌تواند در یک بعدازظهر نسخه اولیه کاری تولید کند. آنچه موفقیت را رقم می‌زند این است که دامنه را در یک گردش کار نگه دارید و آن را با افرادی بسازید که هر روز از آن استفاده می‌کنند.

چه چیزی ابزار داخلی محسوب می‌شود

ابزارهای داخلی همان نرم‌افزارهای بی‌زرق و برقی هستند که کسب‌وکار را می‌چرخانند. انواع رایج:

برای نقطه‌های شروع بیشتر، ایده‌های ابزار داخلی برای تیم‌ها را ببینید.

اصلاً باید آن را بسازید؟

اگر یک نفر آن را نگه می‌دارد، داده کم است و یک خطا هزینه کمی دارد، صفحه‌گسترده را نگه دارید. وقتی این نشانه‌ها را می‌بینید ابزار بسازید:

• افراد تغییرات یکدیگر را بازنویسی می‌کنند، یا کسی نمی‌داند کدام نسخه فعلی است
• برخی افراد باید فقط بخشی از داده را ببینند یا ویرایش کنند
• یک صفحه دستورالعمل برای استفاده از صفحه نوشته‌اید
• تغییر وضعیت باید به کسی اعلان دهد و مدام جا می‌ماند
• به ردپای ممیزی نیاز دارید — چه کسی این را تأیید کرد و چه زمانی

یک گزینه میانی هم وجود دارد. پلتفرم‌های ابزار داخلی low-code (مثل Retool، رابط‌های Airtable، Softr و دیگران) بلوک‌های ساختمانی روی داده شما می‌گذارند. وقتی داده‌تان از قبل در یک پایگاه داده یا صفحه‌گسترده پشتیبانی‌شده است و صفحه‌های کشیدن‌و‌رها می‌خواهید، مناسب‌اند. اپ ساخته‌شده با AI وقتی گردش کار خاص است، می‌خواهید دقیقاً همان‌طور که تیمتان لازم دارد رفتار و ظاهر کند، یا می‌خواهید کد را مالک باشید، برای شما بهتر است. برای پرسش کلی‌تر، ساختن یا خریدن نرم‌افزار برای کسب‌وکار کوچک را ببینید.

پیش از صفحه‌ها، گردش کار را طراحی کنید

پیش از پرامپت، گردش کار را به‌صورت یک داستان کوتاه بنویسید. برای ابزار تأیید هزینه:

1. یک کارمند هزینه‌ای را ارسال می‌کند: مبلغ، دسته‌بندی، تاریخ، توضیح، عکس رسید.
2. مدیرش اعلان می‌گیرد و با یک نظر تأیید یا رد می‌کند.
3. هزینه‌هایی که از یک حد بیشتر باشند تأیید مالی هم لازم دارند.
4. مالی هزینه‌های تأییدشده را در یک دسته هفتگی به‌عنوان پرداخت‌شده علامت می‌زند.
5. هر کسی وضعیت هزینه‌های خودش را می‌بیند؛ مالی همه را می‌بیند.

از آن داستان این‌ها به دست می‌آید:

• داده: هزینه‌ها، کاربران، نقش‌ها، تأییدها (چه کسی، تصمیم، نظر، تاریخ)، پیوست‌ها.
• وضعیت‌ها: ارسال‌شده → تأیید مدیر → تأیید مالی → پرداخت‌شده، یا ردشده.
• نقش‌ها: کارمند، مدیر، مالی، مدیر سیستم.
• قواعد: حد آستانه مبلغ، اینکه چه کسی می‌تواند یک آیتم را به هر وضعیت ببرد.
• صفحه‌ها: فرم ارسال، «هزینه‌های من»، «در انتظار تأیید من»، جدول همه هزینه‌ها برای مالی، صفحه جزئیات با تاریخچه.

گردش کار را با این عبارات توصیف کنید تا AI بتواند از اولین بار چیز درست را بسازد.

دسترسی‌ها و تاریخچه

ابزارهای داخلی اغلب داده حساس دارند — حقوق، اطلاعات مشتری، پول. دو قاعده:

1. نقش‌ها را برای هر عمل روی سرور بررسی کنید. یک مدیر نباید بتواند با فراخوانی مستقیم endpoint تأیید، هزینه خودش را تأیید کند.
2. تاریخچه ثبت کنید. هر تغییر وضعیت و ویرایش را همراه با اینکه چه کسی و چه زمانی انجام داده ذخیره کنید. بیشتر بحث‌های «این را چه کسی تغییر داد؟» را حل می‌کند و وقتی مشکلی پیش می‌آید بسیار ارزشمند است.

تصمیم بگیرید افراد چطور وارد شوند. ورود با حساب‌های گوگل یا مایکروسافت شرکتتان برای تیم‌هایی که از قبل از آن‌ها استفاده می‌کنند راحت است؛ ایمیل و رمز عبور در همه‌جا کار می‌کند. در هر حال ثبت‌نام را محدود کنید تا فقط تیم شما بتواند وارد شود.

یک پرامپت اولیه که کار می‌کند

یک ابزار تأیید هزینه داخلی برای یک شرکت ۲۵ نفره بسازید. کارمندان هزینه‌ای با مبلغ، واحد پول، دسته‌بندی (سفر، غذا، نرم‌افزار، تجهیزات، سایر)، تاریخ، توضیح و آپلود عکس رسید ارسال می‌کنند. مدیرشان فهرست «در انتظار تأیید من» را می‌بیند و می‌تواند با نظر تأیید یا رد کند. هزینه‌های بالاتر از ۵۰۰ دلار علاوه بر این تأیید کسی با نقش مالی را لازم دارند. مالی جدولی از همه هزینه‌ها را با فیلتر بر اساس وضعیت، فرد و ماه می‌بیند و می‌تواند هزینه‌های تأییدشده را پرداخت‌شده علامت بزند. هر تغییر وضعیت همراه با چه کسی و چه زمانی ثبت و به‌صورت یک خط زمانی در صفحه هزینه نمایش داده شود. نقش‌ها: کارمند، مدیر، مالی، مدیر سیستم — برای هر عمل روی سرور بررسی شوند. همه‌چیز در یک پایگاه داده ذخیره شود و داده نمونه واقعی‌گونه بسازید. رابط ساده، فشرده و سریع باشد — این یک ابزار کار است، نه یک سایت بازاریابی.

مراحل ساخت

1. جدول اصلی و فرم برای رکورد اصلی، با داده نمونه واقعی‌گونه تا جستجو و فیلترها آشکارا کار کنند.
2. وضعیت‌ها و انتقال‌ها، از جمله اینکه چه کسی می‌تواند یک آیتم را به هر حالت ببرد.
3. نقش‌ها و ورود، محدود به تیم شما.
4. گزارش تاریخچه روی هر رکورد.
5. اعلان‌ها — ایمیل یا پیام چت وقتی چیزی به اقدام کسی نیاز دارد.
6. وارد کردن داده موجود از صفحه‌گسترده. تبدیل صفحه‌گسترده به اپ پاک‌سازی و وارد کردن را پوشش می‌دهد.
7. آزمایش با دو یا سه کاربر واقعی به مدت یک هفته پیش از فراگیر کردن برای همه.
8. خاموش کردن فرایند قدیمی در تاریخ مشخص. دو سیستم که کنار هم اجرا شوند، هیچ‌کدام قابل اعتماد نیستند.

واداشتن مردم به استفاده واقعی

بسیاری از ابزارهای داخلی کاملاً درست کار می‌کنند و باز هم شکست می‌خورند، چون مردم به روش قدیمی ادامه می‌دهند.

• با کاربران بسازید. پیش از طراحی نسخه جدید، ببینید کسی امروز کار را چطور انجام می‌دهد.
• سریع‌تر از روش قدیمی بسازید. اگر ارسال بیشتر از فرستادن یک پیام طول بکشد، مردم به فرستادن پیام ادامه می‌دهند.
• فشرده بهتر از زیبا است. اپراتورها جدول‌هایی با فیلترهای خوب و فرم‌های سازگار با کیبورد را به کارت‌های بزرگ و فضای خالی ترجیح می‌دهند.
• اقدام بعدی را اول بگذارید. «در انتظار من» باید اولین چیزی باشد که مردم می‌بینند.

اشتباهات رایج

• بازسازی کل صفحه‌گسترده. همان یک گردش کار دردسرساز را منتقل کنید؛ بقیه را فعلاً در صفحه نگه دارید.
• نبود مالک. باید کسی پس از راه‌اندازی مسئول تغییرات و رفع مشکل باشد.
• دسترسی به‌عنوان فکر بعدی. افزودن نقش به ابزاری که تمام شده سخت‌تر از شروع با نقش‌ها است.
• حذف ردپای ممیزی، و بعد نیاز به آن در اولین باری که پولی گم می‌شود.
• منتشر کردن روی یک آدرس عمومی بدون ورود. هر چیزی که داخلی است باید ورود بخواهد.

نگه‌داشتن آن بعد از راه‌اندازی

یک فرایند هر چند ماه تغییر می‌کند — یک مرحله تأیید جدید، یک دسته جدید، یک تیم جدید. از همان ابتدا برای آن برنامه بریزید:

• تنظیمات را در جدول نگه دارید، نه در کد. دسته‌بندی‌ها، حدها و تخصیص تأییدکننده‌ها که در پایگاه داده‌اند می‌توانند بدون بازسازی توسط مدیر تغییر کنند.
• درخواست‌ها را در یک جا جمع کنید. یک لینک ساده «پیشنهاد تغییر» در ابزار بهتر از درخواست‌های پراکنده در چت‌ها است.
• منظم خروجی بگیرید. یک خروجی CSV از جداول اصلی یعنی داده هرگز زندانی نمی‌شود و گزارش پایان ماه را آسان می‌کند.
• بعد از هر تغییر آزمایش کنید. پس از هر تغییر در گردش کار، ارسال، تأیید و رد را دوباره امتحان کنید، چون باگ‌های دسترسی معمولاً همان‌جا ظاهر می‌شوند.

هزینه‌های جاری

ابزار داخلی ساخته‌شده با AI هزینه میزبانی، پایگاه داده، فضای ذخیره‌سازی فایل اگر افراد سند آپلود کنند، و احتمالاً یک سرویس ایمیل یا پیام برای اعلان‌ها دارد. معمولاً برای ابزاری که مالکش هستید مجوز به ازای هر صندلی وجود ندارد، که وقتی کاربران گاه‌به‌گاه زیادی دسترسی می‌خواهند اهمیت دارد. هزینه مداوم، زمان یک نفر برای نگه‌داری آن است.

ساختن با Mythex

ابزارهای داخلی برای Mythex مناسب‌اند. گردش کار را توصیف می‌کنید، عامل آن را در پیش‌نمایش زنده می‌سازد، یک پایگاه داده Postgres برای رکوردها و فضای ذخیره‌سازی فایل برای آپلودهایی مثل رسید اضافه می‌کند. مورد استفاده ابزار داخلی و مورد استفاده پنل مدیریت در مستندات، پرامپت‌های شروع دارند. همکاران می‌توانند در فضای کاری شما بدون هزینه صندلی به ساخت کمک کنند.

دو نکته. ورود تیمتان برای استفاده از ابزار بخشی از اپی است که می‌سازید، با روشی که خودتان انتخاب می‌کنید — و جدا از حساب‌های Mythex است. و Mythex یکپارچگی داخلی با Salesforce، HubSpot یا Slack برای خود اپ ندارد؛ آن‌ها از طریق API خودشان و با کلیدهای خودتان وصل می‌شوند. برای یک پرامپت شروع، قالب‌های ردیاب تأیید یا ابزار مدیریت داخلی را امتحان کنید، و اگر چیزی که لازم دارید بیشتر نمودار است، نحوه ساخت داشبورد را ببینید.

پرسش‌ها