Switching from Excel to a Ticketing System: a 2–4 Week Plan

Why Excel stops working for tracking requests

Excel helps while requests are few and one person handles them. But once you have multiple channels (email, calls, messengers), more than one or two executors, and regular deadlines, the spreadsheet starts to "leak." The move to a ticketing system usually happens not from fashion but from fatigue with manual checks and endless clarifications.

Problems become visible as volume grows: the file balloons, formulas break, and data accuracy depends solely on people's discipline. Worst of all — tickets get lost not because "nobody wanted to," but because Excel has no built-in control or action history.

Deadlines slip and tickets fall out of sight for repeated reasons: multiple versions of the same file appear and it's unclear which is the source of truth; statuses are changed manually with delays; a ticket has no single owner; discussions and decisions stay in chats while the spreadsheet only holds a row; overdue items are noticed too late and it's unclear why.

Managers usually need transparency and control: how many tickets are in progress, who is overloaded, where deadlines are urgent, and whether SLAs are met. Users expect speed and predictability: a clear status, a clear due date, and one place for ticket communication.

Within 2–4 weeks you can get real benefits: a single intake for requests, basic statuses, assigned owners, simple overdue reporting and a priority queue. Complex service catalogs, deep analytics on reasons, and fine-grained department-level permissions are better postponed until after the pilot.

Real example: in a small school IT team, "printer not printing" is logged in Excel while details are discussed in chat. The next day no one remembers who promised to come or what was already checked. In a ticket system the request immediately gets an assignee and a due date, and the conversation and result remain in the ticket. This reduces disputes and returns time to real work.

Inventory of current spreadsheets: what to document

Gather all Excel files where requests are recorded. Usually there is not one document but a set of tables by department, personal tabs "for me" and copies sent by email. For the transition it's important to know not "which file is primary," but where the data actually lives and who uses it.

For each file note: storage location, who maintains it, name, how often it’s updated and its purpose. If there are multiple versions, mark which is considered the source of truth and why.

What data to describe

Go through rows and columns. Don't try to "improve" the table now. The task is to accurately record what exists and how the team works today.

A convenient format is a short card for each file:

• Key fields: request date, requester, subject, description, status, assignee, due date, result.
• Additional fields that actually affect work: intake channel, contract number, address/branch, equipment, attachments.
• Reference data: departments, categories, work types, priorities, reasons, sources.
• Reports: which pivot tables and slices are used, which metrics are watched.
• "Hidden rules": color tags, comments, formulas, checks, manual filters, conditions like "red = urgent."

These "manual rules" are often more important than columns. They hide real statuses, priorities and processing logic. If you don't record them, you will move rows into the ticket system but lose their meaning.

Process map: how a ticket travels from request to resolution

A process map is needed so the ticketing system mirrors real work, not a neat "ideal" diagram. This is especially important for a fast transition: in 2–4 weeks there is no time for long debates.

Walk a typical ticket from start to finish and note where it appears and what people do with it. Email, phone, messenger, and face-to-face requests are different intake channels and each usually has a default owner. If you don't describe this, some requests will continue to live outside the system.

A simple sequence is enough:

• where the ticket comes from and who records it;
• who assigns the assignee and by what rules;
• who can change status and close the ticket;
• where clarifications from the requester or approvals are required;
• what counts as completion: a fix, a comment, confirmation.

Also mark delay points. Tickets usually stall on approvals, waiting for data (screenshots, access, room number) or in a queue for an overloaded specialist.

Describe SLAs in plain terms: what is normal (for example, "reply within 2 hours", "resolution within 1 business day") and what counts as overdue. A typical case: accounting messages in messenger about a broken printer get logged only in the evening and the assignee learns about it the next day. Formally the issue hung for a day, but in Excel no one sees where time was lost. A process map quickly shows which statuses and rules are needed first.

Roles and access rights: a simple setup that doesn't break work

