Moving IT ticket management out of spreadsheets and into Notion
Migrating the IT department's task base into a structure where every ticket carries attributes, every director has their own view, and the board sees figures instead of requesting reports.
The problem
The company logged IT tasks in spreadsheets. That works for noting things down, it does not work for following them. A spreadsheet cannot tell you who asked for what, which department a problem belongs to, or how many tickets came in last month without somebody building the pivot table by hand every time.
The timing mattered too. IT was in the middle of modernising the company's systems, which means more requests, more people involved and more questions from the board about where the effort is going. The spreadsheet became the bottleneck.
What I did
I migrated the base into Notion and gave structure to what had been free text. Each ticket gained a requester, an affected department, a request type, a date and a status. The moment those fields exist, questions that used to require manual work become filtered views.
What was set up
- Tickets with attributes Requester, affected department, request type, date and status. It stopped being a line of text and became a record you can query.
- A page per manager and director Each one sees the tickets for their own area, without asking anybody and without navigating through what does not concern them.
- Tracking charts Which departments generate the most requests, where problems most often originate, and how many tickets were handled in a given period.
- A general tracking page The department-wide view, kept separate from the per-area ones.
- A documentation space IT procedures and material for the rest of the company, in the same place people were already going to check request status.
- An FAQ The questions that reached IT over and over got written answers, which cuts down the tickets that never needed to exist.
Why this counts as technical work
I wrote no code on this project. What I did was the work that usually comes before the code: understanding what information people need to get out of a system, designing the data model that makes it possible, and migrating what already existed without losing history.
Choosing not to build anything bespoke was deliberate. An internal tool written by me would have stayed dependent on me. In a structure the team can change on its own, the organisation survives my leaving, which is the test that matters for this kind of work.
Outcome
The board began following IT by figures rather than by reports requested case by case. For a department in the middle of a systems modernisation, that is what kept things orderly while the workload climbed.