Not all together happy with how this post turned out, but I've learned things that I didn't know before, so that's good.
For example, normally if two nodes (A and B) are connected to a switch which is on the downstream side of another device like your firewall, the switch will route packets from A -> B and vise versa without contacting anything upstream (from @Tedwin).
I decided to post my own answer with the good parts from the comments with @Panther Modern.
Use higher quality hardware. Since I'm using Netgear ProSafe unmanaged switches, I'm considering upgrading to something like Cisco. @Mike Pennington suggested the SG300 series, which I have researched before and found on Amazon for less than $200. @Panther Modern suggests Arista, Cisco, Juniper and Brocade switches.
Troubleshoot each piece independently and isolate the problem. I've done some of this, to the extent that I have isolated the general path, but in an environment where 100% uptime makes people happy and allows them to get work done, this can be tricky. But point taken...
Consider topology and where you have access to and how many users you have. These factors can influence your choices for gear and how you go about answering your questions.
Find good networking tools and use those to help troubleshoot your issue. pfSense helped a lot concerning traffic that passed through the firewall. I also learned about Robocopy for limiting traffic on the client. This tool works pretty well.
Most business-grade, layer-2 switches support VLANs. You configure trunks to carry the multiple VLANs between switches and routers. How to do this, specifically, will depend on the switch model(s). VLAN tags are only used on trunks; frames on access ports are not tagged.
VLAN tagging really has nothing to do with IP QoS. Layer-2 frames have a COS, and layer-3 packets have a TOS, or DSCP. Different frames or packets with the same VLAN tag can have different QoS markings. As Daniel points out in the comment, the COS is only applied on frames with VLAN tags, but tagged frames only exist on trunks, not on access ports. Your switch(es) may support the minimal layer-2 QoS, and you would need to set the switch(es) up to apply COS markings and and queues on the switch(es), but this assumes your switches support layer-2 QoS, which is not normally very robust. Where you will really make a difference is with the layer-3 marking and router queuing based on those markings.
VoIP data traffic is typically set to EF
(Expedited Forwarding), but you aren't doing that. Also, VoIP control traffic, on the same VLAN, is usually marked differently. A VoIP phone will, by default, mark its packets correctly, and you only need to trust on the VoIP VLAN. Marking VoIP the same as network control information, 7
, is not usually a good thing.
One thing to really understand is that your QoS markings and policies are only good on your network. Unless you have an agreement in place with your ISP ($$$), your ISP will not honor your QoS markings and policies. Also, any other carriers through which your packets travel will not honor your QoS markings or policies, and will likely mark them all to BE (Best Effort). If your VoIP problems are on the Internet, you can try to fix what is on you network, but you will have no control of the packet treatment on the Internet.
Best Answer
The 2960 series is managed. Even the Netgear GS348 supports some QoS (its flavor of, check the documentation).
QoS prioritizes traffic - forward important frames, drop less important frames - when that becomes necessary due to link overload = congestion. If none of your links is supposed to handle more traffic then it is capable of, there's no congestion, and no real need for QoS.
So, if those switches where congestion is possible or most likely to happen support QoS features and are configured appropriately, you're basically good. Without deep insight into your network - topology, device configurations, (peak) workloads and flow patterns etc your question cannot be really answered.
Some do, many don't. Since you cannot configure their QoS features you have to make do with what's there. Some switches may support L2 priorities (priority code points from 802.1p/q), others may support differential services (DSCP) from the L3 IP packets.
You need to make sure that upstream, managed switches set/use the QoS flags that the downstream, unmanaged switches require. Since that can get very hard it's easiest to use managed switches with a common logic (mostly from the same vendor/series).