Бутон "Откажете се от договора тук": как да го реализирате правилно в онлайн магазин

Бутонът е видимата част на процеса. Зад него трябва да има запис на заявката, автоматично уведомяване, административен модул и проследима обработка. Ако магазинът само изпраща съобщение до обща пощенска кутия, екипът трудно ще установи кои случаи са обработени и кои са останали без действие.

Основният въпрос при разработката е как да се осигури лесно подаване за клиента и надеждна работа за търговеца.

Какво изисква законът и от кога важи в България?

Чл. 52а от Закона за защита на потребителите въвежда онлайн функция за отказ. Той е създаден с § 7 от изменението, обнародвано в ДВ, бр. 87 от 24 септември 2026 г., и влиза в сила на тази дата по § 83. Изискват се видим и леснодостъпен вход, възможност за изявление и отделно недвусмислено потвърждаване. Официалният текст в Държавен вестник.

Европейската основа е Директива (ЕС) 2023/2673, която добавя чл. 11а в Директива 2011/83/ЕС и предвижда прилагане от 19 юни 2026 г. Европейската и българската дата трябва да се разграничават.

Техническата реализация трябва да следва приложимите правила за конкретните договори. Функцията не създава право на отказ за всяка покупка. Например законовите изключения за някои персонализирани стоки и услуги изискват отделна преценка. Your Europe: право на отказ и изключения.

Каква е разликата между получен отказ и административна проверка?

Подаването на изявление и вътрешната му обработка са отделни събития. Администрацията служи за установяване на фактите и организиране на действията; валидното упражняване на правото на отказ не се поставя в зависимост от свободното одобрение на служител.

Този характер на правото е обяснен и в ръководството на „Активни потребители“: то се упражнява с едностранно изявление и не се предоставя по волята на търговеца.

За системата това означава три отделни записа:

• кога клиентът е подал изявлението;
• кога и как е изпратено потвърждението за получаване;
• как е проверен и обработен конкретният случай.

Потвърждението за получаване не трябва да чака служител да отвори поръчката. Също така автоматичният имейл не трябва да твърди, че сумата вече е възстановена или че всички последващи действия са приключили.

Защо формата не трябва да търси само „активни поръчки“?

Статусът на поръчката в магазина не е достатъчен критерий за достъп до формата за отказ. Доставена поръчка може да е отбелязана като приключена, а данните за по-стара покупка може да са в друга система.

При реална работа възникват и други ситуации:

• клиентът е поръчал като гост;
• въвел е номер на фактура вместо номер на поръчка;
• добавил е префикс или е допуснал печатна грешка;
• магазинът е мигриран и номерата са променени;
• ERP системата временно не отговаря.

Препоръчителната архитектура приема изявлението като самостоятелен запис. След това опитва съпоставяне с поръчката. При липса на съответствие записът остава с обозначение „Нужда от уточнение“, вместо да се губи.

Публичната форма проверява дали необходимите полета са попълнени и имейлът е в допустим формат. Тя не трябва да отговаря „нямате активна поръчка“ като условие за подаване. Данни за чужда поръчка не се показват при въвеждане на произволен номер.

Как трябва да изглежда формата за клиента?

Добрата форма събира достатъчно информация за изявлението и последващата комуникация, без излишни задължителни полета. Следният вариант е практическо предложение за реализация:

Имейлът е необходим за избрания тук начин на потвърждение. Само име, фамилия и номер на поръчка не са достатъчни за него, когато автоматичното съпоставяне може да е неуспешно.

При неизвестен номер формата трябва да допуска други достатъчни данни за договора. Не бива да изисква измислен номер, за да позволи продължаване. Полето не трябва да бъде ограничено само до цифри, ако магазинът използва букви, тирета или префикси.

Причина за отказ, снимка, телефон и банкова сметка не се добавят автоматично като задължителни условия за подаване. Нужните уточнения за последващите действия могат да се съберат отделно. За частичен отказ може да има свободно описание на артикули, без публично извличане на непроверени поръчки.

Две ясни действия

Първият вход е „Откажете се от договора тук“ и отваря формата. След попълване клиентът вижда какво подава и завършва с „Потвърждавам отказа“.

Предварителният преглед може да бъде в същия екран. Не е необходим дълъг процес с анкети или задължителна регистрация. За вече идентифициран клиент данните могат да се попълнят предварително, с възможност за проверка и корекция.

