Итак. Есть БД, WCF - служба и клиентское приложение, пока одно. Это клиентское приложение, для удаленных клиентов, его  возможности таковы, что пользователь может все просматривать и оставлять свои приложения. Т.е. приложение из записи делает только регистрацию пользователч, смена его данных и занесение предложений. Все остальное только на просмотр. Пока еще не отработан вопрос о методах авторизации и аутентификации. Назовем этот клиент - клиент пользователец
Следующий этап - разработка приложения для менеджеров, это также удаленный клиент, но его полномочия намного шире - не толкьо просмотр, но у идаление полльзователей, удаление и правка предложений пользователя, занесение данных в БД, их правка и удаление. Назовем этот клиент - клиент менеджеров.
Вопрос стоит так -  Можно сделать так, что этот клтиент будет также подсоединяться к той же службе, что  клиент пользователей, и наполнить эту службу методами для работы именно этого клиента. Соответсвенно надо будет решать вопрос ограничения доступа рядовых пользователей к этим метода, что в принципе решаемо. Но ведь можно сделать иначе. Для клиента менеджеров создать отдельную службу и наполнить ее этими методами.
У каждого метода свои плюсы и минусы, вот какие вижу я
Если выбрать второй метод, то решение вопроса безопасности становится менее трудоемким, не пидется прописывать какой метод для кого. Пользователи не будут догадываться о надичии службы, через которую можно сделать что-то большее и т.п.
Минус, что придется обслужтивать две службы при одной базе. Т.е. определнные изменения в базе могут застваить вносить изменения двух службах. Ну и еще один, что двум службам, в случае необходимости зщнания об изменениях чего-то придется взаимодействовать между собой.
Второй метод не имеет плюсов первого, но возможно в некоторых случаях (не факт, что во всех) получится снизить число изменений в службе при изменении БД. При этом плюс еще в том, что служба целиком будет владеть информацией о том, что изменилось в БД, а что нет. Она одна работает с базой. Это может пригодится в том случае, если, допустим, я захочу уменьшить число запросов к БД и некоторые данные хранить в массивах службы. Соответсвенно пользователям эти данные будут выдваваться из этих массивов, а запрос к БД будет осуществляться толко тогда, когда произошли изменения. Понятное дело, что это должен быть небольшой объем данных (иначе зхзачем СУБД) и они должны менять не так часто. Такие данные есть, но их не так много. В случае реализации двух раздельных служб, такую возможность можно реализовать таким образом, что оджна служба буджет оповещать другую об изменениях и заставлять ее произвести обносление данных. в принципе не вижу в этом криминала. 
Хотелшось бы услышать ваше мнение. 

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

а скрыть функционал одной роли от другой можно, разнеся методы клиентов и манагеров на два интерфейса и, соответственно, два энд-пойта. при таком варианте можно будет даже прикрутить интерфейсам разную систему безопасности (через разные binding'и и behavior'ы)