آموزش و راهنما

هوش مصنوعی در خدمات پس از فروش؛ راهنمای ساخت دستیار اعزام تکنسین با API

هوش مصنوعی می‌تواند ثبت درخواست خدمات، تشخیص نوع خرابی، خلاصه‌سازی سابقه تجهیزات، آماده‌سازی تکنسین و تبدیل گزارش بازدید به داده ساختاریافته را ساده‌تر کند. در این راهنما، معماری و نمونه کد ساخت دستیار خدمات پس از فروش با API را بررسی می‌کنیم.

Excerpt: هوش مصنوعی می‌تواند ثبت درخواست خدمات، تشخیص نوع خرابی، خلاصه‌سازی سابقه تجهیزات، آماده‌سازی تکنسین و تبدیل گزارش بازدید به داده ساختاریافته را ساده‌تر کند. در این راهنما، معماری و نمونه کد ساخت دستیار خدمات پس از فروش با API را بررسی می‌کنیم.

عنوان متا: هوش مصنوعی در خدمات پس از فروش و اعزام تکنسین

توضیحات متا: کاربردهای هوش مصنوعی در خدمات پس از فروش، مدیریت درخواست، تعمیرات و اعزام تکنسین را بشناسید و ساخت دستیار خدمات میدانی با API را بیاموزید.

اسلاگ: ai-field-service-management-guide

هوش مصنوعی در خدمات پس از فروش؛ راهنمای ساخت دستیار اعزام تکنسین با API

شرکت‌هایی که نصب، تعمیر، نگهداری یا خدمات پس از فروش ارائه می‌کنند، روزانه با تعداد زیادی تماس، پیام، درخواست سرویس، گزارش تکنسین و سابقه تجهیزات مواجه‌اند.

اطلاعات اولیه مشتری ممکن است کامل نباشد:

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

اپراتور باید از میان این توضیحات، نوع تجهیز، نشانه خرابی، میزان فوریت، محل خدمت و اطلاعات موردنیاز را استخراج کند. سپس درخواست باید به واحد مناسب ارجاع داده شود و تکنسینی با مهارت، زمان آزاد و موقعیت مناسب انتخاب شود.

هوش مصنوعی می‌تواند بخش زبانی و اطلاعاتی این فرایند را ساده‌تر کند؛ اما انتخاب قطعی تکنسین، محاسبه مسیر، رزرو زمان و تغییر وضعیت سفارش باید توسط سامانه خدمات و قواعد مشخص انجام شوند.

در این مقاله، کاربرد هوش مصنوعی در خدمات پس از فروش و روش ساخت یک دستیار ثبت و تحلیل درخواست تعمیر با API درواره را بررسی می‌کنیم.

خدمات میدانی چیست؟

خدمات میدانی یا Field Service به فعالیت‌هایی گفته می‌شود که کارکنان یا تکنسین‌های یک شرکت در محل مشتری انجام می‌دهند.

نمونه‌های آن عبارت‌اند از:

نصب تجهیزات
تعمیر لوازم و دستگاه‌ها
سرویس دوره‌ای
بازدید فنی
بازرسی تجهیزات
کالیبراسیون
نگهداری پیشگیرانه
تحویل و راه‌اندازی محصول
رفع خرابی در محل
خدمات تأسیسات
تعمیر تجهیزات صنعتی
پشتیبانی تجهیزات مخابراتی
سرویس آسانسور و سیستم‌های سرمایشی

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

در مستندات Dynamics 365 Field Service نیز چرخه کار از ایجاد سفارش کار تا زمان‌بندی، اعزام، انجام خدمت و صورتحساب تعریف شده است. سفارش‌های کار می‌توانند از تماس، ایمیل، پورتال، قرارداد خدمات یا داده تجهیزات ایجاد شوند. معرفی Dynamics 365 Field Service

هوش مصنوعی در خدمات پس از فروش چیست؟

هوش مصنوعی در خدمات پس از فروش به استفاده از مدل‌های زبانی، پردازش گفتار، بینایی ماشین، جست‌وجوی معنایی و مدل‌های تحلیلی برای بهبود فرایندهای ارائه خدمت گفته می‌شود.

این فناوری می‌تواند در مراحل مختلف استفاده شود:

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

برای نمونه، مایکروسافت از هوش مصنوعی برای خلاصه‌کردن سفارش کار، وضعیت، اولویت، فعالیت‌ها، قطعات و اقدامات بعدی در نرم‌افزار Field Service استفاده می‌کند. خلاصه‌سازی سفارش‌های کار با Copilot

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

