How I use Tender and Lighthouse

or, Why I am a dick about tickets

My role at ENTP is primarily that of a developer, but I do support, as well as fielding questions from and doing research for the rest of our support staff. For both of these roles Tender and Lighthouse integration is a huge help.

Let me explain a little bit about my relationship with tickets. I love tickets and depend on them to do my job. Unlike my own brain, Lighthouse tickets are a steel trap of information, keeping track of relevant changes and discussions until they’re no longer needed. They help me avoid context-switching unless there is a real emergency. For this reason, my workflow is highly ticket-oriented. Having a steady flow of tickets is the easiest way for me to stay focused.

The support staff is sometimes annoyed at me because I can sound like a broken record when it comes to bug reports: “Were you able to reproduce the issue?” followed by “file a ticket.” It is a brusque reply because I want to minimize distraction and keep the important conversation in the ticket. With Tender’s support for Lighthouse integration, the rest of the support staff and I can communicate almost entirely through these channels, and everything stays on the record.

How we track customer issues

When a user opens a discussion in Tender, generally the first thing staff will do is determine whether the bug is a result of a defect or customer error (sometimes it’s a little of both). If it’s determined that there’s a defect that needs to be addressed, they’ll attach a Lighthouse ticket tagged with “to-do,” which is the tag we use to mark tickets that require a followup to the discussion.

On the development side, we track the “to-do”-tagged tickets in Lighthouse and schedule them by moving them into milestones. I generally prefer to have every second or third milestone dedicated to customer fixes, but often a customer bug ticket will make it into a feature milestone if the functionality is related.

At this point the developers can dive into the milestone and crank out a pile of fixes at once. When a milestone is completed and shipped, staff closes the loop on the tickets tagged “to-do” by returning to the associated Tender discussions and letting the customer know it was fixed. In this way, staff spends more of their time helping customers and developers spend more of their time hacking and solving problems.

So our bug-fixing process starts in Tender, moves to Lighthouse, and upon completion returns to Tender. By using each tool for the right job, it’s much easier for me to stay minimally distracted and for the support staff to efficiently address defect reports. Hopefully their annoyance at my obsession with tickets is a small price to pay.

That is why I am a dick about tickets. The fact is, I am coming from a place of love. My love for tickets.

We’re interested in hearing about your Tender workflow: Do you keep state in your tools or in your head? What sort of processes keep your support operation running smoothly?