Discover identity systems before proposing single sign on

A technology director asks if single sign on will work for every user before the semester starts. The honest answer is you do not know yet, and pretending otherwise sets up a promise you cannot keep. A school network rarely runs on one identity system. Central IT often manages staff and student accounts one way, a partner school runs its own directory a different way, and the parent portal sits outside both. Before you say yes or no to single sign on, you need to see the whole picture, not just the part the person in front of you controls.

Why this conversation goes wrong

Account executives want to give a confident answer, especially when the customer names a date. A school year starts on a fixed calendar, and a technology director asking about single sign on before that date is really asking for reassurance. The instinct is to supply it. You say something like "yes, we support single sign on" because the platform does, technically, support the protocol. That statement is true and also useless, because the real question is whether it will work with this district's specific mix of directories, this school's outside IT provider, and however parents currently log into a separate portal.

The failure mode is treating a single sign on request as a feature question when it is actually an architecture question. A feature question has a yes or no answer. An architecture question needs a map, an owner for each piece of that map, and a sequence for testing the connections. When you skip the mapping step and jump to a commitment, you either overpromise a timeline you cannot control or you underdeliver once the technical reality surfaces in week three of onboarding. Neither outcome helps you keep the account or keep your word.

How to prepare

Before you sit down for this conversation, assume there is more than one identity system, not one. Come in with three questions you plan to ask no matter what the customer tells you first. Ask who manages accounts for staff, who manages accounts for students, and who manages accounts for parents or guardians. Those three groups are often provisioned by three different people or systems, even in a district that looks unified from the outside.

Ask whether every school in the network uses the same central IT team or whether any school contracts with an outside provider. Independently supported schools are common in charter networks and in districts where a school joined later and kept its own vendor. That single fact changes your entire integration plan, because you now have two technical owners to loop in instead of one.

Ask how parent accounts get created today. Parents frequently sit outside the staff and student directory entirely, tied instead to a separate portal or a registration system. If a parent portal exists, find out who owns it and whether it was built in house or bought from another vendor. You want this information before the conversation with the technical buyer, not during it, so bring a short list of these questions to any early discovery call, the same way you would when you handle a request to change a student account name and need to know who actually owns that record before you promise a fix.

What to say

Picture the conversation with Dana, a technology director, and you as the account executive. Dana opens with the question you expected. "Can we get single sign on working for every user before the first day of school." She wants a date, and she wants it now.

You do not give her one yet, and you say so plainly. "I cannot answer that honestly until we look at each directory and who manages it. Do all your schools use the same central IT team, and how do parents get their accounts today." Dana pauses, then tells you one of the schools in the network uses an outside IT provider, and parents currently log in through a separate portal that a different vendor built years ago.

You name what that means instead of glossing over it. "That gives us two separate integration paths, not one. I want to set up a working session with your central team, the outside provider for that school, and whoever owns the parent portal. We will map out how staff, students, and parents each get an account, then agree on which connection we test first." Dana agrees, and you have turned a vague deadline into a concrete next step with the right people in the room.

That last move matters. You did not say "yes" or "no" to Dana's original question. You replaced it with a plan that produces a real answer, and you did it without letting the pressure of a calendar date push you into a guess.

Mistakes to avoid

Do not let the school's desired start date become an installation commitment. A date is a goal for the customer, not a technical fact you control. Repeat back what you can control, which is the discovery process and the sequence of testing, and let the technical owners set the real timeline once they see the map.

Do not run the technical workshop as a sales demonstration. The moment you start showing screens instead of asking who owns which system, you lose the information you actually need. Keep the workshop focused on drawing the architecture, not selling the platform. The platform already sold itself if you got this far in the deal.

Do not assume the person in the room speaks for every system. A district technology director might not know how the independently supported school handles accounts, and might not know who built the parent portal five years ago. Ask directly whether anyone in the room can answer for each piece, and if not, get that person's name before the meeting ends.

Do not skip the parent path because it feels like a smaller piece of the deal. Parent accounts are frequently the most fragile part of the whole picture, built on older systems with less documentation than staff or student directories.

How to practice and score it

Draw three user paths on paper before you practice this conversation, one each for staff, students, and parents, for a fictional school network with at least one independently supported school. Roleplay the discovery call and force yourself to ask who provisions each account before you say anything about compatibility. DealSpeak's education practice conversations are built around exactly this kind of scenario, where the technical buyer wants a date and you need to earn the right to give one.

After the roleplay, check your own performance against two questions. Did you name every external system the customer mentioned, including any outside IT provider or separate parent portal, instead of letting one slide past. And does the next meeting you proposed include a specific person able to answer for each system, not just a general promise to follow up. A manager reviewing the recording should be able to point to the moment you turned a date question into a mapping exercise, and should hear you name the parent portal without being prompted.

Score the close the same way you would score any other education conversation, by checking whether the reader wants to learn more, the way you would when you look at how a team uses student clubs to build an early connection with a new school. The workshop is your version of that early connection, the moment where you and the technical owners agree on a shared diagram instead of a guess. Get that right and the single sign on question answers itself once the mapping is done.