مدل هوش مصنوعی و نرم‌افزار مدیریت خدمات وظایف یکسانی ندارند.

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

مدل می‌تواند از متن مشتری بفهمد که «دستگاه صدای غیرعادی دارد و بوی سوختگی احساس می‌شود»، اما نباید بدون بررسی فنی اعلام کند که موتور دستگاه سوخته است.

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

مهارت ثبت‌شده
محدوده جغرافیایی
شیفت کاری
زمان آزاد
ظرفیت روزانه
مجوزهای فنی
قطعات همراه
سطح اولویت
قرارداد مشتری

کاربردهای هوش مصنوعی در خدمات پس از فروش

ثبت خودکار درخواست از روی پیام مشتری

مشتری ممکن است درخواست خود را از طریق فرم، پیام‌رسان، ایمیل، چت یا تماس تلفنی ثبت کند.

مدل زبانی می‌تواند متن را تحلیل و اطلاعاتی مانند این موارد را استخراج کند:

نوع تجهیز
برند یا مدل ذکرشده
نشانه خرابی
زمان شروع مشکل
محل خدمت
فوریت ادعاشده
سابقه اقدام مشتری
زمان ترجیحی مراجعه
اطلاعات ناقص

پس از اعتبارسنجی، این اطلاعات می‌توانند به‌عنوان پیش‌نویس سفارش کار به نرم‌افزار خدمات ارسال شوند.

دسته‌بندی درخواست‌ها

درخواست‌های خدماتی را می‌توان در دسته‌های مشخص قرار داد:

نصب
تعمیر
سرویس دوره‌ای
بازدید
آموزش استفاده
تأمین قطعه
پیگیری سفارش
شکایت از خدمت قبلی
درخواست نامشخص

وجود دسته «نامشخص» ضروری است. اگر مدل برای انتخاب یکی از دسته‌ها مجبور شود، ممکن است نوع درخواست را حدس بزند.

تشخیص اطلاعات ناقص

پیش از اعزام تکنسین، اطلاعاتی مانند نشانی، شماره تجهیز یا شرح خرابی ممکن است لازم باشند.

مدل می‌تواند اطلاعات بیان‌شده را استخراج کند؛ سپس نرم‌افزار، خروجی را با فهرست فیلدهای اجباری مقایسه کند.

برای مثال:

نوع خدمت: تعمیر
نوع تجهیز: پکیج دیواری
نشانه خرابی: آب گرم نمی‌شود
نشانی: ثبت نشده
مدل دستگاه: ثبت نشده
زمان ترجیحی: فردا بعدازظهر

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

مدل نباید خودش تعیین کند که برای هر محصول چه مدارکی یا چه اطلاعاتی الزام قانونی یا قراردادی دارند. این موارد باید از تنظیمات و قواعد سامانه دریافت شوند.

تشخیص اولیه سطح فوریت

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

هوش مصنوعی می‌تواند این نشانه‌ها را برای ارجاع فوری علامت‌گذاری کند، اما نباید جایگزین دستورالعمل ایمنی شود.

اگر پیام شامل خطر احتمالی است، سامانه باید:

پیام ایمنی از پیش تأییدشده را نمایش دهد.
درخواست را به صف فوری منتقل کند.
اپراتور یا مسئول مربوط را مطلع کند.
از ارائه دستور تعمیر نامطمئن توسط مدل جلوگیری کند.
تمام اقدامات را ثبت کند.

متن ایمنی باید توسط متخصص سازمان تهیه شود و از یک قالب ثابت بیاید، نه اینکه در هر درخواست به‌صورت آزاد توسط مدل تولید شود.

خلاصه‌سازی سابقه تجهیز

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

هوش مصنوعی می‌تواند یک خلاصه زمان‌محور تولید کند:

تاریخ نصب
آخرین سرویس
خرابی‌های تکرارشده
اقدامات انجام‌شده
قطعات تعویض‌شده
نتیجه آخرین بازدید
توصیه‌های ثبت‌شده
موارد حل‌نشده

در Dynamics 365 Field Service نیز خلاصه سفارش کار می‌تواند اطلاعات سفارش، سابقه تجهیز، فعالیت‌ها، قطعات و اقدامات بعدی را برای مدیران، اعزام‌کنندگان و تکنسین‌ها آماده کند. تنظیم خلاصه سفارش کار در Field Service

آماده‌سازی تکنسین پیش از مراجعه

