Your Client Is Not a Ticket

Why I put on a detective hat at DrupalCamp Kortrijk to talk about clients, and why asking better questions is becoming our most important skill.

"Can you make the button bigger?"

That is how I opened my session at DrupalCamp in Kortrijk at the end of June. On the screen: a paper ticket with a red CASE OPEN stamp on it. It comes from a real ticket. We made the button bigger. Clean code, properly tested, delivered on time. Two days later the client was back: still almost nobody clicked. Not because the button was too small, but because visitors did not trust the checkout behind it. We had solved the ticket perfectly, and still solved the wrong problem.

That one button became the thread of my talk "Your client is not a ticket". Because this happens to all of us. When I asked the room who had ever "lived" inside a ticket platform, Jira, Redmine or the Drupal issue queue, almost every hand went up. We know the ticket inside out. Nobody ever taught us to read what sits behind it.

Every request exists twice

The core of my story is simple: every request exists in two versions. There is the version in the ticket: "make the button bigger". Clear, scoped, easy to estimate. It slides straight into your sprint and feels like a win the moment you close it. And there is the version in the client's head: "nobody is finishing our checkout". Unclear, messy, impossible to estimate. But that is the problem the client actually pays us to fix.

We instinctively pick the comfortable version. Not out of laziness, but because the ticket is the one we can get our hands around. Still, technically correct is not the same as useful: you can build exactly what was asked, with great code and on time, and solve the wrong problem.

From developer to managing partner

I am Tom Hollevoet, managing partner at Calibrate, a Belgian agency that has been building with Drupal for many years. But I started out like many of us: as a developer, with a queue full of tickets and the ambition to close them as fast and as well as I could.

The longer I do this work, the more I realise that the hardest bugs are not in the code, but in the communication. That insight has shaped my path from developer to managing partner more than any technology ever did. These days I spend more time at the table with clients than in the code, and honestly, I still do the same job: trying to understand what someone really needs.

The case of the vague ticket

A session about communication can easily get fluffy, so I wrapped mine in a detective story. I played the detective, hat and trench coat included, and treated the vague ticket as a case to crack. Four clues, four leads, each one something you can apply the very next morning.

Lead one: know your client

The same words mean different things depending on who says them. A marketer asking for a bigger button usually means: get me more clicks and more sales. A technical contact might mean: the call to action is buried in the page. And a business owner really means: why aren't we selling more? Read the role first, then the ticket.

On top of that I added the four Insights colours, because most clients are a blend of four ways of communicating. The blue client wants detail and says: "make it 48 pixels, top right". The red one wants direction and results: "the numbers are down, make it convert". The yellow one is full of ideas: "make it pop, give it some energy!". And the green one is looking for reassurance: "will it break anything?". Same button, four colours, four conversations. The skill is hearing which colour is sitting in front of you, and answering in that language.

Lead two: ask before you build

Run the ticket through four lenses until you can say the real job in a single sentence. What are they asking, exactly? Show me an example. What do they want to achieve? How will we know it worked? Why is this coming up now? And what could break, does this touch the checkout or the tracking? For our button, that one sentence became: more completed orders before Friday, not just a bigger button. That is no longer a ticket, that is a brief.

Lead three: pick the moment

Is it foggy? Then call first, and afterwards write the agreements back into the ticket, in the client's own words. That way the conversation becomes the record, not somebody's memory. A ten-minute call can save you 17 emails, two assumptions and one mild production panic.

Lead four: dare to challenge the request

Don't be the implementer who neatly delivers the symptom; be the advisor who names the real problem. It doesn't have to be harsh: offer a better alternative ("let's try a clearer label before we resize"), test small before you rebuild everything, tie it to the goal ("will a bigger button really sell more?") and protect your client's budget ("a smaller change gets you most of the win"). Challenging isn't fighting your client; it's doing your job right.

Why I love doing this

What keeps me attached to Drupal is not just the technology, but the community around it. At a DrupalCamp you feel it right away: people share what they know, ask questions, and genuinely want each other to do well. DUG Belgium ran a great event, and speaking for a room like that is simply a joy. If this session got a few people to pick up the phone before opening the editor next time a vague ticket comes in, then my case is closed.

And then there is AI

My session was deliberately not about AI, and yet it secretly was, the whole way through. AI now generates in seconds what used to take hours of coding. I even used AI to create the detective images for my slides, wink. But the faster the code arrives, the more important the question that comes before it. Understanding the context of the problem, seeing the person behind the request, daring to ask the right question: that is what remains when the building itself becomes cheap. Whoever invests in understanding their client today makes themselves indispensable tomorrow.

Don't just close the ticket, close the gap

If you remember one thing from my session, let it be this: don't just close the ticket, close the gap. Good Drupal delivery is not only clean code. It is asking the better question, picking the right moment, and helping people move from request to real need.

And the button? We did make it bigger in the end. But only after we fixed the trust problem underneath it. That is the version the client told their boss about.

A big thank you to DUG Belgium for the organisation, and to everyone who raised a hand and thought along. If you'd like the slides or want to talk it through: just give me a shout.