Формата трябва да работи за покупки като гост, на телефон и с клавиатура. Достъпът до нея не трябва да зависи от приемане на маркетингови бисквитки.

Какво трябва да се случи след потвърждаване?

Системата първо запазва изявлението и задачата за изпращане на имейл, а след това започва вътрешното съпоставяне. Това е препоръчителен модел за надеждна реализация.

1. Проверява минималната пълнота на подадените данни.
2. Създава уникален номер на заявката и записва сървърна дата и час.
3. Запазва съдържанието на изявлението и адреса за потвърждение.
4. В същата операция създава задача за автоматичен имейл.
5. Показва потвърждение на екрана с номера на записаната заявка.
6. Изпраща потвърждението и следи резултата.
7. Съпоставя данните с поръчките и уведомява отговорния екип.

Записът не трябва да чака ERP или куриерска система. Връзката към вътрешната поръчка може да остане празна до проверката. Въведеният от клиента номер и вътрешният идентификатор са различни полета.

Часът се регистрира при получаване на окончателното потвърждение в сървъра, а не при по-късната обработка от фонов процес. Показва се с ясна часова зона и се запазва при повторно изпращане на същата техническа заявка.

При грешка в записването не се показва фалшиво „успешно изпратено“. Клиентът получава ясно съобщение и достъп до обявените алтернативни начини за контакт.

Какво трябва да съдържа автоматичният имейл?

Имейлът трябва да потвърждава получаването и да възпроизвежда подаденото изявление, с дата и час. Българският чл. 52а, ал. 5 предвижда изпращане на траен носител без неоправдано забавяне, не по-късно от края на работния ден. Източник: Държавен вестник.

За този поток най-практичният вариант е автоматичен имейл непосредствено след надеждния запис. Съобщението на екрана допълва имейла, но не го заменя. Линк към съдържание, което може да бъде променяно, не е достатъчен заместител на самото изявление в съобщението.

Примерен шаблон:

Тема: Получено изявление за отказ — заявка {{REQUEST_REFERENCE}}

Получихме Вашето изявление за отказ на {{SUBMITTED_AT_WITH_TIMEZONE}}.

Посочено име: {{CUSTOMER_NAME}}

Посочен номер на поръчка/договор: {{CONTRACT_REFERENCE}}

Съдържание на изявлението: {{DECLARATION_TEXT}}

Номер на регистрираната заявка: {{REQUEST_REFERENCE}}

Допълнителната комуникация по обработката ще бъде свързана с този номер. За контакт: {{MERCHANT_CONTACT}}.

Данните в шаблона се попълват от подаденото изявление. До проверка на самоличността имейлът не включва извлечени адреси, стойности, артикули или документи от намерена по номер чужда поръчка.

При забавен или неуспешен имейл заявката остава записана. Изпращането се повтаря контролирано, а екипът получава сигнал за проблем. Датата на изявлението не се заменя с датата на повторния имейл.

Как трябва да работи административният модул?

Администрацията трябва да дава общ преглед на изявленията и доказуема история на обработката. Препоръчителните оперативни състояния са:

Тези състояния организират работата. Те не променят момента, в който потребителят е подал изявлението.

Статусът на имейла е отделен: чака изпращане, изпратен или неуспешен. Така заявка „Получено“ може едновременно да има проблем с доставката на потвърждението.

Служителят трябва да вижда първоначалните данни, намерените съответствия, проверката на самоличността, датите на доставка и историята на комуникацията. При свързване с поръчка се пазят авторът, моментът и основанието на действието. Оригиналното изявление остава непроменено.

Как се проверяват поръчката и срокът?

Проверката трябва да използва фактическите данни за договора и доставката, а не само датата на поръчване. При обичайните онлайн покупки на стоки 14-дневният срок по правило е свързан с получаването; за услугите началният момент е различен. Официално разяснение на Your Europe.

За административния процес това означава проверка на:

• съответствието между подателя и договора;
• момента на получаване на стоката или приложимото начално събитие;
• разделени доставки и липсващи данни;
• приложимостта на правото на отказ за конкретния предмет;
• предоставената информация за отказ и възможни особености на срока;
• датата и часа на подаденото изявление.