پس از انتخاب تکنسین، دستیار هوشمند می‌تواند خلاصه‌ای کاربردی برای او بسازد:

مشکل گزارش‌شده چیست؟
مشتری چه اقداماتی انجام داده است؟
آخرین تعمیر چه بوده است؟
چه مهارتی احتمالاً لازم است؟
چه قطعاتی ممکن است بررسی شوند؟
چه سؤالاتی باید از مشتری پرسیده شود؟
کدام هشدارهای رسمی محصول مرتبط‌اند؟

پیشنهاد قطعه به معنی ثبت مصرف یا سفارش قطعه نیست. موجودی باید از انبار استعلام شود و تکنسین یا مسئول مجاز تصمیم نهایی را بگیرد.

جست‌وجو در راهنمای تعمیرات

دفترچه‌های فنی، راهنماهای نصب، دستورالعمل‌های عیب‌یابی و بولتن‌های خدماتی می‌توانند به یک سامانه RAG متصل شوند.

تکنسین می‌تواند سؤال کند:

خطای E14 در این مدل چه معنایی دارد؟
ترتیب رسمی بررسی این هشدار چیست؟
برای این سرویس چه ابزارهایی لازم است؟
دستورالعمل تعویض قطعه در کدام صفحه است؟

پاسخ باید همراه با نام سند، نسخه و بخش منبع نمایش داده شود. اگر سند مرتبط پیدا نشد، مدل باید این موضوع را اعلام کند و از ساختن دستورالعمل خودداری کند.

برای آشنایی بیشتر می‌توانید مقاله RAG چیست و چگونه کار می‌کند؟ را مطالعه کنید.

تبدیل صدای تکنسین به گزارش

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

دستگاه بررسی شد. فیلتر به‌شدت مسدود بود. فیلتر تعویض و مسیر هوا تمیز شد. دستگاه اکنون روشن می‌شود، اما پیشنهاد شد برد در سرویس بعدی دوباره بررسی شود.

سامانه ابتدا صدا را به متن تبدیل می‌کند و سپس مدل زبانی می‌تواند اطلاعات را استخراج کند:

مشکل مشاهده‌شده
علت احتمالی
اقدام انجام‌شده
قطعه مصرف‌شده
وضعیت نهایی
توصیه بعدی
نیاز به مراجعه مجدد

تکنسین باید نتیجه را پیش از ثبت قطعی تأیید کند. مدل نباید قطعه‌ای را که در متن ذکر نشده به گزارش اضافه کند.

تکمیل پیشنهادی سفارش کار

مدل می‌تواند از توضیحات طبیعی تکنسین، مقادیر پیشنهادی برای فیلدهای سفارش کار بسازد.

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

عبارت «پس از تأیید» در این معماری اهمیت زیادی دارد. مدل پیشنهاد می‌دهد؛ کاربر مسئول، نتیجه را بررسی و ثبت می‌کند.

تهیه پیام برای مشتری

دستیار می‌تواند بر اساس وضعیت واقعی سفارش، پیش‌نویس پیام بسازد:

تأیید دریافت درخواست
درخواست تکمیل اطلاعات
اعلام بازه پیشنهادی مراجعه
اطلاع‌رسانی تأخیر
اعلام پایان عملیات
درخواست بازخورد
یادآوری سرویس دوره‌ای

اطلاعاتی مانند نام تکنسین، زمان مراجعه و وضعیت قطعه باید از نرم‌افزار دریافت شوند. مدل نباید آن‌ها را حدس بزند.

تحلیل گزارش‌های خرابی

با تجمیع گزارش‌های تأییدشده می‌توان موضوعات پرتکرار را شناسایی کرد:

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

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

هوش مصنوعی چگونه به اعزام تکنسین کمک می‌کند؟

اعزام تکنسین از دو مسئله متفاوت تشکیل شده است:

درک درخواست

مدل زبانی می‌تواند بفهمد مشتری چه مشکلی را توصیف کرده و چه مهارتی احتمالاً موردنیاز است.

بهینه‌سازی تخصیص

موتور زمان‌بندی باید مناسب‌ترین تکنسین را بر اساس داده‌های واقعی انتخاب کند.

معیارهای تخصیص ممکن است شامل این موارد باشند:

فاصله از محل مشتری
زمان سفر
مهارت لازم
ساعات کاری
مدت تقریبی خدمت
اولویت سفارش
تجهیزات همراه
محدوده مجاز فعالیت
ظرفیت باقی‌مانده
وابستگی میان مأموریت‌ها

