AI-құралдарға арналған құмсалғыш: артық құқықсыз жазу

Неге агенттің жазуы оқудан қауіпті

Оқу жұмыс барысын сирек өзгертеді. Агент деректерді қате түсініп, нашар жауап беруі мүмкін, бірақ жазу жүйенің өзін өзгертеді: клиент карточкасын түзетеді, статусын жаңартады, пікір қосады, тапсырманы жабады. Осыдан кейін қате чатта емес, CRM-де, деректер базасында немесе құжатта қалады.

Ең жиі кездесетін мәселе қарапайым: агент ұқсас объектілерді шатастырады. Екі клиенттің атауы ұқсас, екі мәміленің нөмірі шамалас, контактілердің тегі бірдей. Адам мұндай айырманы көбіне контекст арқылы тез аңғарады. Ал агент көбіне бірінші сәйкес келген нұсқаны алып, деректі дұрыс емес жерге жазады.

Бір қате түзету сирек жалғыз қалады. CRM-дегі бір өрісті өзгерту бірден тізбекті іске қосуы мүмкін: мәміле кезеңі ауысады, сегмент қайта есептеледі, хат жіберіледі, менеджерге тапсырма құрылады, есеп жаңарады. Қате тез үлкейеді, кейін команда бір ғана фактіні емес, автоматты әрекеттердің бүкіл ізін жөндеуге мәжбүр болады.

Менеджер көбіне мәселені кеш байқайды. Бәрі сенімді болып көрінгенше, ешкім әр өрісті қолмен тексермейді. Дабыл клиент қоңырауынан, есептегі ақаудан немесе таратылған хаттың оғаш көрінуінен кейін ғана келеді. Сол кезде агент тағы бірнеше жазба енгізіп үлгеруі мүмкін, ал алғашқы қатені табу қиынға соғады.

Тағы бір қауіп бар: жазу жалған сенім тудырады. Чаттағы қате жауапты қайта сұрауға немесе өшіруге болады. Қате жазбаны адамдар факт ретінде қабылдап, құжатқа көшіреді және жұмыста пайдаланады.

Егер қалыпты логтар болмаса, себепті табу созылып кетеді. Команда статус өзгергенін көреді, бірақ оны кім, қандай ереже бойынша және қай сұраныстан жасады - түсінбейді. Сосын болжам басталады: интеграцияларды, қызметкерлерді, сценарийлерді тексереді. Ал шын себеп біреу ғана - агенттің сәтсіз әрекеті.

Құмсалғыш формальдылық үшін керек емес. Жазу құқықтары дерекке емес, салдарға қолжетімділік береді. Оқудағы қате уақыт алады. Жазудағы қате бүкіл команданың жұмыс шындығын өзгертеді.

Нені алдымен оқшаулау керек

Алдымен бизнес үшін «ақиқат көзі» болып тұрғанның бәрін бөліп алыңыз. Жобаның черновигіндегі қате жағымсыз, бірақ көтеруге болады. CRM, деректер базасы немесе келісімшарт үлгісіндегі қате ұзақ сақталады және соңынан шоттарды, хабарландыруларды, тапсырмаларды және есептердегі күмәнді сандарды ілестіріп жүреді.

Әдетте оқшаулаудың бірінші қабатына бес аймақ кіреді:

• мәміле статусын, соманы және жауапты адамды өзгертетін CRM өрістері
• жеке деректері бар жазбалар: телефон, email, мекенжай, ИИН, қарым-қатынас тарихы
• агент жазба құра, біріктіре немесе өшіре алатын кестелер
• кейін келісімшарттар, актілер және хабарламалар шығатын құжат және хат үлгілері
• жүйе өзі шот, хабарлама немесе тапсырма іске қосатын әрекеттер

CRM-ді бәрінен бұрын бөлек контурға шығарған дұрыс. Бір ғана қате өріс те процесті бұзады: мәміле кенет «сәтті» деп кетеді, сома болжамға түседі, ал иесі ауысып, контексттен айырылады. Агент өзгерісті бірден боевой карточкаға жазғаннан гөрі, оны ұсынғаны әлдеқайда қауіпсіз.

Жеке деректері бар өрістерді қарапайым жазбалар мен тегтерден бөлек оқшаулаған жөн. Егер әрекет үшін толық телефон нөмірі немесе ИИН қажет болмаса, оларды мүлде көрсетпеңіз. Қазақстандағы командалар үшін бұл деректерді сақтау мен өзгерістер журналын жүргізуге қойылатын жергілікті талаптар мәселесі де.

