Dave, there's two angles to this:
From a "Cisco Bigot" approach (my preferred approach) you tell them we need Cisco end-to-end to be supported. No one wants a telephone system that is only half-supported, and no one wants to deal with fingerpointing if jitter is leading to crappy calls.
However, from a technical perspective, let's review where we're at. Here's your biggest hurdles:
1. Customer claims Alcatel "supports QoS"; you need to understand exactly what this means? For example, Cisco's Catalyst 4000 Supervisor II "supports QoS", but that doesn't mean it's suddenly not a flaming pile of dog poo (and thank God, finally EOS). Does the Alcatel equipment simply provide a priority queue based on COS/DSCP? Or can it re-write COS/DSCP? Based on what information? Can it rewrite DSCP/COS based on VLAN? The answers to these questions might alter your QoS approach.
2. You lose inline power. [see note below]
3. In going with Alcatel, you lose any magical agreements between the phone and the switch; this includes Voice VLAN negotiation, and the switch telling the phone to rewrite COS on frames coming from PC port. This is your biggest obstacle from a QoS point of view.
Now, some workarounds:
1. You could configure every phone port as a dot1q trunk, and manually configure the phone to use a certain Voice VLAN. A whole lot of work, but it IS possible.
2. You could use Cisco Catalyst Inline Power Patch Panels, although I've never actually touched one of these or seen them in the field. Typically the price is so close to just buying a new Catalyst 3560 that people end up going that route.
3. Depending on what the Alcatel can or cannot do, you may be able to work around the "can't tell the phone to rewrite the PC Port frames" problem. Maybe the Alcatel can automatically rewrite DSCP/COS on packets/frames coming in on the native VLAN (untagged data VLAN), while leaving DSCP/COS on packets/frames coming in on the Voice VLAN alone.
In my experience, LANs are typically not overcongested. The QoS on the LAN is not important day-to-day, it becomes important when Microsoft's "worm of the week" has every infected host spewing data on the network-- then suddenly LAN QOS is a "gotta have". Going from memory, I think Nachia or Welchia was one of these types of worms. This comment applies more to small/medium business LANs, not necessarily large companies or "campuses" as you reference above.
Lastly, the tricky part is that unless you have Alcatel expertise, you need to rely on both the answers the customer gives to the above and assuming thye move forward you need to rely on the configuration work performed by your customer. As you menion, that's a tricky place to be in. If your customer is not an expert at Alcatel QOS and does not do a good job onfiguring their side, the crappy voice quality is going to be blamed on Cisco. This is a fine line to walk; you don't want to spend the back-end of a deployment pointing fingers between the vendor and the customer, and you certainly can't just walk away from an install saying "we did our job, good luck fixing your LAN QOS".
Technically, what you want to do is possible but it will require an expert understanding of the Alcatel's capabilities, an expert understanding of how all this technology pieces together, and a good SOW outling who is responsible for which pieces of the project -- and pre-determined actions if certain things (such as jitter leading to poor voice quality) are encountered.
Good luck.