در مستندات Field Service نیز انتخاب منابع بر اساس مکان، دسترس‌پذیری، مهارت و اولویت به‌عنوان بخشی از زمان‌بندی معرفی شده است. چرخه مدیریت سفارش کار و زمان‌بندی

مدل زبانی نباید برنامه روزانه را بدون بررسی این محدودیت‌ها بسازد. معماری بهتر این است که مدل نیاز را استخراج کند و موتور زمان‌بندی گزینه‌های معتبر را محاسبه کند.

آموزش ساخت دستیار ثبت درخواست خدمات با API درواره

در این مثال یک تابع پایتون می‌سازیم که پیام فارسی مشتری را تحلیل و آن را به یک درخواست ساختاریافته تبدیل می‌کند.

نصب کتابخانه‌ها

pip install openai pydantic

تنظیم متغیرهای محیطی

export DARVAREH_API_KEY="YOUR_API_KEY"
export DARVAREH_MODEL="YOUR_MODEL_ID"

شناسه مدل را از فهرست فعلی مدل‌های درواره انتخاب کنید.

کد پایتون

import os
from typing import Literal

from openai import OpenAI
from pydantic import BaseModel, Field, ValidationError


client = OpenAI(
    api_key=os.environ["DARVAREH_API_KEY"],
    base_url="https://api.darvareh.ir/v1",
)

MODEL_ID = os.environ["DARVAREH_MODEL"]


class ServiceRequestAnalysis(BaseModel):
    request_type: Literal[
        "installation",
        "repair",
        "periodic_service",
        "inspection",
        "training",
        "spare_part",
        "follow_up",
        "complaint",
        "other",
        "unclear",
    ]
    equipment_type: str | None
    equipment_model: str | None
    reported_symptoms: list[str]
    customer_actions: list[str]
    mentioned_location: str | None
    preferred_time: str | None
    missing_information: list[str]
    required_skill_tags: list[str]
    priority_suggestion: Literal[
        "normal",
        "high",
        "urgent_review",
        "unclear",
    ]
    safety_signal: bool
    safety_signal_reason: str | None
    summary: str = Field(max_length=500)
    response_draft: str = Field(max_length=700)


def analyze_service_request(
    customer_message: str,
) -> ServiceRequestAnalysis:
    prompt = f"""
پیام مشتری را برای ثبت اولیه درخواست خدمات تحلیل کن.

قواعد:
- فقط اطلاعات موجود در پیام را استخراج کن.
- نوع خرابی قطعی یا قطعه معیوب را حدس نزن.
- زمان مراجعه یا اعزام تکنسین را تأیید نکن.
- هیچ دستور تعمیر یا اقدام ایمنی تولید نکن.
- اگر نوع درخواست مشخص نیست، request_type را unclear قرار بده.
- اگر نوع یا مدل تجهیز ذکر نشده است، مقدار آن null باشد.
- required_skill_tags فقط پیشنهاد اولیه برای موتور تخصیص است.
- در صورت اشاره به دود، آتش، جرقه، بوی سوختگی،
  نشتی خطرناک یا احتمال آسیب، safety_signal را true کن.
- response_draft فقط دریافت درخواست و اطلاعات موردنیاز
  را توضیح دهد و زمان یا نتیجه خدمت را تضمین نکند.
- پاسخ را فقط به‌صورت JSON معتبر برگردان.
- هیچ متن یا Markdown خارج از JSON ننویس.

پیام مشتری:
{customer_message}
"""

    completion = client.chat.completions.create(
        model=MODEL_ID,
        temperature=0.1,
        messages=[
            {
                "role": "system",
                "content": (
                    "شما دستیار ثبت اولیه خدمات پس از فروش هستید. "
                    "اطلاعات را بدون حدس استخراج می‌کنید و فقط "
                    "JSON معتبر تولید می‌کنید."
                ),
            },
            {
                "role": "user",
                "content": prompt,
            },
        ],
    )

    content = completion.choices[0].message.content

    if not content:
        raise ValueError("پاسخی از مدل دریافت نشد.")

    try:
        return ServiceRequestAnalysis.model_validate_json(content)
    except ValidationError as error:
        raise ValueError(
            f"ساختار پاسخ مدل معتبر نیست: {error}"
        ) from error