Агент жазба құра немесе өшіре алатын кестелер көбіне ең қымбат ақауды әкеледі. Клиенттің дубликаты оңай пайда болады. Дұрыс емес жазбаны өшіру одан да оңай. Жұмыс ережесі қарапайым: жою әдепкіде тыйым салынған, ал жаңа жазбалар алдымен staging-қабатқа түседі немесе «жоба» мәртебесін алады.

Келісімшарт, акт және хат үлгілерін де қатаң бақылауда ұстаған дұрыс. Агент құжаттың көшірмесіне айнымалыларды қоса алады, бірақ негізгі үлгіні қайта жазбауы керек. Әйтпесе бір сәтсіз түзету ондаған файлға тарайды.

Сыртқы әсері бар әрекеттерді бөлек оқшаулаңыз. Егер өрістегі өзгеріс бірден шотты, клиентке хатты немесе командаға тапсырманы іске қосса, мұндай әрекетті кезек, тексеру ережесі немесе қолмен растау арқылы өткізіңіз. Әр мұндай жазбаны «дейін» және «кейін» өрістерімен, уақытымен және агент ID-сімен журналға түсірген пайдалы. Кейін бұл талдауға кететін сағаттарды үнемдейді.

Құқықтарды артық қолжетімділіксіз қалай бөлуге болады

Егер агент оқып та, жазып та бір қолжетімділік арқылы жұмыс істесе, оған әдетте қажеттен көп құқық беріледі. Жазу үшін бұл дұрыс бастама емес. Алдымен қолжетімділікті екі қабатқа бөліңіз: оқу бөлек, жазу бөлек.

Дерек маскаланған болса және агентке шын мәнінде контекст керек болса, оқуды кеңірек ашуға болады. Ал жазу басынан-ақ тар болуы тиіс. «CRM-ге қолжетімділік» емес, бір сценарийдегі бір ғана әрекетке құқық.

Жақсы ереже былай естіледі: бір агент, бір рөл, бір жазу маршруты. Егер агент қоңыраудан кейін лид карточкасын жаңартса, оған мәміле иесін өзгерту, жазбаларды жою немесе жаппай импорт іске қосу құқығын бермеңіз. Ол тек сіз қосқан міндетті ғана орындай алуы керек.

Қандай құқықтарды шектеу керек

Ең жиі қате - пайдаланушы немесе қызмет деңгейінде қолжетімділік беріп, содан кейін промптқа үміт арту. Промпт құқықтарды бақылауды алмастырмайды. Шектеулерді интеграцияның өзінде қою керек:

• тек керекті команданы ғана рұқсат ету, мысалы update, бірақ delete емес
• тек нақты өрістерді ашу, мысалы «status», «next_step», «contact_date»
• жаппай түзетулерге, экспортқа және схеманы өзгертуге тыйым салу
• жазбаны бір объектіге немесе объект түріне байлау

Жоюды көбіне адамға қалдырған дұрыс. Жаппай түзетулерді де солай. Бір сәтсіз сұраныс бірнеше минут ішінде мыңдаған жазбаны бұзып жіберуі мүмкін, содан кейін команда салдарын қолмен талдайды.

Әр құралға бөлек токен - тағы бір базалық ереже. CRM, деректер базасы және құжаттар үшін бір ортақ құпияны қолданбаңыз. Бір токен сыртқа кетсе немесе агенттің мінезі оғаштанып кетсе, сіз тек сол арнаны өшіре аласыз, бүкіл контурды емес.

Токенді тек жүйеге ғана емес, рұқсат етілген командалар тізіміне де байлаған пайдалы. Мысалы, CRM үшін токен мәміледегі екі өрісті ғана өзгерте алады, ал деректер базасына арналған токен қызметтік кестеде тек черновик жазбасын жасай алады. Бұл баптау қызықсыз көрінеді, бірақ тосын жағдайлардан жақсы қорғайды.

Жұмыс схемасы былай көрінеді: агент қауіпсіз қабат арқылы оқиды, әрекетті қалыптастырады, ал жазуды қысқа рұқсаттар тізімі бар бөлек тар құрал орындайды. Егер сценарий кеңейсе, жаңа рөл және жаңа токен жасаңыз. Ескі құқықтарды «бір жағы керек болып қалар» деп соза бермеңіз.

