Hola, genial... tienes la rueda del ferrary, ahora te falta el chasis, motor, pintura, caja, etc.

Un sistema PQR necesita muchas secciones y muchos datos, tablas, etc, lo primero que debes hacer es crear un flijo de uso y en base a eso crear la db, por ejemplo.. ingresa el admin, que administra? puede administrar usuarios, tickets, debes administrar zonas horarias, correos de envio, sincronizaciones, etc.

Haz un ezquema sobre la navegación del usuario, que cosas debe poder ver y/o administrar, luego de eso haz las tablas en un modelo ERM, puedes usar mysql workbench, es muy facil usarlo o si no hazlo en papel, luego que tengas la idea lista haz las tablas y las columnas.

De todas maneras te doy algunas pistas:

Necesitas administrar usuarios asi que necesitas una tabla de usuarios
No todos los usuarios hacen lo mismo asi que necesitas grupos de usuarios
Cada grupo necesita permisos específicos, ahora... esos permisos serán fijos o dinamicos? esto quiere decir,,, el administrador puede crear un nuevo grupo con nuevos permisos?
En ese caso necesitas una tabla de usuarios, tabla de grupos de usuarios, tabla de permisos, tabla relacion de usuarios y grupos, tabla relacion de permisos y grupos, de esta manera un mismo usuario puede tener dos grupos simultaneamente, puede ser moderador y usuario final y hacer ambas cosas.

Los temas pueden ser reclamo, queja o sugerencia, será una sola? puede ser mas de un tipo? depende de eso si la tabla del tema tendrá una columna de tipo con una relacion de "mensaje y tipo" o una tabla intermedia relacional entre el mensaje y el tipo de muchos a muchos.

Ahora, esto se parece a un tracker, esto quiere decir que debe tener asignaciones, alguien debe tomar y responder esos tickets, esto quiere decir que debe existir una tabla de relaciones entre el tema y usuarios participantes de los cuales se dividen en dos: adjuntos (cc) y asignados, esto quiere decir que en un ticket una o dos personas pueden ser asignadas para resolver la incidencia pero pueden estar copiados uno o mas personas que pueden tener la misma petición y para que alguien pueda estar copiado y tener la misma petición el usuario primero debe saber que ya existe una petición similar, por lo cual debe existir un buscador.

Fuera de esto vas a hacer proyecciones o reportes de uso? por ejemplo, cuantos usuarios están esperando sin una respuesta, cuantos tickets están sin asignar, cuantos tickets fueron finalizados en el mes, cual es el % de finalización mensual, el usuario asignado debiera tener un contador de temas asignados y terminados?

Por otro lado los usuarios asignados y copiados deben poder ver el historial de sus tickets, deben poder ver que ticket les falta por responder o si alguien les respondió su respuesta, para eso debes crear una tabla de movimientos e historial asociado a los usuarios.

Por otro lado debes considerar si tu db será relacional o no, si será normalizada o no, por ejemplo si vas a tener muchos tickets debes crear una tabla desnormalizada o si no vas a tener problemas cuando llegues a un limite de mensajes, especialmente en el buscador, debieras tener una tabla con valores duplicados desnormalizados para que cuando alguien haga una búsqueda no se cuelgue la aplicación para todos los demás.

Recuerda tener mucho cuidado con la codificación de caracteres, crear índices, llaves foreanas, si la modificación va a causar un efecto en cascada o no, si no defines bien eso podrás tener tablas corruptas ya que tendrás relaciones con un id no existente.

Por otro lado te recomiendo no hacer procedimientos almacenados, eso es una muy mala práctica, la basde de datos es base de datos, no es capa de negocio, todos los calculos se realizan por código y no a traves del motor de la base de datos o si no cuando crezca se te va a caer muy rápido ya que tendrás las cargas de las consultas y de los procedimientos y vas a necesitar mucho hardware y gastar mucho dinero, en ves de eso la base de datos debe comportarse solo como base de datos y la aplicación debe contar con su capa de negocios (la lógica de la app) donde haga todos los calculos sobre que tipo de consultas realizar a la db, de esa manera si la logica crece en uso de cpu podrás tener la capa de presentación o negocio con un balanceador de carga con sitios replicados y una sola base de datos, en cambio si llevas todo a la base de datos no tendras otra que replicar la base de datos en varios servidores que terminarán costandote mucho mas y será mas dificil de administrar, necesitarás mas personal encargado de la db y será todo un desastre, y peor aun si quiere hacer un solo procedimiento almacenado, eso no se hace, es como andar en bicicleta con las ruedas del juguete de mi hijo de 1 dolar.

Espero que esto te de algunas luces sobre lo que debes tener en cuenta antes de hacer tu db.

Saludos.