result = analyze_service_request(
    """
    سلام، پکیج دیواری منزل از دیشب آب را گرم نمی‌کند
    و کد E14 نشان می‌دهد. یک بار خاموش و روشنش کردم،
    ولی تغییری نکرد. اگر امکان دارد فردا بعدازظهر
    برای محدوده سعادت‌آباد تعمیرکار بفرستید.
    مدل دقیق دستگاه را الان نمی‌دانم.
    """
)

print(result.model_dump_json(indent=2))

نمونه خروجی

{
  "request_type": "repair",
  "equipment_type": "پکیج دیواری",
  "equipment_model": null,
  "reported_symptoms": [
    "آب گرم نمی‌شود",
    "نمایش کد E14"
  ],
  "customer_actions": [
    "خاموش و روشن‌کردن دستگاه"
  ],
  "mentioned_location": "سعادت‌آباد",
  "preferred_time": "فردا بعدازظهر",
  "missing_information": [
    "مدل دقیق دستگاه",
    "نشانی کامل",
    "شماره سریال یا شناسه تجهیز"
  ],
  "required_skill_tags": [
    "تعمیر پکیج دیواری",
    "بررسی خطای دستگاه"
  ],
  "priority_suggestion": "normal",
  "safety_signal": false,
  "safety_signal_reason": null,
  "summary": "مشتری اعلام کرده است پکیج دیواری از شب گذشته آب را گرم نمی‌کند و کد E14 نمایش می‌دهد. خاموش و روشن‌کردن دستگاه مشکل را رفع نکرده و زمان ترجیحی مراجعه فردا بعدازظهر در محدوده سعادت‌آباد است.",
  "response_draft": "سلام، درخواست بررسی پکیج شما ثبت اولیه شد. برای تکمیل درخواست، لطفاً مدل یا تصویر پلاک دستگاه، نشانی کامل و در صورت وجود شماره سریال را ارسال کنید. زمان مراجعه پس از بررسی ظرفیت و هماهنگی نهایی اعلام می‌شود."
}

این خروجی هنوز یک سفارش کار قطعی نیست. سرور باید ساختار آن را اعتبارسنجی و اطلاعات لازم را از مشتری یا سامانه دریافت کند.

اتصال خروجی مدل به موتور زمان‌بندی

پس از تحلیل پیام، نرم‌افزار باید گزینه‌های معتبر را پیدا کند. ساختار ساده این فرایند می‌تواند چنین باشد:

پیام مشتری
    ↓
استخراج نوع خدمت و مهارت پیشنهادی
    ↓
تکمیل نشانی و اطلاعات تجهیز
    ↓
دریافت تکنسین‌های واجد شرایط
    ↓
بررسی شیفت، ظرفیت و محدوده
    ↓
محاسبه بازه‌های قابل ارائه
    ↓
انتخاب مشتری یا اپراتور
    ↓
رزرو قطعی در تراکنش
    ↓
ارسال تأییدیه

هنگام رزرو نهایی باید دوباره آزادبودن بازه کنترل شود؛ زیرا ممکن است فاصله میان نمایش و انتخاب، ظرفیت تغییر کرده باشد.

برای جلوگیری از ثبت چندباره نیز بهتر است هر درخواست رزرو یک کلید یکتا یا Idempotency Key داشته باشد.

نمونه منطق قطعی انتخاب تکنسین

مدل می‌تواند برچسب مهارت را پیشنهاد کند، اما انتخاب تکنسین بهتر است با کد انجام شود:

from dataclasses import dataclass


@dataclass
class Technician:
    technician_id: str
    skill_tags: set[str]
    active: bool
    available_slots: set[str]
    service_areas: set[str]


def find_eligible_technicians(
    technicians: list[Technician],
    required_skills: set[str],
    requested_slot: str,
    service_area: str,
) -> list[Technician]:
    eligible = []

    for technician in technicians:
        if not technician.active:
            continue

        if requested_slot not in technician.available_slots:
            continue

        if service_area not in technician.service_areas:
            continue

        if not required_skills.issubset(
            technician.skill_tags
        ):
            continue

        eligible.append(technician)

    return eligible

این تابع از مدل زبانی نمی‌خواهد زمان آزاد یا مهارت تکنسین را حدس بزند. تمام محدودیت‌ها بر اساس داده‌های ثبت‌شده بررسی می‌شوند.

در نسخه عملی می‌توان معیارهای دیگری مانند فاصله، مدت سفر، اولویت و بار کاری را نیز به موتور تخصیص اضافه کرد.

ساخت دستیار گزارش‌نویسی برای تکنسین

مرحله دیگری که ارزش عملی زیادی دارد، تبدیل یادداشت تکنسین به گزارش ساختاریافته است.