Failures often start when everyone is given the same rights. In Excel this seems convenient, but in a ticketing system it leads to deadline chaos, conflicts and data exposure risks.

Start with a minimal set of roles and clear actions for each. The team will continue working in familiar ways, but order will appear.

Basic set of roles

• Requester: creates a ticket, sees status, adds clarifications, confirms resolution.
• Operator (dispatcher): checks the description, assigns an assignee, changes priority, returns for clarification.
• Assignee: takes the ticket, writes comments, records the result, moves it to "awaiting confirmation."
• Manager: sees queues and reports, approves rules, can escalate and change priorities by agreement.
• Admin: configures fields, statuses, reference data, access rights and integrations.

What to restrict immediately

Some actions should be closed for most users from day one, even if they were done "as needed" in Excel:

• Changing due dates and SLAs retroactively — only manager or operator and with a required reason.
• Deleting tickets or clearing history — usually admin-only; better avoid deletion altogether.
• Editing text after closure without trace — make edits via comments or a recorded note.
• Access to internal comments — provide a separate "internal" field visible only to operator, assignee and manager.

Example: an employee writes "printer not working" and accidentally leaves a personal phone number. If the requester sees only public comments and the operator moves the phone number into a hidden field, you reduce leakage risk while keeping the contact.

Which ticketing features are needed in the first 2–4 weeks

In the first weeks, the goal is not a perfect system but a clear minimum that replaces Excel and enforces discipline. Add improvements after the team starts living in tickets.

The base without which tickets become a new 200-row spreadsheet:

• Ticket card: who requested, what’s needed, attachments, assignee, due dates.
• Statuses: e.g. "New", "In Progress", "Awaiting Information", "Done".
• Comments and change history so you don't look for discussions in messengers.
• Notifications at least for new tickets, status changes and new comments.
• Search and filters by requester, subject, status and assignee.

Once this minimum works, it quickly becomes clear what else is needed to reduce repetitive questions and speed up responses.

What to add almost immediately

Simple extensions that pay off quickly and don't require long setup:

• Categories ("Access", "Email", "Accounting system", "Hardware") to see frequent problem areas.
• Priorities so urgent tickets don't drown in "do it tomorrow" items.
• Reply templates for repeated instructions.
• A knowledge base with short "how-to" articles.

Don't overcomplicate reports at the start. Three metrics are enough: workload per assignee, overdue tickets and average resolution time. That suffices to agree on rules and remove the "we all did it" argument.

Cloud or on-premises

If you need a fast launch with minimal IT work, cloud is usually chosen. If strict data requirements exist (government, finance, healthcare) or full control is needed, choose on-premises.

In Kazakhstan, a practical criterion is supply chain transparency and local support availability. This affects not only which ticketing system to pick but also the infrastructure it will run on.

2–4 week implementation plan: week-by-week steps

The fastest route is to launch a pilot and improve iteratively. A transition like this often fits into 2–4 weeks if a process owner is assigned and decision makers are defined.

Week by week

• Week 1: document current spreadsheets (fields, who fills them, where values come from), map a simple ticket path from request to closure, agree roles and pick a pilot group (e.g., 5–10 people: dispatcher, 2–3 assignees, manager).
• Week 2: configure the basics: statuses and return reasons, categories (e.g., "workstation", "email", "access"), the ticket form with required fields, notifications, access rights and ticket visibility.
• Week 3: migrate data (minimum set to start), run short training with live examples and start the pilot on real traffic without double-logging in Excel.
• Week 4: collect feedback, adjust the form and statuses, connect basic reports for managers (volume, SLAs, overdue) and decide whether to expand to the whole team or extend the pilot.

To avoid chaos you need a process owner (usually the support lead or service owner). They are responsible not for "button configuration" but for rules: what counts as a ticket, what is priority, when to close.

Record decisions in one place and briefly, otherwise rules will constantly change "in chats." A simple log is enough:

• what changes (status, field, SLA rule);
• why (what problem appeared in the pilot);
• who approved (process owner + pilot representative);
• effective date;
• how we check the result (a metric or a concrete example).