Құмсалғышты қалай кезең-кезеңімен құруға болады

Алдымен агент нені өзгерте алатынын нақты бекітіңіз. «CRM-мен жұмыс» емес, қысқа әрі жабық әрекеттер жинағы: тапсырма құру, мәміле статусын жаңарту, пікір қосу, бір өрісті толтыру. Жазбаны жою немесе клиент иесін өзгертуге болмайды. Тізім қаншалықты тар болса, кездейсоқ түзету соғұрлым аз.

Шектеулерді алдын ала сипаттап алған ыңғайлы:

• тек таңдалған өрістерді өзгерту
• тек бір типтегі объектілермен жұмыс істеу
• тек тестілік немесе қызметтік сегментке жазу
• жою мен жаппай жаңартуларды орындамау
• анық емес жағдай туғанда орындауды тоқтату

Содан кейін бөлек қызметтік есептік жазбалар ашыңыз. Агентке қызметкердің токенін немесе «бәріне бірдей» ортақ интеграция қолжетімділігін бермеңіз. CRM, деректер базасы және құжаттар үшін әртүрлі рөлдері бар бөлек есептік жазбалар жасаған дұрыс. Егер агент клиент карточкаларын жаңартса, оған қаржылық есептерге, HR файлдарына және воронка баптауларына қолжетімділік керек емес.

Келесі қадам - тестілік контур. Деректер көшірмесін алып, артық нәрсенің бәрін алып тастаңыз: жеке деректерді, нақты телефондарды, сценарийге қажет емес ішкі жазбаларды. Осындай көшірмеде агенттің жаман хаттарда, дубльдерде, бос өрістерде және даталардың оғаш форматтарында қалай әрекет ететінін тексеру оңай. Модель AI Router сияқты шлюз арқылы өтсе де, жазу құқықтарын модель шақыруының өзінен бөлек ұстаған дұрыс.

Содан кейін бір іске қосуға арналған түзетулер санына қатаң шек қойыңыз. Бұл қарапайым ереже көп жағдайда үлкен проблемалардан сақтайды. Егер агент 20 карточканы жаңартуы керек болса, 200-ге рұқсат бермеңіз. Егер операциялар күрт көбейсе, жүйе тапсырманы тоқтатып, қолмен тексеруді сұрауы тиіс.

Журнал бірінші күннен керек. Сценарийді кім іске қосқанын, модельге қандай промпт кеткенін, агент қандай құрал шақырғанын, өзгеріске дейін не болғанын және кейін не болғанын сақтаңыз. Жылдам қайтару үшін өзгерген өрістердің суретін сақтау немесе өзгерістерді бөлек оқиғалар ретінде жазу ыңғайлы, сонда бұрынғы күйді бір командамен қайтара аласыз.

Жақсы құмсалғыш әдетте модельден емес, қарапайым шекаралардан басталады: аз құқық, шағын тестілік контур, қысқа әрекеттер тізімі және түсінікті қайтару мүмкіндігі. Бұл жалықтыратындай көрінеді, бірақ дәл осындай шаралар көбіне жұмыс істейді.

Жазудан бұрын қандай ережелер қою керек

Кез келген жазудың алдында агент бірнеше қатаң тексеруден өтуі тиіс. Әйтпесе хатты немесе өрісті танудағы бір қате CRM-дегі дұрыс емес сомаға, бұзылған мәміле статусына немесе қате клиентке жазылған жазбаға айналады.

Бірінші ереже қарапайым: әр өрістің идентификаторын, күнін, сомасын және форматын тексеріңіз. «Ұқсайды» емес, «дәл келді» болуы керек. ID үшін - дәл сәйкес келу. Күн үшін - түсінікті формат және рұқсат етілген аралық. Сома үшін - валюта, белгі және үтірден кейінгі таңба саны. Егер өріс тексеруден өтпесе, агент ештеңе өзгертпейді.

Екінші ереже: әр түзетудің алдында объектіні дереккөзбен қайта салыстырыңыз. Агент карточканы бес секунд бұрын оқыса да, жазбаның ағымдағы нұсқасын қайта сұрауы керек. Әйтпесе ол біреудің өзгерісін үстінен жазып тастайды. CRM-де бұл жиі болады: менеджер мәміле кезеңін әлдеқашан түзетіп қойған, ал агент ескі мәнді жаңасының орнына жазып жібереді.