ساختار خروجی می‌تواند شامل موارد زیر باشد:

{
  "observed_problem": [],
  "performed_actions": [],
  "used_parts": [],
  "test_results": [],
  "final_status": "resolved | partially_resolved | unresolved",
  "follow_up_required": true,
  "follow_up_notes": "",
  "customer_instructions": []
}

پرامپت باید صریحاً از مدل بخواهد:

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

پس از تولید نتیجه، تکنسین آن را تأیید می‌کند و سپس اطلاعات در سفارش کار ثبت می‌شوند.

استفاده از Function Calling در خدمات پس از فروش

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

get_customer_assets
get_asset_history
find_available_slots
create_draft_work_order
get_work_order_status
get_approved_manual_section

مدل فقط باید ابزار مناسب و آرگومان‌ها را پیشنهاد کند. سمت سرور باید موارد زیر را کنترل کند:

هویت کاربر
دسترسی به تجهیز
معتبر بودن شناسه
مجاز بودن عملیات
کامل بودن ورودی
آزاد بودن ظرفیت
نیاز به تأیید
ثبت گزارش عملیات

برای درک بهتر این روش می‌توانید مقاله Function Calling چیست؟ را مطالعه کنید.

معماری پیشنهادی برای محصول واقعی

مشتری یا تکنسین
       ↓
وب‌سایت، اپلیکیشن یا مرکز تماس
       ↓
Backend سازمان
       ↓
کنترل دسترسی و آماده‌سازی ورودی
       ↓
API درواره
       ↓
مدل منتخب
       ↓
اعتبارسنجی خروجی JSON
       ↓
موتور قواعد و زمان‌بندی
       ↓
تأیید اپراتور یا تکنسین
       ↓
ثبت در سامانه خدمات

ارتباط مستقیم اپلیکیشن کاربر با API مدل مناسب نیست؛ زیرا کلید API افشا می‌شود و کنترل عملیات دشوار خواهد بود.

کلید API باید فقط در سمت سرور نگهداری شود.

چگونه کیفیت دستیار خدمات را ارزیابی کنیم؟

ارزیابی باید با مجموعه‌ای ثابت از درخواست‌های واقعی انجام شود.

دقت دسته‌بندی

چند درصد درخواست‌ها به نوع صحیح خدمت و صف مناسب ارجاع داده می‌شوند؟

دقت استخراج

برای هر فیلد جداگانه بررسی کنید:

نوع تجهیز
مدل
نشانه خرابی
محل
زمان ترجیحی
اطلاعات ناقص

تشخیص پیام‌های فوری

سامانه باید پیام‌های دارای نشانه خطر را از دست ندهد. در عین حال، علامت‌گذاری بیش‌ازحد نیز باعث شلوغ‌شدن صف فوری می‌شود.

نرخ JSON معتبر

چه درصدی از پاسخ‌ها بدون اصلاح ساختاری توسط برنامه قابل پردازش‌اند؟

میزان اصلاح انسانی

اپراتور یا تکنسین چند درصد خروجی را ویرایش می‌کند؟ اصلاح زیاد ممکن است نشانه ضعف پرامپت، مدل یا ساختار ورودی باشد.

زمان ثبت درخواست

زمان متوسط ثبت و تکمیل درخواست قبل و بعد از اجرای دستیار چقدر است؟

نرخ مراجعه مجدد

آیا آماده‌سازی بهتر تکنسین و دسترسی به سابقه تجهیز، مراجعه‌های تکراری ناشی از اطلاعات ناقص را کاهش داده است؟

هزینه هر درخواست

هزینه مدل، پردازش صوت، جست‌وجوی اسناد و زیرساخت را به تفکیک قابلیت اندازه‌گیری کنید.

معیارهای انتخاب مدل مناسب

کیفیت زبان فارسی

مدل باید پیام‌های رسمی، محاوره‌ای و دارای غلط املایی را درک کند.

نمونه‌های آزمایشی باید شامل موارد زیر باشند:

اعداد فارسی و انگلیسی
تاریخ نسبی مانند «پس‌فردا»
نام محله و شهر
مدل‌های ترکیبی فارسی و لاتین
توضیحات کوتاه و مبهم
چند مشکل در یک پیام

دقت در پیروی از ساختار

مدل باید JSON معتبر و مقادیر محدودشده تولید کند.

توانایی کار با متن طولانی

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

قابلیت چندوجهی

