At some point in every company party a guest walks up to the booth with a phone in their hand. What happens next is a policy decision, and the person who should make it is the client, not the DJ and not the guest. Most clients have never been asked. This post lays out the three workable policies, how a request gets handled in the moment under each one, and the three specific requests that come up at almost every corporate event: the one that breaks the tone, the one from the CEO, and the one from somebody who has had too much to drink.
Three policies, and the client picks one
Requests are not good or bad in themselves. They are information about the room, delivered one person at a time, and whether that information should change the set is up to whoever is paying for it. We ask on the planning call. These are the options.
Yes. Requests are welcome and the DJ works them in where they fit. This suits a smaller company party, a team outing, or any event where the point is that people feel it is theirs. The DJ still filters for the do-not-play list, the clean-edit default, and tone; "yes" means yes to the room's taste, not to every song ever recorded.
No. Requests are declined, politely, with the DJ explaining that the music has been set by the company for the evening. This suits a gala, a client-facing event, a launch, or any event with a tight program and a run of show, where a guest's request could push a timed cue or take the room somewhere the host does not want it. It also suits a client who has spent real effort on a please-play list and does not want it overridden by whoever is standing nearest the booth at 10:40.
With rules. The most common choice and usually the right one. Requests are taken but with limits the client sets in advance. The rules that work in practice: requests go into a queue rather than being played next; anything on the do-not-play list is declined regardless of who asks; requests that break the tone are checked with the client's contact before playing; requests stop at a fixed time before the end so the last twenty minutes are the DJ's; and one named person at the company can override any of the above. That last rule is the one that matters, because it settles the question of whose party it is.
Whatever the policy, guests are told the same thing at the booth: a thank you, a note of the song, and no promise about when or whether it plays. A DJ who promises "next one" to every guest has handed the set to the queue.
The request that breaks the tone
This is the request that passes every filter on paper and still should not be played: a song that is technically clean, not on any list, and wrong for this room at this moment. Sometimes it is a song whose subject is a problem, covered in the clean edits post. More often it is a matter of fit. A hard trap record requested when the floor is sixty people aged 40 to 60 dancing to disco. A slow ballad requested at peak. A meme song, or a track from a comedy sketch, requested by a group who think it will be funny for thirty seconds and would not think so if a client heard it.
The handling is the same in each case. The DJ says thank you and takes the note, then makes a judgement. If the song could work later, it goes in the queue for the moment it would fit; a slow request is not wrong, just early, and it may be exactly the right song at the end of the night. If the song is never going to fit this room, it is not played, and the guest is not told that in those words. "I'll see if I can work it in" is the honest answer, because it is true and it does not start an argument in front of the booth.
If the requester comes back a second time, or the request is borderline enough that the DJ is not sure, the DJ looks for the client's named contact. That person gets a quiet question, not a public one: "Someone's asking for this; do you want it?" The contact decides in five seconds and the DJ acts on it. This is why the planning call ends with one name, and why that person should still be reachable after the second drink.
The CEO's request
Somebody senior will ask for a song. It happens at most events, and the way it is handled says a lot about whether a DJ understands corporate work.
The principle is that the request is honoured if at all possible, and the timing is the DJ's. A song from the CEO is not a request in the ordinary sense; it is a signal to the room, and the room will notice when it plays. So it is worth playing well: at a moment when the floor is full enough to respond, mixed in cleanly rather than dropped cold, and, if the client wants, with the DJ making sure the CEO is on or near the floor when it lands. Playing it three minutes after it was asked for, to an empty floor, satisfies the request and wastes it.
There are two exceptions. The first is a senior request for something on the do-not-play list. That list was set by the client, and the DJ does not know whether the CEO is the client, a peer of the client, or the reason the song is on the list. The DJ checks with the contact. Quietly. The second is a senior request that is explicit or off-tone, which is rarer than people expect but happens, usually late. Same answer: the contact decides, and if the contact cannot be found, the clean-edit default holds and the song does not play.
One practical note: if you know in advance that your executive will want a specific song, put it on the please-play list as a must-play with a moment attached. It removes the guesswork and gets the song the placement it deserves.
The drunk request
Late in the night a guest who has been enjoying the open bar will come to the booth, and they will be persistent, and they will often want something that is a bad idea. The handling here is about the guest's dignity as much as the music, because this is a colleague of everyone in the room and they will be at their desk on Monday.
The DJ's booth manner in this situation: friendly, brief, and physically unavailable for a long conversation. Headphones half on. The request is taken with a thank you. The guest is not argued with, corrected, or told they have had enough; that is not the DJ's role and it never ends well. If the guest wants to stand at the booth, the DJ keeps working and keeps it pleasant. If the guest starts touching equipment, the DJ asks them, once, to step back, and if that does not work, the client's contact or the venue's security lead gets a look. Every good venue has a person for this and the DJ knows who they are before doors.
The song itself is treated like any other off-tone request: thanked for, queued or not, and never promised. Drunk requests are also a useful signal in aggregate. If four separate people have come up asking for the same era in the last twenty minutes, that is the room speaking, and a DJ who is reading the room takes the hint even if none of the four individual songs get played.
Request apps, slips, and the question of whether to use them at all
Clients sometimes ask whether guests can submit requests through an app, a QR code on the table, or a text line, and whether we recommend it.
It depends on the policy above. Under "yes" or "with rules," a request channel can be useful, because it moves the conversation away from the booth, gives the DJ a readable list rather than a shouted title, and lets the quieter half of the room, who would never walk up, have a say. Under "no," a request channel is a mistake, because it invites requests the host has already decided not to take, and the guests who used it will notice that nothing they asked for got played.
Two cautions. A request channel is not a voting system; the DJ is still making the decisions, and the client should not expect the most-requested song to be played on that basis. And a channel that is open before the event, shared in the invitation, produces a list that is really a please-play list from the whole company, which is a good thing if it is treated that way and consolidated by the client before it reaches the DJ. The do-not-play and please-play post covers how to turn it into something usable.
If you are planning a party and have not thought about requests yet, that is normal; we will ask on the planning call. To check a date, send it with the venue and headcount to the contact page. We reply within 24 hours.