So a couple of points to this-
1.) NO_ADVERTISE is intended to prevent a given BGP speaker from propagating the route any further. So in this case adding this attribute to given route advertised to a peer will actually prevent the route from being pushed to the remainder of the carrier's network. You might want to consider NO_EXPORT, which is intended to restrict the propagation of a given prefix beyond a confederation (or an entire AS if confederations aren't in use). See RFC1997 for details on the behaviors of communities in general and well-known communities in particular.
2.) The well-known communities don't -have- to be honored but, in general, they are by default in most implementations (..unless you choose to explicitly strip these values). They tend to be all-or-nothing in nature, though - so, for example, signify that a given route can't propagate past the immediate peer router or past the peer router's ASN. In this case putting NO_EXPORT on a route would prevent BT from advertising to Cisco or Sprint, but would allow it to be present throughout any other routers inside the BT ASN.
3.) In this case the owners of the BT and Customer routers would have to agree upon a community value and its special meaning if you want the route to be selectively advertised (or not specifically not advertised) to a given upstream peer. Your carrier might also append communities indicating whether a given route is from one of their other direct customers or from an upstream transit (this is a handy way to pare down table sizes). Apart from the well-known values mentioned above everything else is potentially up for grabs and, also as mentioned, there's no standard guarantee (beyond what's negotiated with the carrier) of what behavior corresponds to what community. There's also no assurance that any carrier will preserve appended communities as prefixes cross their network.
So let's take a fairly simple example. On the BT router (let's call it ASN2856) we'll set up a filter on each of its peers to CUSTOMER (which we'll call ASN65400), Sprint (ASN1239) and Cisco (ASN109) such that only routes with xxx:ASN will be permitted. As such, if we put 65400:109 on the route but not 65400:1239 then the route will be allowed to Cisco but not Sprint. If both 65400:1239 and 65400:109 are appended to a prefix the route will go to both. If neither, then the route will stay inside ASN2856.
So on BT we'd have something like
ip community-list to-cisco permit .*:109
ip community-list to-sprint permit .*:1239
ip community-list to-customer permit .*:65400
route-map CISCO-PEER-OUT permit 10
match community to-cisco
set community none
route-map CISCO-PEER-OUT deny 20
route-map SPRINT-PEER-OUT permit 10
match community to-sprint
set community none
route-map SPRINT-PEER-OUT deny 20
route-map CUSTOMER-PEER-OUT permit 10
match community to-customer
set community none
route-map CUSTOMER-PEER-OUT deny 20
! Start the BGP section
neighbor 220.127.116.11 send-communities
neighbor 18.104.22.168 remote-as 109
neighbor 22.214.171.124 route-map CISCO-PEER-OUT out
neighbor 126.96.36.199 send-communities
neighbor 188.8.131.52 remote-as 1239
neighbor 184.108.40.206 route-map SPRINT-PEER-OUT out
neighbor 220.127.116.11 send-communities
neighbor 18.104.22.168 remote-as 65400
neighbor 22.214.171.124 route-map CUSTOMER-PEER-OUT out
On the CUSTOMER router you'd have something like this
ip prefix-list ROUTES-FOR-CISCO permit 192.168.1.0/24
route-map MARK-ROUTE permit 10
match ip address prefix-list ROUTES-FOR-CISCO
set community 65400:109
route-map MARK-ROUTE permit 20
set community 65400:109 65400:1239
neighbor 126.96.36.199 remote-as 2856
neighbor 188.8.131.52 send-community
neighbor 184.108.40.206 route-map MARK-ROUTE out
This would set the prefix 192.168.1.0/24 with a community of 65400:109, which would allow the route to be sent only to ASN109. All other routes would have both 65400:109 and 65400:1239 - which would allow said routes to go to either carrier. On the BT router I've also set it to clear all communities on routes sent to peers - so, for example, the CISCO peer wouldn't see the 65400:109 community you included.
In practice the communities probably wouldn't be structured quite like this, of course, but this should hopefully give you a taste of what's possible.
Hope this helps-