Excel calendar with multiple events in one day, done properly

A calendar built in a spreadsheet works well right up to the point where a second appointment lands on the same day. Then the question becomes where to put it. Inside the same cell on a new line, in an extra row that shifts every other week, or on a separate sheet that nobody will ever cross reference. Every one of those choices is a workaround for the same structural fact: a month grid is a fixed container, and the number of things happening on a Tuesday is not fixed.

The way out is to stop storing events in the grid. Keep one row per event in a flat list, treat the month view as something generated from that list, and the layout stops breaking as volume grows. What follows is how that looks in practice, and where the spreadsheet stops being the right tool regardless of layout.

Why the grid breaks at the third appointment

Three approaches turn up repeatedly, and each fails in a predictable way.

The most common is typing multiple lines into a single day cell. On a Mac the in-cell line break is Control+Option+Return, while the Windows build uses Alt+Enter, and Microsoft documents both. Entry is fast and the month grid keeps its shape. The cost shows up the first time someone asks how many meetings happened last month or how many hours went to one client, because a block of text inside one cell cannot be counted. The data is visible and unusable at the same time.

The second approach is reserving three rows for each day. That holds until a day needs four, at which point inserting a row shifts every date below it. Conditional formatting rules and formulas that reference ranges by position break quietly when this happens, and the breakage is often noticed weeks later.

The third is one sheet per day or per week. Capacity per day becomes unlimited, and the ability to see across days disappears. A file heading toward hundreds of sheets has no practical way to answer a question about the quarter.

What unites all three is the attempt to grow data inside a presentation layout. Seven columns by five or six rows is a shape chosen for printing, not for storing a variable number of records.

One row per event, and generate the grid from it

Start a separate sheet with one row per event and these columns.

Column	Example	Why it earns its place
Date	2026-09-04	Stored as a real date, not text
Start	15:00	Stored as a real time
End	16:00	Makes duration a subtraction
Subject	Weekly review	The only field most templates keep
Location	Shibuya office	Needed for any travel judgement
Owner	Name	Gives grouping something to group by
Type	Meeting, focus, travel	Separates categories of time

With this shape, a day holding eight events is eight rows. Nothing about the sheet has to change. When a month grid is still wanted, generate it: FILTER pulls the rows matching a given date, and TEXTJOIN collapses them into the single cell the grid expects. The printed layout becomes a derived artifact that can be rebuilt at any time, and the authoritative version lives in the list.

Arithmetic becomes possible for the first time here. End minus start gives duration per row. Summing by owner or by type answers how many hours went into meetings this week. That number is usually the reason the calendar was being tracked in a spreadsheet in the first place, and the month grid layout was the thing preventing it from being produced.

Rebuilding the month grid from the list

Moving to a flat list does not mean losing the printable month view. It means producing it rather than typing into it.

Build the frame first. Put the first day of the month in one cell, then let SEQUENCE generate the run of numbers and offset it by the weekday the month starts on. Every date in the grid is then a formula, which is the part that matters: a grid of typed dates has to be rebuilt every month, while a grid of formulas needs only the starting date changed.

Fill the cells next. For any given day, FILTER returns the subject column of every row in the list matching that date, and TEXTJOIN collapses the result into a single cell using a line break as the separator. The same formula handles a day with one appointment and a day with eight. If cells look cramped, wrapping and row height fix it, and neither change touches the data.

Two refinements are worth adding. To show start times alongside titles, concatenate time and subject before joining, so each line reads as a time followed by what happens then. To get chronological order inside each cell, sort the underlying list by date and start time. That sort is done once on the list, and every cell in the grid inherits it, which is the general advantage of this structure: adjustments happen in one place rather than in thirty-one.

One discipline keeps this working. The generated grid must stay disposable, which means never typing anything directly into it. The moment a note is added to a day cell, that note exists nowhere else and the grid can no longer be regenerated without losing it. When something new needs recording, the correct move is adding a column to the list, not a scribble to the grid.

Catching double bookings with a formula

Once several events share a day, overlap is inevitable, and a spreadsheet says nothing about it unless asked.