Софтуерът може да показва предварителна индикация. При неизвестна дата или спорен случай показва „Нужда от проверка“, вместо автоматичен отрицателен отговор. Правилата за сроковете и изключенията се съгласуват с юрист според продажбите на търговеца.

След проверката системата може да изпрати инструкции за връщане, конкретно искане за уточнение или мотивиран отговор. Искането за уточнение не трябва да представя вече полученото изявление като неподадено. Самото изпращане на потвърждение не бива да отключва без проверка възстановяване на пари или разкриване на клиентски данни.

Как се предотвратяват дублиране и злоупотреби?

Защитата трябва да запазва достъпността на формата и да отделя получаването на изявление от действията по поръчката. Необходимите технически мерки включват защитена връзка, проверка на входа и ограничени административни права.

При двойно натискане една и съща техническа заявка трябва да връща същия регистрационен номер. За целта може да се използва уникален ключ на изпращането. Дедупликация само по номер на поръчка е неподходяща: клиентът може да изпрати ново изявление или уточнение.

Публичният отговор не разкрива дали съществува чужда поръчка. Антиспам мерките трябва да са съразмерни и достъпни, без задължително създаване на профил или имейл верификация като допълнителна стъпка за завършване на отказа.

За данните се определят срокове за съхранение и разрешени потребители. Техническите логове не трябва ненужно да копират цялата лична информация.

Как се проверява функционалността преди пускане?

Приемателните тестове трябва да проверяват целия процес, включително отказите на външни услуги. Минималните сценарии са:

• покупка като гост и заявка от телефон;
• приключена поръчка и липсващо съответствие по номер;
• данни за договор без известен номер на поръчка;
• двойно натискане и повторно изпращане след мрежов проблем;
• временно недостъпна ERP система;
• неуспешен имейл с повторно изпращане и известие;
• подадено изявление близо до края на срока;
• опит за достъп до чужда поръчка;
• запазване на оригиналното съдържание след административна корекция.

Успешният резултат означава надежден запис, правилен час, потвърждение с действителното съдържание и видимост за отговорния служител. Изпратен имейл без запис в администрацията не е достатъчен критерий.

Често задавани въпроси

Достатъчен ли е PDF формуляр във футъра?

Не за описаната интерактивна функция. Файлът не осигурява онлайн подаване, отделно потвърждаване и автоматично удостоверяване на полученото изявление. Може да остане като допълнителен ресурс.

Трябва ли да се откаже заявка при грешен номер?

В предложения модел изявлението се запазва и влиза за уточнение. Формата не разкрива данни за поръчки и не променя чужди записи. Съпоставянето се извършва във вътрешния процес.

Може ли да се изпраща само имейл след проверката?

Потвърждението за получаване е отделно от последващия отговор. Реализацията трябва да изпрати първото своевременно, а второто — според необходимите фактически действия.

Трябва ли формата автоматично да анулира поръчката?

Получаването на изявление не трябва да води до непроверени финансови или складови промени. Когато са установени договорът, подателят и приложимите правила, могат да се автоматизират разрешени операции, например спиране на изпълнението или създаване на задача за връщане.

Как Sirius Software може да реализира този процес?

Sirius Software (Сириус Софтуер) може да разработи функцията като част от онлайн магазина и неговите административни процеси. Решението може да включва публична форма, надежден регистър, автоматични имейли, административен модул и интеграции с поръчки, CRM, ERP и куриери.

При анализа се уточняват платформата, покупките като гост, номерацията, наличните данни за доставки, правата на служителите и последващите действия. Разработката следва съгласуваните правни правила и включва тестове, наблюдение и проследимост.

Бюджетът зависи от текущия магазин, наличната администрация и необходимите връзки. Формата с регистър и имейли има различен обхват от процес с частични връщания, платежни операции и складови документи.

Изпратете запитване за разработка на функция за отказ от договор. Посочете адреса и платформата на магазина, как обработвате отказите в момента и кои действия искате да се автоматизират. Ще обсъдим подходяща реализация и обхват за оценка.

Повече за свързаните възможности: софтуерна разработка и ERP интеграции и подготовка на техническо задание.

За автора

Автор: Георги Папучаров, основател на Sirius Software. Статията представя технически модел за онлайн магазин. Приложимите срокове, изключения и клиентски текстове се съгласуват според конкретните договори.