IThis video teaches you how to fully customize the ticket system in Leadtime to match your own workflows. Instead of adapting to a rigid system, you configure everything to fit your team. Using a server crash task type as an example, all building blocks are assembled step by step.
The first building block is custom statuses. Leadtime comes with six standard statuses (New, In Progress, Feedback, Resolved, Closed, Backlog), but you can create your own – such as "Root Cause Analysis" or "Waiting for Customer." Important: every new status is based on a standard type, so the system can continue delivering accurate analytics and automations. Multilingual names are also supported.
Next are custom fields. Instead of writing additional information in an unstructured way in the description, you create dedicated fields – for example a dropdown for SLA level, a text area for affected systems, or a date field for the outage time. This makes data filterable and reportable.
Work activities are the third building block. With every time entry, the team member selects an activity (e.g., Development, Root Cause Analysis, Emergency Patch). This makes it transparent where working time actually goes – not just how much, but what for.
In the task type, you bring everything together. You select the relevant statuses, activities, and custom fields, and define which fields are required. Leadtime fundamentally distinguishes between two base types: "Feature" (billable, value-adding work) and "Bug" (non-billable error fixing) – this distinction runs through the entire billing system.
The final building block is task templates. Using the editor, you can predefine a structure with headings, tables, and editor placeholders. Placeholders provide guidance when filling out the ticket and automatically disappear when the ticket is saved. This ensures everyone on the team creates consistent, complete tickets.
Every team works differently. Bug reports need different information than feature requests. Support tickets go through different phases than internal tasks.
The good news is you don't have to adapt to a rigid system. In this video I'll show you how to configure the ticket system for your own workflows.
We'll build a complete task type for server crashes together. Along the way you'll learn all the building blocks: custom statuses, custom fields, work activities, and task templates.
I'm opening Administration, then Task Settings, then Task Status.
Here you see the standard statuses that Leadtime comes with: New, In Progress, Feedback, Resolved, Closed and Backlog. These six cover the typical phases of a ticket.
But maybe this doesn't fit your workflow. Maybe you need a status like "Waiting for Customer" or "In Review". No problem. You can create your own statuses.
Here's the important part: Every new status is based on one of the standard types. This isn't a limitation. It has a good reason. Leadtime uses these base types for analytics and automations. If you base a status on "In Progress", the system knows active work is happening. If you base it on "Closed", the ticket is done.
I click Create. For our server crash example, I'm creating a status called "Root Cause Analysis". I choose the magnifying glass as the icon. As the base type I select "In Progress" because during the analysis, active work is being done on the ticket.
I save. The new status is available immediately.
One more tip: If you work internationally, you can add multilingual names for each status. Leadtime automatically shows the right language based on each user's settings.
Now let's look at custom fields. I switch to Administration, Task Settings, Custom Fields.
Standard tickets have title, description, status, assignee. But sometimes you need more. For a server crash you might want to know: What SLA level does the customer have? Which systems are affected? When exactly did the outage happen?
You could write this information somewhere in the description. But then it's not searchable or filterable. With custom fields you capture structured data that you can analyze later.
I click Create. First field: SLA Level. As the type I choose Select, which gives us a dropdown. In the description I write "Service level agreement of the affected customer". Then I add the options: Gold, Silver, Bronze.
Save. The field exists now but isn't assigned to any task type yet. We'll do that in a moment.
Second field: Affected Systems. As the type I choose Text Area. Here the person can list multiple systems. Description: "Which servers, services or applications are down?"
Third field: Outage Time. Type Date. This documents exactly when the problem occurred.
Three fields, three different types. There are more: simple text, number, checkbox. But the principle is always the same. Structured data instead of free text.
Next building block: Work activities. I open Administration, Task Settings, Work Activities.
When your team books time on a ticket, it's often not enough to know that four hours were spent. You want to know: What were those four hours spent on? Development? Testing? Coordination?
That's exactly what work activities are for. With every time entry, the team member selects an activity. This makes your reports much more meaningful. You see not just how much time went into a project, but where exactly it went.
Leadtime comes with four standard activities: Development, Testing, Management and Research. For many teams that's enough. But you can add your own.
I click Create. For server crashes I'm adding "Root Cause Analysis". And a second one: "Emergency Patch". Both are now available as activities.
Later, when a developer books time on a server crash ticket, they can choose: Was this root cause analysis or emergency patch? This distinction is incredibly valuable when you want to understand where your resources are really going.
Now comes the exciting part. We bring everything together. I open Administration, Task Settings, Task Types.
Here you see the existing types. Leadtime fundamentally distinguishes between two base types: Feature and Bug.
This is important for billing. Everything derived from Feature counts as value-adding work. Feature development, new requirements, extensions. This work is billable.
Everything derived from Bug counts as fixing errors. Bugs are typically not billable. The customer doesn't pay for you to fix your own mistakes.
This distinction runs through the entire system. When you invoice projects later, Leadtime automatically filters by this criteria.
I click Create. Our new task type is called "Server Crash". As the icon I choose the lightning bolt. And as the base type I select Bug, because a server crash is an error that needs to be fixed.
Now come the building blocks we created earlier.
For statuses I select: New, Root Cause Analysis which is our new status, then In Progress, Feedback, Resolved and Closed. This is the workflow a server crash ticket goes through.
For work activities I select: Development, Root Cause Analysis and Emergency Patch. Only these three activities can be booked on server crash tickets.
For custom fields I add: SLA Level, Affected Systems, Outage Time. I can also specify which fields are required. I make SLA Level required. No server crash ticket should be created without this information.
Save. The task type is fully configured.
From now on, anyone on the team can create a server crash ticket. It automatically has the right statuses, the right fields, the right activities. Everything consistent, everything reportable.
Last building block: The task template. You find this directly in the task type under "Task Body Template".
A template pre-structures the description field. When someone creates a new server crash ticket, the text field isn't empty. It already has a structure.
I open the editor. Here I can add headings, tables, checklists. Everything the rich text editor offers.
For our server crash template I'm building this structure:
First heading: Error Description. Below that comes a placeholder.
Second heading: Initial Actions. Another placeholder.
Third heading: Affected Customers. Here I add a simple table with the columns Customer and Impact.
Now the highlight: Editor placeholders. I place the cursor under "Error Description", type slash and select "Editor Placeholder".
I write: "Describe what exactly happened. When was the problem noticed? Are there any error messages?"
Here's what's special about these placeholders: They're only visible in edit mode. As soon as the ticket is saved, they disappear. The person filling it out sees the guidance, but the finished ticket stays clean and readable.
I add another placeholder under "Initial Actions": "What immediate measures were already taken? Server restart? Rollback? Customer communication?"
I save the template.
Now I'll test this. I create a new ticket and select "Server Crash" as the type. And there it is: The complete structure. The headings, the table, and the placeholders with the hints.
I fill out the ticket and save. The placeholders are gone. Only my actual text remains.
This is extremely helpful, especially when different people create tickets. Everyone knows what information is needed. And all tickets look the same.
You've now learned the complete toolkit.
Custom statuses for your workflow. Custom fields for structured data. Work activities for precise time tracking. Task types that bring everything together. And templates that make your team's life easier.
The ticket system adapts to your processes, not the other way around.
In the next video I'll show you how to bring external users into your ticketing and control the visibility of information.