Күмәнді сәйкестіктерді өзіңізше болжауға болмайды. Егер бір хат екі тапсырысқа ұқсаса, егер клиенттің бір сомада екі келісімшарты болса, егер құжаттағы дата анық болмаса, тізбекті тоқтату керек. Қалыпты оқшаулау болжамды құптамайды. Жүйе растау сұрап, неге түзетуді орындамағанын журналға жазуы тиіс.

Тәуекелі жоғары жағдайда дайын өзгерістің орнына адамға черновик жіберген дұрыс. Бұл жеңілдіктерге, банктік деректемелерге, төлем статусына, жолдарды өшіруге және қайтаруы қиын кез келген түзетуге қатысты. Адам үш нәрсені көруі керек: агент нені өзгерткісі келеді, деректі қайдан алғаны және қандай өрістер күмәнді болып қалғаны.

Ең қауіпті жазу жолдарын бөлек жауып тастаңыз:

• еркін SQL
• ақ тізімсіз еркін API шақырулары
• жол саны шектелмеген жаппай жаңартулар
• версиясы жоқ файлдарды жою және қайта жазу

Деректер базасына қауіпсіз қолжетімділік пен CRM-дегі әрекеттерді оқшаулау үшін агентке жалпы қолжетімділік емес, тар командалар берген дұрыс. «Кез келген жерге жаз» емес, «мәміле сомасын жаңарт», «пікірдің черновигін жаса», «тег қос». Сол кезде AI-агентке жазу құқықтарын тексеру, AI өзгерістерінің аудитін жасау және қатені тез қайтару оңайырақ болады.

Мысал: агент хаттан кейін CRM-ді жаңартады

Тексеру керек нәрсе - агенттің CRM-ге жаза алатыны емес, ол жерде қаншалықты аз өзгеріс жасай алатыны. Ең түсінікті сценарий: клиент тапсырыстың жеткізу мерзімін жылжытуды сұрайды. Агент хатты оқиды, бірақ мәмілені бірден өзгертпейді.

Алдымен ол керек карточканы екі белгі бойынша іздейді: хаттағы тапсырыс нөмірі және хат алмасу тақырыбы. Тек клиент атымен сәйкестендіру жеткіліксіз. Егер екі ұқсас мәміле табылса немесе нөмір сәйкес келмесе, тізбек тоқтайды да, хат адамға жіберіледі.

Келесі қадамда агент өзгерістердің черновигін дайындайды. Мысалы: жаңа жеткізу күні - 18 маусым, менеджерге тапсырма - «қоймадағы слотты нақтылап, клиентке жауаппен растау». Черновик тек жаңа мәндерді емес, негізін де көрсетеді: клиент ауыстыруды сұраған хаттың үзіндісі.

Менеджер мұны интерфейсте уже енгізілген өзгеріс емес, ұсыныс ретінде көреді. Ол әрекетті бір батырмамен растай алады немесе кері қайтара алады. Егер күн күмәнді көрінсе, оны қолмен түзетеді. Егер хат екіұшты болса, черновикті жазусыз жабады.

Расталғаннан кейін жүйе мәміленің тек екі рұқсат етілген өрісіне жазады:

• жоспарланған жеткізу күні
• менеджердің тапсырмасы

Мәміле сомасы, воронка кезеңі, жауапты адам, байланыстар және пікірлер агент үшін жабық болып қалады. Бұл қарапайым шектеу тәуекелді қатты азайтады. Модель хатты қате түсінсе де, мәмілені басқа кезеңге кездейсоқ ауыстыра алмайды немесе клиент деректерін өзгерте алмайды.

Тағы үш нәрсені қосу пайдалы: ескі және жаңа мәнді қатар көрсету, агент түзетуді ұсынған хаттың ID-сін сақтау және өзгерісті кім, қашан растағанын аудитке жазу.

Мұндай сценарийдің пайдасы бар. Менеджер мәмілені іздеп, датаны қолмен көшіруге уақыт жұмсамайды, ал бақылау адамның қолында қалады. Алғашқы пилот үшін әдетте осы жеткілікті: тар іздеу, бір черновик, нақты растау және тек алдын ала рұқсат етілген жерге жазу.

Командалар көбіне қай жерде қателеседі

