Eight Weeks of Listening Before We Built Anything

A Monday the requirements list never mentions

Picture a Monday at a school-age program office. The phone rings before the coffee is ready. A parent needs Wednesday instead of Thursday this week. Someone makes the change in the schedule, then writes it on a sticky note, because the bill is figured somewhere else and it needs to hear about the change too. By the end of the day there is a row of sticky notes along the edge of the monitor and a second spreadsheet open in another tab.

None of that shows up in a requirements document. Ask an office what it needs from new software and you get a tidy list: schedules, billing, rosters, payments. The list is true. It is also missing the part that matters most, which is everything that happens between the items on it.

That is why, when we set out to build scheduling and weekly billing software for school-age programs, we did not start with a list. We started by sitting with the people who do the work.

How the 8 weeks worked

Our starting point was a YMCA school-age program we built alongside for 8 weeks, meeting for about 1 hour one day a week, on average. You can read more about how we built it on our process page.

An hour a week sounds small, and that was the point. A program office has no spare afternoons. In each meeting the team showed us part of how their day really ran, and we listened and asked questions. The next week, they showed us another part.

The length mattered more than the hour. One meeting shows you one kind of week. Over 8 weeks you see the week with a closed day in it, the week a child starts on a Wednesday, the Friday when a few cards decline, the family that pays at the front desk, the parent who reads everything in Spanish. Those are not edge cases. In a school-age program, they are what an ordinary month is made of.

A requirements document tells you what people think they do. A day tells you what they actually do.

Workarounds, not a feature list

When we listened, the team did not hand us features. They showed us workarounds. Parents called the office to change their days, because only the office could change a schedule. Cards declined on billing day, and finding them meant searching. Rescheduling, charging accounts and processing refunds were repetitive jobs, done by hand, week after week.

Each of those workarounds was a pain point. The workaround told us where it hurt. It did not tell us why.

This is where a requirements document falls short. A document would have said parents need a way to change their schedule. Fine. Build a form. But the reason parents called was not a missing form. It was that the schedule only lived in the office, and the bill lived somewhere else. A form on its own would have created one more place for a change to get lost.

Listening long enough lets you follow a pain point back to its root cause. Our process has four steps, and the first one does most of the work:

• Listen. You show us how your day really runs, and where your software gets in the way.
• Find the pain points. Together we name every place your current tools slow your team down or force a workaround.
• Reverse-engineer the problem. We trace each pain point back to its root cause, so the fix solves the problem, not just the symptom.
• Build the solution. We build it to work the way you described, and prove it with your team before it goes live.

Skip the listening and the other three steps are working from guesses.

What came back from all that listening

What we built is the scheduling and billing platform on this site, and it sounds the way the office sounded when they described their week:

• Parents choose and change their own days online instead of calling the office.
• A child's weekly days are set once and repeat, and a child who starts mid-week is billed that day for the days left in the week.
• The bill is built from the schedule, so the two match, and days the program is closed are not charged.
• Someone in the office starts one run that bills the whole week, and declined cards are listed together in one place.
• Cash and checks taken at the front desk are recorded on the family's account, and there is a history of who changed what.
• Parents enter their own card, so it is never written on paper.
• Printable rosters for each site carry allergies and contact numbers, and the parent portal, bills and receipts are in English and Spanish.

That is where the name comes from. Echo Scheduling echoes your scheduling needs back to you in your technology. Every item on that list traces back to something the team showed us during an ordinary week, not to a line in a document.

Try one listening hour in your own program

You do not need us to start. Pick one ordinary day this week and spend an hour on it with your office and one site coordinator. Do not ask what the software should do. Ask them to walk you through what they did today, step by step, and write down every time they reached for something outside the system:

• A sticky note.
• A second spreadsheet.
• A binder at the front desk.
• A phone call that only happened because a parent could not make the change themselves.

Each one is a pain point. Then, for each, ask why it has to happen that way. Keep asking until the answer stops being about a person and starts being about where information lives or who is allowed to change it. That is usually the root cause, and it is usually shared by more than one workaround.

Tell us how your day really runs

If your team keeps a second spreadsheet next to your software, the software is not listening yet. We would like to hear how your day really runs, at your YMCA, park district or rec center, from the first phone call on Monday to the bill on Friday. Then we will show you what we built by listening to a program like yours.

Request a demo