Moving From a Spreadsheet to a Request Desk

A spreadsheet to request desk migration takes about two weeks for a small team: map the sheet's columns to the desk's fields, import only open requests (plus a summary of closed ones for history), set up categories and targets from what the sheet shows you actually receive, run both in parallel for a week with new requests going only to the desk, then make the sheet read-only. The data is the easy part; the habit change — people filing requests in the new place — is what needs planning.

Signs you've outgrown the spreadsheet

Spreadsheets are a reasonable start: free, flexible, everyone knows them. They stop working when:

• Two people edit the same row and one change silently wins.
• Nobody knows who owns what — the "Owner" column is blank or stale.
• Requesters can't see status without asking, or can see everyone's requests, including private HR ones.
• There are no deadlines, or deadlines exist but nothing warns anyone before they pass.
• Reporting is manual — someone spends Friday building a pivot table.
• The sheet has 2,000 rows and filters are the only way to find anything.

If three or more apply, the spreadsheet is costing more time than it saves. What replaces it is described in what is an internal request desk.

Step 1: learn from the sheet before leaving it

The spreadsheet is a record of what you actually receive. Before migrating, use it:

• Categories. Group the last three months by what was asked. The groups that appear repeatedly are your categories; aim for 5–10.
• Targets. For categories where the sheet has dates, look at how long requests took. Set first targets near your 80th–90th percentile, as in the SLA tracking guide.
• Teams. Who actually handled each category? That's your routing.
• Knowledge. Questions that appear over and over deserve a knowledge-base article on day one — see ticket deflection.

Step 2: map the columns

Spreadsheets drift; columns get added and repurposed. Map each to a field in the desk:

Spreadsheet column	Desk field	Notes
Date	Created at	Parse carefully — see below
Name / Email	Requester	Match to user accounts by email
Request	Title + description	First line → title
Type	Category	Map free text to your new categories
Assigned to	Assignee	Match by email
Status	Status	Map "WIP", "in progress", "doing" → one status
Notes	Internal note	Not visible to the requester
Priority / "URGENT!!"	Priority	Re-triage rather than copying

Anything that doesn't map cleanly (a colour code, a "follow up?" column) usually shouldn't be migrated. It was compensating for the spreadsheet's missing features.

Step 3: decide what to import

You rarely need everything:

• Open requests — yes, all of them, with their requester, assignee and notes.
• Recently closed requests (the last month or so) — optional, useful if people will look for them.
• Old closed requests — no. Keep the spreadsheet as a read-only archive and link to it. Importing years of inconsistent data mostly imports mess.

Importing only open work also forces a useful clean-up: every open item gets looked at once, and many turn out to be done or abandoned.

Step 4: clean and import the data

Export as CSV (the format is described in RFC 4180 — quoted fields, commas, line breaks inside quotes). Then:

• Dates. Spreadsheets mix formats (03/04/2026 is March 4 or April 3 depending on locale). Normalize to ISO 8601 (2026-04-03) before import, and decide which timezone the sheet's dates were in.
• People. Match names to accounts by email. Unmatched requesters should be invited first, or imported with the email recorded so they can be linked later.
• Duplicates. The same request often appears twice. Deduplicate by requester + similar title + date.
• Free text. Trim whitespace, fix obvious encoding problems (’ instead of ').

Import through the desk's own import feature or API so permissions and triggers apply — deadlines stamped, organization set, events recorded. If you import straight into a database (Supabase supports CSV import), remember that importing as a privileged user bypasses row-level security; set the organization and requester fields correctly yourself, and run the same checks the app would.

CSV injection

A value starting with =, +, - or @ can be interpreted as a formula when a CSV is opened in a spreadsheet program — OWASP documents this as CSV injection. It matters twice: when you export the old sheet (someone may have typed a formula), and when your new desk exports data later. When exporting, prefix such values with a single quote or otherwise neutralize them.

Step 5: run in parallel — briefly

For one week:

• New requests go only to the desk. Add a banner at the top of the spreadsheet: "New requests → [link]. This sheet is read-only from Monday."
• Open requests are worked in the desk, not the sheet.
• When someone adds a row to the sheet anyway, move it into the desk for them and reply with the link. The first few times, doing it for them is faster than explaining.

Keep the parallel period short. Two systems of record for more than a week means both are wrong.

Step 6: switch off the sheet

At the end of the week, make the sheet read-only (or remove edit access for everyone but one admin) and rename it with "ARCHIVE" in the title. Pin the link to the desk wherever the sheet used to be linked: team chat, the intranet, email signatures.

Step 7: show the first month's numbers

The moment that converts sceptics is the first report: "In September, IT handled 212 requests, median first response 45 minutes, 91% resolved within target." A spreadsheet never produced that without someone's Friday afternoon. Share it. The metrics worth showing are in help desk metrics that matter, and the people side of the rollout is in onboarding a team to a new help desk tool.

FAQ

How long does it take to move from a spreadsheet to a help desk?

For a small team, about two weeks: a few days to set up categories and import open requests, and a week of running in parallel before the sheet becomes read-only.

Should I import all my old spreadsheet data?

Import open requests and perhaps the last month of closed ones. Keep older history as a read-only archive rather than importing inconsistent data.

How do I get people to stop using the spreadsheet?

Make the sheet read-only after a short parallel week, put a link to the desk at the top, and move stray rows into the desk for people while replying with the link.

What is CSV injection?

A spreadsheet-formula attack: a cell value starting with =, +, - or @ may run as a formula when a CSV is opened. Neutralize such values when exporting.

Sources

• RFC 4180 — Common Format for CSV Files
• OWASP — CSV Injection
• Supabase — Import data
• Wikipedia — Help desk