Бірінші қате қарапайым: команда агентке барлық әрекетке бір токен береді. Сол токенмен ол клиент карточкаларын оқиды, CRM-дегі өрістерді өзгертеді, пікірлерді қосады және кейде тіпті экспортты іске қосады. Бірінші күні бұл ыңғайлы. Кейін ешкім қандай әрекетті кім жасағанын және артық жазуды қайдан тоқтату керегін түсінбейді. Токен сыртқа кетсе, мәселе бірден барлық аймаққа тарайды.

Екінші қате асығыстықтан шығады. Тез бастау үшін команда агентке бүкіл CRM-ді ашады, ал оған тек екі-үш өріс пен бір объектіге ғана қолжетімділік керек еді. Іс жүзінде агентке клиенттің толық профилін, сату тарихын және ішкі пікірлерді көру сирек қажет. Егер міндет «хаттан кейін лид статусын жаңарту» болса, CRM-ге толық қолжетімділік көмек емес, артық тәуекел.

Тест жағынан жағдай одан да нашар. Көбі жазуды бірден тірі деректе, көшірмесіз және бөлек контурсыз тексереді. Бір қате промпт, хатты талдаудағы бір ақау - агент ондаған жазбаны өзгертіп жібереді. Кейін команда оның нақты нені қозғағанын қолмен іздейді. Құмсалғыштың мәні де сол - алдымен сценарийді көшірмеде өткізу, қателерді көру, ережелерді түзету, содан кейін ғана жазуды продакшенге жіберу.

Тағы бір әлсіз жер - журнал жүргізу. Команда соңғы өзгерісті ғана сақтайды, бірақ агенттің бастапқы сұранысын және құралдың толық жауабын сақтамайды. Мұндай схема даулы жағдайды талдауға мүмкіндік бермейді. CRM-дегі өріс өзгергені көрінеді, бірақ агент неліктен дәл солай шешкені, қандай дерек алғаны және құрал не қайтарғаны байқалмайды.

Қауіпті сценарий көбіне шақырулар тізбегінде жасырынып жатады. Агентке лимитсіз және бөлек растаусыз екінші құралды шақыруға рұқсат беріледі. Мысалы, ол алдымен CRM-ді жаңартады, сосын өзі деректер базасына барып, басқа жүйеде тапсырма құрады және құжатты түзетеді. Бір сәтсіз қадам тағы бірнешеуін ілестіріп әкетеді.

Әдетте бес қатаң шектеу жеткілікті:

• әрекеттің әр түріне бөлек токен
• тек қажет өрістер мен объектілерге қолжетімділік
• деректер көшірмесіндегі тесттер
• сұраныс, жауап және өзгерістердің толық логы
• келесі құралдарды шақыруға лимит

Егер команда осы пункттердің біреуін болса да өткізіп алса, қателер сирек кішкентай болып қалады. Олар тек ұзақ уақыт байқалмай жатады.

Іске қоспас бұрынғы қысқа тексеру тізімі

Алғашқы іске қосуға дейін тек промптты емес, қолжетімділік шекараларын да тексеріңіз. Оқудағы қате әдетте шу ғана тудырады. Жазудағы қате нақты деректерді өзгертеді: мәміле статусын, соманы, мерзімді немесе құжат мәтінін.

Егер төмендегі кез келген пункт бойынша команда бес минуттан ұзақ таласса, агентке жазу құқықтарын беруге ерте. Алдымен дауды шешіңіз, сосын қолжетімділікті ашыңыз.

• Әр әрекеттің нақты иесі бар. Егер агент мәміле кезеңін өзгертсе, CRM-ге пікір жазса немесе деректер базасындағы жазбаны жаңартса, сол әрекетке жауап беретін және даулы жағдайды қарайтын адам болуы тиіс.
• Жазуға арналған өрістердің тізімі алдын ала жабық. Агент өз бетінше «импровизация» жасамауы керек. Тек схемаға кіргенін ғана рұқсат етіңіз: мысалы, «next_step» және «summary», бірақ жеңілдік, деректемелер немесе жауапты менеджер емес.
• Жаппай түзетулер бөлек сценариймен жүреді. Бір хаттан кейін бір карточканы жаңарту - басқа нәрсе. Ал кестедегі 10 000 жолды қайта жазу - мүлде басқа. Пакеттік операциялар үшін бөлек іске қосу, лимит және келісім керек.
• Қайтару минутпен өлшенеді. Команда өзгерістер журналы, snapshot немесе командалар кезегі арқылы бұрынғы мәндерді тез қайтара алуы тиіс. Егер қайтару бір күндік қолмен талдауды талап етсе, жүйе әлі дайын емес.
• Модель ауысса да, қолжетімділік ережелері өзгермейді. Бүгін агент бір модельмен, ертең басқасымен жұмыс істей алады, бірақ жазу құқықтары сол күйінде қалады. Бұл ережелер промпттан да, модельден де бөлек өмір сүруі керек.