Example: in the pilot almost everything is marked "Urgent." In week two you introduce clear criteria (e.g., leader's workstation down, critical system outage). By week four reports show that truly urgent tickets no longer get lost in the general flow.

Data migration from Excel: what to migrate and how to avoid dirty data

A common mistake is trying to migrate everything accumulated over years. This slows launch and brings old problems (mixed statuses, empty dates, duplicates) into the new system.

Decide what you need for the first month. Usually active tickets and a small recent history are enough; leave the rest in Excel as an archive.

Usually worth migrating:

• active tickets (everything not closed) and the last 1–2 weeks of closed tickets;
• reference data (employees or groups, services/categories, divisions, equipment — if you actually maintain it);
• knowledge base — only current instructions that are frequently opened;
• history selectively, if needed for reporting or incident reviews.

Before import, normalize data: unified statuses (e.g., "New", "In Progress", "Awaiting", "Closed"), consistent date formats and a consistent priority scheme (P1–P4 or High/Medium/Low). Decide unique identifiers: either keep the old Excel number or add a "Legacy ID" field so you can find the original row later.

To avoid dirty data, set simple quality rules before loading:

• required fields: subject, requester, assignee (or group), status;
• no empty due dates for high-priority tickets;
• one assignee per ticket (no "Ivan/Petr/not sure");
• a unified reference for statuses and priorities with no free text;
• at least a manual duplicate check by number, phone or subject.

First do a test on a small set, e.g., 30–50 rows. Verify statuses mapped correctly, dates didn't "shift", and assignees actually exist in the system. After that, run the bulk import. This approach usually saves days of rechecks and makes the data migration manageable.

Statuses, priorities and SLA: make tickets move, not stall

The biggest slowdowns are fuzzy rules: what counts as done, what to do when data is missing, and who is "on fire" right now. Statuses, priorities and SLAs exist so there's always a clear next step for a ticket.

Don't overcomplicate statuses. A basic set covers most cases: "New", "In Progress", "Awaiting Information", "Under Approval", "Resolved", "Closed." It's important to separate "Resolved" and "Closed": "Resolved" means the assignee did the work; "Closed" means the requester confirmed or the agreed waiting period passed. "Awaiting Information" prevents tickets from hanging forever when required data is missing.

Agree on 3–4 priority levels with simple criteria so teams don't argue:

• P1: department-wide outage or critical security risk.
• P2: seriously impedes work, no workaround.
• P3: workaround exists, can wait.
• P4: enhancement or "when there's time."

SLA in plain words is two promises: what the user sees (how fast we reply and when we'll deliver) and what the team measures (time to first response, time to resolution, share of overdue tickets). For a pilot a clear rule is enough: P1 — response within an hour, P2 — within the business day, P3–P4 — handled by queue.

Notifications should help, not annoy. Usually three are enough: when the ticket is accepted, when a reply from the user is needed, and when the solution is ready. If an engineer sets a ticket to "Awaiting Information," the system sends a single message with a clear question and a response deadline, then reminds only near SLA breach. This helps tickets move rather than stall.

Common mistakes when switching from Excel to tickets

The problem is often not the system but the approach. If Excel is replaced "overnight" without agreements and simple rules, tickets quickly turn into new chaos.

Most common mistakes

• One person configures the system and users see the result only on launch day. Symptom: people keep writing in chat or sending old files because "tickets are inconvenient."
• Migrating Excel one-to-one: all columns, formulas and old reports. Symptom: a form with 20+ fields, tickets are filled randomly and data becomes garbage.
• Creating many roles and exceptions immediately. Symptom: tickets "invisible", statuses can't be changed or assignees set, people are afraid to click.
• No clear closing rules. Symptom: tickets closed "so they don't hang" without actual resolution, comments or requester confirmation.
• Pilot launched without metrics. Symptom: after a month everyone argues based on feelings and there's nothing to prove improvements or issues.

To avoid this, start with a minimum: 3–5 required fields (subject, description, category, priority, requester), 2–3 roles (user, assignee, admin) and one clear closing rule.

Example: for a team that supports workstations and servers, without metrics the effect is easily lost. Choose two pilot metrics: time to first response and share of tickets closed with confirmation. In 2–4 weeks you'll see bottlenecks and it will be easier to justify next steps.

Quick readiness checklist before launch

Before moving people from email and Excel to tickets, check five things. This list saves weeks of arguments and prevents the launch from turning into endless configuration.

• A process owner is appointed (one person who makes decisions) and a pilot group of 10–30 users is chosen. Prefer a team with stable flow: IT support, facilities or accounting.
• Simple reference data agreed: 5–7 topics (e.g., access, hardware, software, network, consultations) and 3–4 priorities with clear terms.
• Roles and rights are transparent: who creates tickets, who does the work, who can change priority, who sees others' requests. Decide in advance what external staff or contractors can see.
• One closing rule exists: what counts as "done" (repaired, issued, explained) and who confirms. Example: assignee moves to "Done" and the requester confirms within 2 business days or returns for rework.
• Basic reports and a review rhythm are prepared. Minimum: how many arrived, how many closed, how many overdue by SLA, average time to first response, top reasons. Schedule short meetings: weekly 15 minutes with the process owner and a monthly review with management.

If at least two items are uncertain, don't postpone the launch — simplify: cut categories, reduce roles, pick one team for the pilot and agree on a single clear SLA.

Example scenario: how a team gains first benefits in a month

Familiar situation: a company has two branches. IT requests live in one Excel (access, printers, laptops), facilities requests in another (repairs, passes, furniture). Some requests come via messengers, some by email. Duplicates appear, requests are lost, and disputes arise about who took a task.

The first step is simple: document both tables and agree a single set of fields. Keep only what's needed daily: requester, branch, category (IT/facilities), short description, priority, due date, assignee, status, comments. Also fix contact rules (one phone format) and a strict branch reference (exactly two values).

Roles are set so the move doesn't break routine:

• Dispatcher accepts all incoming, clarifies, sets category and priority, assigns an assignee.
• Assignees (IT and facilities) see their queues and tickets.
• Manager sees the big picture: due dates, overdue items, workload.

After a month you usually see initial gains without complex configuration. The "it was in my spreadsheet" excuse disappears — there is one queue and clear statuses. Losses fall: every request gets a number and an owner. SLA control is easier: you can see what's overdue and where it stalled. Managers can ask specific questions: not "how are things?" but "why are 5 tickets from branch 2 awaiting info?"

Integrations with email and messengers, complex dashboards, expanded knowledge bases and keyword routing can wait for stage two. Order appears in 2–4 weeks and improvements are added once the flow is under control.

Next steps after the pilot: scale without overload

After the pilot, don't try to "finish everything at once." Lock in what works and expand in waves so people don't feel burdened by new bureaucracy.

Collect short feedback from pilot participants: assignees, manager and 1–2 active requesters. The aim is to pick practical improvements that can be done in 1–2 weeks, not argue tastes.

Limit the list to 10–15 items: which statuses confuse and how to rename them; which required fields are missing (room, branch, equipment); which notifications are unnecessary or needed now; which reports the manager checks weekly; how to handle verbal requests.

Then expand by department waves. Choose the next department where requests are repetitive and someone is ready to enforce rules. Keep common foundations: unified priorities, SLA rules, standard roles and one approach to describing tickets. Add forms and categories locally so you don't overload the interface.

At the same time, assess infrastructure: where the system will run, number of users, need for a server, backups, and dedicated dispatcher workstations. If hosting on-premises, check resources and support availability early.

If infrastructure deployment time is lacking, involve a system integrator. For example, GSE.kz (gse.kz) works both as a local equipment provider and as an integrator: that's convenient when you need servers, workstations and support aligned with the future ticketing system and related services.