In the ever-evolving landscape of higher ed technology, the role of a sales engineer helps bring the art of the possible to light for clients. At Pathify, Julie Gumerman identifies the match between an institution’s technical requirements and our Engagement Hub’s capabilities.
Julie is an expert in areas ranging from security protocols to accessibility requirements, giving prospects peace of mind before committing to a partnership with Pathify. She spearheads training of our middleware technology, Flow, while scoping custom work projects to help clients fulfill creative endeavors outside the Recipe Library and Flow’s capabilities.
In part two of this insightful series, we sit down with Julie to delve into her role as Senior Sales Engineer where she discusses her role in the customer journey and what draws higher ed IT directors to Flow.
Stay tuned for the last part of this three-part series, exploring the inner workings of the Recipe Library.
This interview transcript has been edited for clarity and brevity.
Pathify: How would you describe your role to an institution considering a partnership with Pathify?
Julie Gumerman: I like to think of myself as the resident nerd for the sales department. I’m doing anything from talking to colleges and universities about how our systems work, or what the fit might look like, to scoping custom work and APIs with system compatibility. I also do a lot of DIY widget training and tutorials.
Pathify: How do you like to work with institutions?
JG: During the presale process, I get in where people’s technical knowledge starts to taper off. I talk to IT teams about how our middleware works, the capacity of the portal, security considerations and how we accommodate those in addition to some deeper-level talks about how Roles and User Provisioning work.
Pathify: I know clients often come to you with some pretty out-of-the-box requests. What’s your approach to handling those?
JG: It really depends on the situation. Sometimes the Pathify Account Managers really know what customers are looking for, so I’ll go in and say, “I know you are looking to do a Balances Widget from a system we haven’t pulled data from. What is that going to look like? What does that system look like? Do you have API access? Do they even have APIs?” It’s more about trying to figure out how a customer envisions what a specific integration looks like and then figuring out a best-case scenario for what a customer accomplishes with this integration.
Pathify: Clients are typically surprised by how flexible our middleware, Flow, is. Can you talk about some of the benefits realized by using it?
JG: Our middleware is incredibly versatile. If you can pull data out of a third-party system and move it into a neutral space, the sky’s the limit. There aren’t many restrictions related to our capability, and what we can do right now.
Beyond that, if someone is looking for a specific functionality, we try to figure out how many other customers are using it, or if it will benefit a decent chunk of Pathify customers. If it does, that integration becomes incredibly valuable, not only to our current customers, but also to us as a company.
Our middleware is incredibly versatile. If you can pull data out of a third-party system and move it into a neutral space, the sky’s the limit. There aren’t many restrictions related to our capability, and what we can do right now.
Julie Gumerman, Senior Sales Engineer
Pathify: It sounds like you really rely on customers for new custom work ideas where if enough customers want it, we’ll build it. What’s an example of your favorite project you’ve worked on?
JG: One of the coolest pieces I’ve worked on recently is a Starfish Widget from EAB Navigate. It was awesome because we kept hearing Navigate pop up all over the place, and I expected to go through a hefty custom work process after having my first conversation with the customer about it. Suddenly, it turned into several customers needing it so the widget is now on the product roadmap. It was really watching the project pivot from a long, drawn-out process to the product team saying, “We’re just going to build it because people need it.”
Pathify: Yeah, it sounds like our customers are really at the forefront of challenging the status quo in helping to push us to be more innovative. How do you help them to push boundaries?
JG: We’ll walk with them through those boundaries as far as they will allow us to push. If the request will bring value, we’ll do whatever the APIs allow us to do. There aren’t many restrictions outside of what third-party APIs provide.
Pathify: You’ve mentioned Flow a few times. How would you describe what it is and how it works?
JG: Flow is the Grand Central Station of moving data around for Pathify. It has other purposes, in addition to being an integration bus, but its primary purpose is moving information around between third-party systems.
Flow isn’t structurally part of the Pathify portal instance. It’s separate, which means if a customer wanted to, they could use Flow to connect third-party systems without connecting to Pathify’s portal at all, which is pretty awesome. It also hosts front-end resources for customers who complete Flow training. We also see customers build awesome static widgets, which might not involve moving data but really help institutions get important information out to students, faculty and staff.
Pathify: It sounds like there are a lot of great uses for Flow, but what are some of the main challenges institutions try to solve using it?
JG: Usually the challenge comes from a pet project where someone starting Flow training wants to work with a particular system. It’s usually a matter of getting them connected with one of Pathify’s engineers, where we’ll explain the basics of how Flow works. Towards the end of the training, an institution might ask for help integrating their system with AWS or Ethos and want guidance on setting it up by themselves.
Pathify: Are there any creative projects you’ve seen that have surprised you?
JG: One of the coolest projects was actually Cal Arts, which wanted to bring the hustle and bustle of hallways to users taking classes at home during the pandemic. They built a school radio widget and users could play it while navigating the portal, just to get the sense of being a part of a community listening to the same thing. We also did a sports score widget on the fly for the University of Mount Olive where they ended up with something totally unique to their needs. We’ve had a Bible Verse of the Day Widget as well — our customers get pretty creative.
Pathify: How does DIY training work and why is it important?
JG: DIY training is for customers with specific projects they want to build and have free rein to do their own development. Now they want to integrate what they built in a completely disparate system with Pathify. DIY training allows developers to use Flow to build integrations or widgets themselves and then pull data into the portal instance as they go. We have over 26 hours of tutorial content available on demand to walk admins through any possible integration they might want.
Customer Story: University of Northwestern – St. Paul
As a faith-based institution, University of Northwestern – St. Paul (UNW) holds unique requirements for students attending, including a credit requirement for chapel attendance. After vetting other vendors, UNW chose Pathify as its student portal because of its willingness to act as a true partner to the institution.
During Phase 1 of implementation, UNW created a widget displaying a progress bar for chapel credit completion in a given semester using Pathify’s middleware, Flow. The Pathify implementation team’s willingness to think innovatively instilled confidence in John Day, Director of Student Retention, regarding Pathify’s ability to deliver a contemporary student experience.
“Pathify was interested in looking at what our unique needs are and helping us get to that point where other vendors gave us something out of the box and expected us to develop on our own,” Day said.
Learn more about why UNW selected Pathify.
