Your Software Should Echo You, Not the Other Way Around

The binder next to the keyboard

Look at the front desk of a school-age program at the end of a long afternoon. The computer is on and the program software is open. Right next to the keyboard sits a binder. Inside it are the things the software does not know: the family that switched to Tuesdays, the child who started on a Wednesday, the check that came in this morning and has not been entered yet.

On the edge of the monitor there is a sticky note. In another tab there is a second spreadsheet that someone updates every Friday so the bills come out right.

Nobody planned that binder. It grew one page at a time, every time the software could not hold something the program needed it to hold. Your staff did exactly what good staff do. They kept the program running and filled the gap themselves.

We think of that binder as a sound. It is the sound of software that is not listening.

What the name Echo means

Echo Scheduling means we echo your scheduling needs back to you in your technology. You tell us how your program works, and the software answers in the same shape.

That sounds simple, but a lot of platforms are built the other way around. They arrive with their own idea of what a program is: one schedule pattern, one billing rhythm, one way to take a payment. Your program has to fit. Where it does not fit, your staff fill the gap by hand. The gap becomes a workaround, and the workaround quietly becomes part of somebody's job.

When software only fits its own shape, your staff become the translators.

The name is a promise about direction. The program speaks first. The software echoes.

The workarounds are trying to tell you something

A workaround is not a failure of your team. It is information. Every sticky note is a fact that the system had no place for. Every second spreadsheet is a calculation the software could not do the way your program does it. Every phone call from a parent asking to change a day is a change that only one room was allowed to make.

When we worked with a YMCA school-age program we built alongside, we did not start with a feature list. You can read how we built it on our process page. We started by listening to how their day really ran, and what the team showed us, week after week, was workarounds. Parents phoned to change their schedules. Rescheduling and charging accounts were done by hand. Finding the cards that declined meant searching for them.

Our process turns those workarounds into a map. We listen while you show us how your day really runs. We find the pain points, every place your tools slow your team down or force a workaround. We reverse-engineer the problem, tracing each pain point back to its root cause. Then we build the solution to work the way you described, and prove it with your team before it goes live.

Traced back far enough, those workarounds tend to share a root cause. The software had a fixed idea of the program, and the program had to bend around it.

What it sounds like when software echoes back

When software is shaped around how your program actually runs, the workarounds have nowhere left to live. For the program we built alongside, that sounded like this:

• 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.
• For families on child care assistance, the copay is entered once and billed, and covered days are not charged to the family.
• The parent portal, bills and receipts are in English and Spanish.

None of that is clever. It is the program's own rules, said back to it. That is the whole idea. Your rules already exist. They are written in the binder, on the sticky notes and in the heads of the people who have run your desk for years. Software that echoes you starts there.

Questions that tell you whether your software is listening

You can tell whether your software echoes you without a demo and without a vendor in the room. Sit down with your office staff and one site coordinator and ask:

• Where is the second spreadsheet? If someone keeps one, find out what it holds that the software does not.
• What is on the sticky notes? Each note is a fact the system had no place for.
• Who has to call whom? If a parent has to phone the office to change a day, the schedule only lives in one room.
• Can the bill ever disagree with the schedule? If it can, they are being kept in two places.
• When a balance changes, can you see who changed it? If not, your team is relying on memory.
• Can a family who reads in Spanish read their own bill? If not, someone on staff is translating it for them.

If the answers are short, your software is listening. If every question opens the binder, it is not, and that is not your staff's fault. They have been doing the echoing themselves, by hand, for as long as the binder has been there.

Let us echo your program back to you

We would like to hear how your day really runs, at your YMCA, park district or rec center, including the parts that only live in the binder. Tell us what your staff do by hand and what they wish they did not have to. We will show you what it looks like when software is shaped around a program instead of the other way around.

Request a demo