اگر محصول باید تصویر پلاک دستگاه یا خرابی را تحلیل کند، مدل انتخابی باید ورودی تصویر را پشتیبانی کند.

سرعت پاسخ

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

هزینه

برای دسته‌بندی ساده ممکن است یک مدل سریع و اقتصادی کافی باشد. خلاصه‌سازی پرونده‌های پیچیده یا تحلیل تصویر ممکن است به مدل دیگری نیاز داشته باشد.

امکان تغییر مدل

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

مدیریت هزینه API

وظایف را تفکیک کنید

برای همه مراحل از یک مدل استفاده نکنید. ممکن است وظایف زیر به مدل‌های متفاوتی نیاز داشته باشند:

دسته‌بندی کوتاه
استخراج اطلاعات
تحلیل تصویر
خلاصه‌سازی سابقه
تولید پاسخ
تبدیل گفتار به متن

تاریخچه را محدود کنید

برای هر درخواست فقط رکوردهای مرتبط با همان تجهیز و مسئله را ارسال کنید.

خروجی را کوتاه نگه دارید

در وظایف عملیاتی، JSON کوتاه معمولاً از گزارش متنی طولانی مفیدتر است.

نتایج ثابت را ذخیره کنید

خلاصه راهنمای محصول یا Embedding اسناد را برای هر درخواست دوباره تولید نکنید، مگر اینکه منبع تغییر کرده باشد.

مصرف را بر اساس قابلیت ثبت کنید

مشخص کنید هر بخش از محصول چه میزان مصرف و چه ارزش عملیاتی ایجاد می‌کند.

برای محاسبه دقیق‌تر می‌توانید راهنمای هزینه API هوش مصنوعی را بخوانید.

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

سپردن کامل اعزام به مدل زبانی

مدل به‌تنهایی از ظرفیت لحظه‌ای، مهارت قطعی و موقعیت تکنسین‌ها خبر ندارد. تخصیص باید توسط موتور زمان‌بندی انجام شود.

تأیید زمان بدون رزرو واقعی

پیشنهاد «فردا ساعت ۱۰» تا زمانی که در سامانه رزرو نشده است، قرار قطعی محسوب نمی‌شود.

ارائه تشخیص قطعی از روی توضیح کوتاه

یک نشانه می‌تواند علت‌های مختلف داشته باشد. مدل باید اطلاعات را استخراج و پرسش تکمیلی پیشنهاد کند، نه اینکه خرابی را قطعی اعلام کند.

تولید دستورالعمل ایمنی به‌صورت آزاد

برای موقعیت‌های پرخطر باید از متن‌های تأییدشده سازمان استفاده شود.

ثبت خودکار قطعه مصرفی

قطعات باید از گزارش تکنسین، اسکن کالا یا رکورد انبار تأیید شوند.

نبود امکان اصلاح

اپراتور و تکنسین باید بتوانند خروجی مدل را پیش از ثبت نهایی ببینند و اصلاح کنند.

نداشتن منبع برای پاسخ فنی

پاسخ‌های مربوط به تعمیر باید به راهنمای معتبر و نسخه درست تجهیز متصل باشند.

آزمایش فقط با پیام‌های مرتب

درخواست‌های واقعی کوتاه، مبهم، محاوره‌ای و گاهی متناقض‌اند. مجموعه ارزیابی باید این تنوع را پوشش دهد.

مسیر پیشنهادی پیاده‌سازی

مرحله اول: انتخاب یک فرایند

با ثبت اولیه درخواست یا خلاصه‌سازی گزارش تکنسین شروع کنید.

مرحله دوم: تعریف طرح خروجی

فیلدهای لازم، گزینه‌های مجاز و شرایط ارجاع انسانی را مشخص کنید.

مرحله سوم: جمع‌آوری نمونه‌ها

نمونه‌هایی از درخواست‌های واقعی و خروجی مطلوب تهیه کنید. اطلاعات غیرضروری را حذف کنید.

مرحله چهارم: مقایسه مدل‌ها

چند مدل را از نظر دقت فارسی، سرعت، هزینه و ثبات JSON ارزیابی کنید.

مرحله پنجم: اجرای آزمایشی

خروجی مدل را فقط به اپراتور نمایش دهید و اصلاحات او را ثبت کنید.

مرحله ششم: اتصال به سامانه

پس از رسیدن به کیفیت مناسب، ایجاد پیش‌نویس سفارش کار و دریافت ظرفیت را از طریق Backend فعال کنید.

مرحله هفتم: خودکارسازی محدود