Аудитті де бөлек тексеріңіз. Сіз әрекетті кім іске қосқанын, агент нақты нені өзгерткенін және оған қандай ереже рұқсат бергенін көруіңіз керек. Мұндай із болмаса, CRM-дегі әрекеттерді оқшаулау тез арада «бәлкім, бұны бот жасаған шығар» деген дауға айналады.

Жақсы тест қарапайым: пилоттан 20-30 нақты тапсырма беріп, процесті өзіңіз бұзуға тырысыңыз. Агенттен деректі қате өріске жазуын, жаппай түзету жасауын және бір әрекетті екі рет қайталауын сұраңыз. Егер жүйе сабырмен бас тартып, әрекетті журналға жазып, өзгерістерді тез қайтаруға мүмкіндік берсе, қолжетімділік жұмыс істеп тұр деген сөз.

Пилоттан кейін не істеу керек

Пилоттан кейін командада жиі артық батылдық пайда болады. Агент CRM-дегі бір жазбаны бір рет ұқыпты жаңартты да, бірден оған көбірек өріс, көбірек кесте және көбірек әрекет ашқың келеді. Бұл - жиі қате. Құқықтарды жүйеге деген сенім өсетін жылдамдықтан баяу кеңейткен дұрыс.

Бір жазу сценарийін және өте тар өрістер жиынтығын сақтап қалыңыз. Егер пилот тек мәміле статусын өзгертіп, клиент хатыннан кейін қысқа пікір қосқан болса, оған бірден мәміле иесін, соманы, тегтерді және байланысты контактілерді өзгертуге рұқсат бермеңіз. Жазу аймағы қаншалықты тар болса, агент қай жерде қателесетінін және салдарын кім түзететінін соғұрлым оңай түсінесіз.

Бірден команданың жалпы әсерін емес, құрғақ метрикаларды жинаңыз. Мына нәрселерді қараған пайдалы:

• қанша жазба қолмен растауға кетті
• қанша өзгерісті қайтаруға тура келді
• агент қай өрістерде жиі қателеседі
• даулы жағдайларды талдауға қанша уақыт кетеді
• агент қаншалықты жиі артық жазуға тырысады

Бұл сандар тез-ақ шындыққа қайтарады. Кейде модель сенімді жазады, бірақ әр оныншы жаңартуда қателеседі, ал CRM, клиенттер базасы немесе құжаттар үшін бұл қымбатқа түседі.

Бірдей ережелер жиынын екі-үш модельден өткізіп, бірдей кіріс деректеріндегі мінез-құлқын салыстырған пайдалы. Тек модельді ауыстырыңыз. Қолжетімділік саясатын, валидацияны, деректі маскалауды және аудитті өзгеріссіз қалдырыңыз. Сонда айырмашылық шынайы болады: қай модель жиірек растау сұрайды, қайсысы өрістерді шатастырады, қайсысы қайтаруға сирек әкеледі.

Егер команда airouter.kz сияқты AI Router бірыңғай шлюзін қолданса, модельдерді салыстыру одан да оңай. Сұраныстарды бағыттауды жазу саясатын өзгертпей-ақ ауыстыруға болады, бұл CRM мен деректер базасына артық тәуекелсіз модельдерді сынаудың ыңғайлы жолы.

Құқықтарды тек тыныш, сәтті іске қосулар сериясынан кейін ғана кеңейтіңіз. Әдетте бұл агент бірнеше апта қатарынан бір сценарийде қайтарулар, қолмен талдаулар және оғаш жазбалар өсімінсіз жұмыс істеді деген сөз. Содан кейін бір жаңа өріс немесе бір жаңа әрекет қосып, метрикаларды қайта қараңыз. Мұндай қарқын баяу сияқты көрінеді, бірақ ол тым жомарт құқықтардан кейінгі үлкен ақауды талдаудан көбіне жылдамырақ.