The test is short. Two events overlap when the first starts before the second ends and the second starts before the first ends. Applied across rows sharing a date, that identifies every clash in the sheet. Wiring the same condition into conditional formatting colours the row at the moment of entry, which is considerably more useful than discovering the clash on the morning it matters.

The limit is worth stating plainly. The test only sees what has been typed into the sheet. Travel between two locations, a colleague holding a room, a commitment that lives in a different system: none of those are visible, so a row can pass the overlap test and still be impossible. That gap is not a formula problem. It is a boundary of what a private file can know.

Three things the spreadsheet will not do

Layout fixes take the file a long way. Three gaps remain no matter how well structured the list is, and they are the ones that decide when to move.

Reminders are the first. A spreadsheet has no way to interrupt anyone fifteen minutes before an appointment. Every event stored there depends on somebody remembering to open the file, which means the file has to be opened on a schedule that itself has to be remembered.

Concurrent editing is the second. The moment a file is mailed to a colleague, it forks. Their additions and yours end up in different copies, and reconciling them is manual. Shared storage improves this but does not eliminate it, and the merge rules vary by product and configuration.

Travel is the third. An appointment ending at two and another starting at three in a different part of the city renders as an hour of white space. It is not free. Holding a location column helps a human judge it, but converting a location pair into a duration and subtracting it from the gap is work the sheet will not do on its own.

Which of the three hurts most is what decides the timing of a move. A single person tracking stable appointments can patch the reminder gap by other means and stay in the file for a long time. As soon as two or three people are writing into the same sheet, the forking problem starts consuming more time than the sheet saves. Volume is rarely the trigger. The number of people involved and how often times change are the two variables that matter.

There are worthwhile mitigations before giving up on the file. Restrict all writing to the list sheet so that the generated grid stays read only, which removes the question of where a given entry was recorded. Add a column naming whoever entered each row, so any query about an appointment has an obvious recipient. Handle changes by marking a cancellation column rather than deleting rows, which preserves what the schedule looked like before the change. None of these fix concurrent editing, but together they make the file survivable for longer.

Moving the list into a calendar

A well-structured list exports cleanly, which is the payoff for the layout work. Google Calendar states what it accepts:

You can import events into Google Calendar using ICS and CSV files on a computer. Source: support.google.com

Three details decide whether the import succeeds. Headers must be in English, using Subject, Start Date, Start Time, End Date, End Time, All Day Event, Description, Location and Private. Only the first two are mandatory, so a first pass with nothing but subject and date is the fastest way to confirm the file parses before adding the rest. And any field containing a comma has to be wrapped in quotation marks, or the columns shift from that row onward.

Recurring events change shape during the move, usually for the better. Rows that were typed out one per week become a single repeating event. There is a ceiling: repeating events in Google Calendar are limited to 730 occurrences, which a daily repeat reaches in about two years. For a weekly meeting that ceiling is fourteen years away and irrelevant. For a daily habit it is worth knowing before assuming the series runs forever.

For Calendar on the Mac, the equivalent path is producing an ICS file and importing it. Either way, the export happens once. A month grid with text stuffed into merged cells cannot be exported at all, which is the practical reason the layout matters more than it looks.

Keep the spreadsheet for the arithmetic

Moving events out is not the same as abandoning the file. Splitting the work by what each tool is good at leaves both more useful.

The spreadsheet keeps the counting: hours per client, meeting load per person, how a month compared with the one before it. Those are questions about aggregates, and a calendar interface is a poor place to answer them. The calendar takes anything that needs a reminder, anything shared with another person, and anything whose time is likely to move.

Entry cost is the remaining variable, and it is worth measuring before choosing where events will live. Adding a row to a well-built list means typing date, start, end, subject and location in sequence. Whether that gets faster or slower elsewhere depends entirely on how the destination handles input, which is set out on the Entering events page. The travel gap described earlier is the other axis: some calendars store a location and stop there, while others derive a duration from it, and the reasoning is covered under Travel time. Anyone weighing two or three destinations will find the differences laid out on the Compared with other calendars page.

What to change first

Rebuild the sheet as one row per event before doing anything else, because every other option depends on it, including staying in a spreadsheet. Once the list exists, add the overlap formula, then decide whether reminders and shared editing are worth an export. If they are, Caltimate is one of the destinations worth comparing.