اقدامات کم‌ریسک و قابل بازگشت را خودکار کنید و رزرو، تغییر وضعیت مهم یا ثبت هزینه را به کنترل‌های قطعی و تأیید مناسب بسپارید.

آیا درواره برای ساخت دستیار خدمات مناسب است؟

درواره دسترسی یکپارچه به مدل‌های مختلف هوش مصنوعی را از طریق API سازگار با OpenAI فراهم می‌کند.

توسعه‌دهندگان نرم‌افزارهای خدمات پس از فروش، CRM، ERP و مدیریت تعمیرات می‌توانند قابلیت‌هایی مانند موارد زیر را به محصول خود اضافه کنند:

تحلیل پیام مشتری
استخراج اطلاعات
دسته‌بندی درخواست
خلاصه‌سازی سفارش کار
تولید پیش‌نویس پاسخ
تحلیل گزارش تکنسین
جست‌وجوی معنایی
پردازش تصویر و صوت با مدل مناسب

آدرس پایه API درواره عبارت است از:

https://api.darvareh.ir/v1

با یک کلید API و کیف پول ریالی می‌توان مدل‌های مختلف را آزمایش و بر اساس کیفیت، سرعت و هزینه، گزینه مناسب هر وظیفه را انتخاب کرد.

درواره جایگزین نرم‌افزار مدیریت خدمات، موتور زمان‌بندی یا سیستم انبار نیست. این پلتفرم لایه دسترسی به مدل‌های هوش مصنوعی را فراهم می‌کند و منطق عملیاتی در نرم‌افزار شما باقی می‌ماند.

برای شروع، مستندات API درواره را مشاهده کنید.

پرسش‌های متداول

هوش مصنوعی در خدمات پس از فروش چه کاربردی دارد؟

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

آیا هوش مصنوعی می‌تواند تکنسین مناسب را انتخاب کند؟

مدل می‌تواند مهارت موردنیاز را پیشنهاد کند، اما انتخاب نهایی باید با استفاده از اطلاعات واقعی درباره مهارت، موقعیت، ظرفیت و شیفت تکنسین انجام شود.

آیا می‌توان زمان مراجعه را با هوش مصنوعی رزرو کرد؟

مدل می‌تواند منظور مشتری و زمان ترجیحی را استخراج کند. ظرفیت واقعی باید از سامانه زمان‌بندی دریافت و رزرو نهایی توسط Backend ثبت شود.

آیا هوش مصنوعی می‌تواند خرابی دستگاه را تشخیص دهد؟

مدل می‌تواند نشانه‌ها و علت‌های احتمالی را برای بررسی پیشنهاد کند، اما تشخیص قطعی به داده کافی، مستندات معتبر و بررسی تکنسین نیاز دارد.

آیا می‌توان گزارش صوتی تکنسین را خودکار ثبت کرد؟

بله. صدا ابتدا به متن تبدیل می‌شود و سپس مدل اطلاعات ساختاریافته را استخراج می‌کند. تکنسین باید نتیجه را پیش از ثبت نهایی تأیید کند.

آیا برای هر وظیفه به یک مدل جداگانه نیاز داریم؟

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

آیا API درواره با OpenAI SDK سازگار است؟

بله. در بسیاری از پروژه‌ها کافی است base_url، کلید API و شناسه مدل را تنظیم کنید و از همان ساختار کتابخانه OpenAI استفاده کنید.

جمع‌بندی

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

برای پیاده‌سازی مطمئن:

با یک کاربرد محدود شروع کنید.
خروجی مدل را ساختاریافته دریافت کنید.
گزینه «نامشخص» را برای اطلاعات مبهم در نظر بگیرید.
زمان و ظرفیت را از سامانه واقعی دریافت کنید.
تخصیص تکنسین را با قواعد قطعی انجام دهید.
پاسخ‌های فنی را به مستندات معتبر متصل کنید.
گزارش تکنسین را پیش از ثبت نهایی تأیید کنید.
اقدامات حساس را مستقیماً به مدل نسپارید.
مدل‌ها را روی پیام‌های واقعی فارسی ارزیابی کنید.
کیفیت، زمان و هزینه هر قابلیت را اندازه‌گیری کنید.

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

مقالات مرتبط

منابع

این مقاله صرفاً با هدف آموزش و اطلاع‌رسانی تهیه شده است. پیش از استفاده عملی، مستندات رسمی سرویس‌ها و صفحه سلب مسئولیت را مطالعه کنید.