Сергей П

Вы не тот telebot поставили. Там в pypi какой-то адище творится с одноимёнными модулями.
Убедитесь, что ставится нужная библиотека:

> pip show telebot                                                        
Name: telebot
Version: 0.0.3
Summary: A Telegram bot library, with simple route decorators.
Home-page: https://github.com/KyleJamesWalker/telebot
Author: Kyle James Walker
Author-email: KyleJamesWalker@gmail.com
License: MIT
Location: /home/svp/.local/lib/python3.6/site-packages
Requires: requests
Required-by: 
Note: you may need to restart the kernel to use updated packages.

Попробуйте ставить так:

pip install git+https://github.com/KyleJamesWalker/telebot

Или где-то лежит такой файл telebot.py и импортируется локально.

Во-первых нужно, чтобы телеграм-бот знал кто у него есть кто. То есть знал идентификаторы менеджеров и мог отличать их от пользователей.
Во-вторых, менеджер разговаривает с ботом точно так же, как и пользователь, но пользователь пишет боту и получает от него ответы менеджера, а менеджер пишет боту и получает от него реплики пользователя. Проблема в том, что пользователей много, а бот один или несколько. Вот тут и появляется возможность по-разному решить эту задачу со своими плюсами и минусами.

Вы обмолвились, что хотите, чтобы все менеджеры имели доступ к диалогам других менеджеров с пользователями.
Это проблема, у которой нет 100% элегантного решения. Тут вам бы следовало подетальнее расписать ТЗ, но пока его нет я опишу лишь несколько возможностей.

Бот может цитировать все диалоги в общий канал или группу, чтобы там была возможность их просмотра всеми менеджерами. Отвечать также можно прямо в группу с цитированием того, кому предназначается ответ. Бот увидев такое сообщение перешлёт его в своём личном диалоге с пользователем. Процитированные реплики пользователя можно тегировать для фильтрации диалога с конкретным пользователем.

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

Тут много вариантов. Детализируйте ТЗ.

Чтобы вы понимали, в общем простом случае бот - это виртуальный пользователь, на события вокруг которого реагирует программа. Бот может быть добавлен в группу или личный чат с человеком.

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

Программа, управляющая ботом, имеет возможность хранить своё состояние в БД или памяти. Так она может "знать" о всех диалогах.

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

В сложном случае можно сделать, чтобы не одна а несколько инстансов прорграммы работало от имени одного бота. Тогда придётся подключать их к общей БД, чтобы они (инстансы) могли синхронизировать своё состояние при необходимости.

Одна программа может управлять сразу несколькими ботами. Это значит, что боты как бы могут "знать" информацию и состояния друг-друга. Тут можно как угодно запрограммировать.

1. Вынесите строку `temp/` в отдельную переменную.
   
2. Проверяйте при старте бота этот путь на существование.
   
3. Если такого пути нет, можно его либо создать, либо выдать соответствующее сообщение об ошибке и завершить работу.
   

Если путь без "/" вначале , то это относительный путь от текущего на момент запуска скрипта.
Если бот лежит по пути: `/home/my_username/my_bot_folder/my_bot.py`
И запускается так:
`my_bot_folder/my_bot.py`
То текущий каталог на момент запуска у вас домашний:
`/home/my_username`
И бот будет пытаться писать картинки по пути типа:
`/home/my_username/temp/2345435666hashtralala.png`.
Если у вас в домашнем каталоге нет папки temp, то будет эта ошибка.
Нужно создать папку temp в нужном месте.
Можно обработать эту ошибку и в ее обработчике написать `print('please make temp folder in:', os.getcwd())`

Разглашать такие ограничения - это было бы стратегической ошибкой со стороны Дурова по ряду причин:

1. Пока объёмы не создают проблем и укладываются в существующие мощности, создать иллюзию безлимитного изобилия дискового пространства - это хороший PR ход подогревающий интерес к мессенджеру.
   
2. Как только лимиты будут четко очерчены, сразу появятся желающие их "пощупать". Таких желающих будет много, и они начнут ныть, когда лимиты придётся урезать из-за этого. Всякие любители нецелевого использования халявы узнав про конкретные лимиты станут плодить и заливать под завязку аккаунты для хранения своего барахла. Очевидно. что от таких паразитов Телеграму только вред, а ныть они будут на весь инет жалуясь, что либо лимиты постоянно урезают и "чего нам теперь ждать дальше", либо что этих паразитов банят за не целевое использование сервиса, а они "просто хотели другу архивы с лабами переслать". Ага.
   
3. В лицензии наверняка (я правда не читал, ибо лень) написано, что телегу можно юзать как можно и нельзя как нельзя. Но банить за такое нужно только самых упоротых и по лотерее, чтобы нельзя было вычислить строгий алгоритм и делать всё, чтобы брать максимум халявы, но не попадаться на бан.
   

Я понимаю, что вопрос вы задаёте с другой стороны окопа. Я понимаю вашу мотивацию.
Однако если бы я разрабатывал похожую систему, то постарался бы:

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

Мы решили вопрос доступа к API телеграма так.
Стандартный домен API телеги для ботов заблочен роскопозором, поэтому в конфиге нашего бота подменён домен для доступа к АПИ.
Наш же VDS за пределами юрисдикции роскомпозора в конфиге nginx имел такую вот запись:

server {
    listen tg.my_own_domain.ru:8079;
    server_name tg.my_own_domain.ru;
    access_log /var/log/nginx/tg.my_own_domain.ru-access.log;
    error_log /var/log/nginx/tg.my_own_domain.ru-error.log;
    location / {
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Server $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_pass https://api.telegram.org/;
        client_max_body_size 100M;
    }
}

Начинайте уже пользоваться современными удобными библиотеками для работы с путями:

from pathlib import Path
my_folder_path = Path('/home/pi/Desktop/bot2.0/photo')
my_file_path = my_folder_path / 'my_file_name.ext'
print(f'Для ясности можно залогировать путь по которому сохраняем: {my_file_path}')
my_file_path.write_bytes(downloaded_file)

Всё зависит от того, какие задачи будут у вашего бота, какая будет у него архитектура, насколько сложные модели данных, собираетесь ли использовать ORM и какой именно.
А может быть вам реляционная структура БД и вовсе не нужна и больше подойдёт NoSQL база данных.
там их великое множество с разными возможностями и ограничениями от простых хранилищ ключ-значение, до развесистых и навороченных.

Я бы порекомендовал MongoDB.
Для питона есть огромное количество примеров и тьюториалов типа такого. Куда уж понятнее.

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

Вообще не очень понятна мотивация вашего вопроса. Сейчас полно простых доступных материалов по этой теме, в том числе на русском языке. А как выбрать какую БД использовать я вам уже описал. Для более детального совета не хватает информации о то, чем будет заниматься ваш бот.

P.S.
Прошу прощения за капитанские ссылки в тексте, но каков вопрос, таков и ответ.

P.P.S.
Должен признать, что я довольно предвзят в пользу монги. Скорее всего вам подойдёт всё что угодно.
Меньше всего потребует настройки и знания, видимо, sqlite. Это embedded база данных, она заточена для простого использования. Однако если вам вдруг понадобится запускать несколько инстансов вашего бота, которые будут работать с одной БД, то посмотрите всё же в сторону MongoDB или Postgres. Mysql стал сдавать позиции и нет особых причин не использовать postgres, если вам нужна именно реляционная БД.