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

CMS это как из пушки по воробьям, сделать можно, но целесообразнее использовать легковесный фреймворк.

Собственно тут пути 2:

1) делать чисто фронт энд + бэк на 1С
2) фронт + бэк на языке Х <--синхроинзация--> 1С

Относительно первого, достаточно всего навсего сделать фронтэнд и использовать oData из 1С, при этом в 1С кодить не придется вообще (ну или написать самому http серсвис, тогда конечно придется).
Это быстрее в плане разработке, при грамотном подходе и работать будет очень быстро, если пойти SPA путем например, главное, что нужно знать помимо 1С это JS (причем желательно хорошо) + еще фреймворк типа react \ angular, можно конечно заюзать проект metadata.js, это JS фреймворк для работы через oData с 1С, выложен тут на инфостарте.

Минусы данного подхода: необходимость в постоянной работе самого сервера 1С (причем 1С очень желательно именно клиент + серверный вариант), 1С глушится = все перестает работать. Так же нужно думать как организовать авторизацию, либо убрать авторизацию HTTP сервисов и сделать свою, например на JWT, либо оставить стандартную, но при этом придется выпиливать 401 ошибку, если не хочется видеть дополнительно окна логина, которое браузеры выкидывает при получении 401 ошибки + если не использовать HTTPS (хотя это уже must have вообще) при стандартной basic авторизации, это еще и небезопасно.

Второй вариант имеет больше "+" в плане отказоустойчивсти, можно взять тот же PHP в виде Laravel \ Lumen фреймворков запустить его на любом хостинге, где доступность серверов обычно высока и синхронизировать данные с базой 1С, в данном случае, даже если 1Ску заглушили, то заявка например все равно попадет в базу когда 1С поднимется. Синхронизацию можно сделать на базе той же oData, если логика будет очень проста. Авторизацию можно сделать на базе фреймворка, т.е. 1С вообще не будет знать о логинах \ паролях \ токенах клиентов, а в 1С можно ходить под одной учеткой + идентификатор контрагента передавать при запросах.

Минусы более долгий цикл разработки, т.к. придется присать фронт + бэк + синхронизацию. Возможно будут проблемы с синхронизацией переодически (еще не разу не видел идеальной работы систем синхронизации)

В обоих случаях минимум: это знания JS на уровне мидл разработчика, архитектуры MVC и, опционально, языка для бэка если 2 способом пойдете (тот же PHP например).

Участвовал в разработке сервисов на базе обоих способов, по душе был 1й вариант, т.к. изменений во втором, в случае их необходимости приходится делать как в 1С так и на бэке, но у нас был отказоустойчивый кластер + nginx, в итоге стоит 2 сервера у заказчика, которые в свою очередь географически разпределены в пределах города + облачный сервер где хостится nginx, это довольно большие вложения были для обеспечения большого аптайма + поели г... в плане фоновых обновлений ИБ, чтобы на долго не оставлять базу в нерабочем состоянии. Если апйтайм не сильно критичен даже на 1ч можно по идее юзать всего 1 сервер.