Every day, Design Everest project managers were sending RFPs to a network of architecture and engineering professionals by email, each one using their own templates, their own contacts, their own process. The result was slow, inconsistent, and invisible. The average time to receive a bid was 96 hours. Customers had moved on by then.

When I joined, I identified the close rate (15%, against an industry average of 30%) as the number to move. Working with Sales and Marketing, we formed a clear hypothesis: get a price to a customer faster, close more of them. We estimated a 5 to 7 percent improvement was achievable.

The urgency became concrete when the company set a goal to expand from California into Washington and Texas. Our email-based bidding process, already straining under one state's volume, was not going to hold up across three. This wasn't just a UX problem anymore, it was a scalability risk for the business.

I ran 8 one-on-one interviews with engineers and architects on the platform. Four patterns came back every time: every PM had their own process, communication happened over long email threads, PMs only reached out to partners they already knew (limiting competition), and partners frequently lacked the information they needed to bid accurately, surfacing costly surprises later.

The insight wasn't just that the process was slow. It was that there was no process. What we needed was automated, consistent, and transparent. Those three words became the design brief.

I led the design of Design Hub, a new internal platform built around one core flow: Create, Send, and Award. Project managers could build a structured RFP once, send it to multiple partners simultaneously, and award the winning bid, all from a single place, replacing the email-based process entirely. Partners received complete project information up front, with no back-and-forth required. Incoming bids were consolidated in a single view, making comparison and selection instant.

I also managed the full cross-functional process: aligning stakeholders across Sales, Product, and Engineering, running design reviews, and coordinating through to company-wide launch.

The tool was adopted company-wide as the new standard for running RFPs.

While airlines had adapted the in-flight experience during COVID, the airport itself was largely unchanged, and travelers were noticing. Through interviews with 5 Alaska Airlines customers, one theme kept coming back: the vacation didn't feel like it started until the plane took off. Five out of five said arriving at the airport made them anxious.

The constraint that shaped everything: airlines don't own gate or terminal facilities. Physical redesign wasn't on the table. The solution had to live in the product.

Mapping the customer journey surfaced a clear pattern: travelers already balance cost against departure and arrival times when booking. Crowd size was a third variable they cared about but couldn't act on. Adding it to the existing search, rather than building a standalone feature, meant meeting users inside a behavior they already had.

The data visualization. I tested a line chart first, but crowd data from Google's API comes in hourly increments, discrete buckets, not a continuous curve. A bar chart was more honest to the data format and communicated approximate crowd size without implying false precision.

The name. Getting the label right took longer than expected. Testing ruled out "Airport Busyness," "Peak Travel Times," and several others. "Crowd Size" won, direct, neutral, and immediately understood by all three test participants.

The 2/3 on the visualization became an explicit next step: the chart needed a plain-language label. Small finding, but the kind of specific iteration note that shows the work wasn't done at launch.

View prototype ↗

When customers can't trust the data in front of them, they can't act on it. When they can't act on it, they stop seeing the value in paying for the software. That pattern kept showing up in churn conversations, so a new pod was formed with a single tactical mandate: figure out why customers didn't trust the data, and fix it.

We talked to CSMs, services teams, and customers directly to trace the problem to its source. It turned out to be foundational: contract ingestion. Customers had two ways to get contract data into Zylo, and both were broken. Contract Concierge was a paid, white-glove service where our own team manually entered contract data by hand. It worked, but it took a month or more and was only offered as an upsell, too slow and too limited for most enterprise customers. The self-serve alternative was a long manual entry form with more required fields than most users understood, a lot to get through unless you already knew exactly what you were doing.

I led the design of Contract Assist, Zylo's first AI agent. It gave customers a third way to get contract data into the system: drag and drop a PDF, and the agent parses it for the key contract fields. The concierge service and the manual form were still there for anyone who wanted them, but most customers no longer needed either. Instead of typing everything in by hand, users verify a small set of AI-highlighted fields and approve. That shift made ingestion faster, and because it wasn't manual entry anymore, more accurate too.

This screen predates the Horizon rebuild, you can still see the old design system in it. Designing Contract Assist against those inconsistent components ended up shaping what Horizon needed to fix.

Early on, we tracked how often users edited the fields Contract Assist extracted. The number was under 1%. Product Managers initially read that as a win, the AI was so accurate that people barely needed to touch it.

Usability testing told a different story. People weren't validating the extracted data, they were assuming it was correct and clicking through, even in sessions where a field was obviously wrong. A near-zero edit rate didn't mean high accuracy. It meant automation bias: users had started treating the AI's output as ground truth instead of something to check.

I redesigned the review flow around confidence scoring. Instead of presenting every field as equally certain, Contract Assist now flags the fields it's least confident about and guides users to check those specifically, rather than asking them to review everything, which is what caused the rubber-stamping in the first place, or nothing. The goal shifted from minimizing edits to earning the right amount of scrutiny.

Adoption kept climbing through all 100 days, not just an initial rush, and the old concierge process, which used to take over a month, now handles less than 1% of contracts.

Contract Assist worked almost too well. Once uploading a contract took seconds instead of a month-long concierge request, more of them got uploaded, sometimes the same one twice. A CLM workflow CC'd Zylo's inbox at every step instead of just at signature, a concierge re-processed an order form, two teammates each assumed it was their job. None of it was user error, it was just what happens when ingestion gets easy.

Every duplicate meant a second, slightly different record of the same contract, and every number built on top of it, contract counts, commitment totals, renewal alerts, went quietly wrong. Some customers were running manual, months-long cleanups just to catch them by hand.

I designed detection and resolution as one flow. A pair is flagged if either the contract's key fields match or the uploaded file itself is identical, so a re-uploaded PDF gets caught even when its metadata looks slightly different. From there, a side-by-side comparison shows exactly what's different between the two records, uploader, source, dates, so resolving one takes a single click instead of tracking down whoever uploaded the original.

This is a high-level summary. The full write-up is available on request, happy to walk through the strategy, process, and outcomes directly at saitelbachj@gmail.com.

Zylo customers manage dozens or hundreds of SaaS tools, but the data that would tell them where they're overspending, usage, contract terms, renewal timing, ownership, lived scattered across the platform. Getting a real answer meant pulling multiple reports and cross-referencing them by hand. The insight was often there. Customers just couldn't get to it fast enough to act on it.

Cost visibility and savings are the core of what Zylo sells, but a dashboard-first experience only pays off if the customer already knows what to look for and has the time to dig. That's a real gap between the value we could provide and the value customers were actually getting. Leadership saw AI as the way to close it: instead of asking customers to find the insight, the product could surface it to them directly, and do it in a way competitors weren't.

We'd also already built an MCP integration, a technical connector that let power users query their Zylo data through their own AI tools. But usage data and customer conversations showed a segment of admins who wanted that same value, a plain-English way to ask questions about their SaaS spend, without the technical setup MCP required. As the product leader, I saw an opportunity to reach that segment without a parallel engineering effort: Clarity could run on the same backend already powering the MCP, just fronted by a chat interface built directly into the product.

I led the product and design vision for how AI should show up across the platform. Rather than bolt on a single chatbot feature, we designed Clarity to work two ways: a direct chat interface for open-ended questions, and the same insights surfaced contextually throughout the product wherever a customer was already looking. The goal was to meet customers in their existing workflow rather than create a new one.

Designing for trust mattered as much as designing the feature itself. Every answer linked back to the underlying data in the app, so customers could verify a number rather than take an AI-generated table on faith. Discoverability was a related challenge: rather than leave the chat fully open-ended, we used the prompt library to guide customers toward the comparisons that mattered most, like an Effective License Report that combines usage and cost data no single dashboard surfaced on its own. Advanced reporting had been on Zylo's roadmap for a while; I led the product design and vision here, and this became a meaningful, faster step toward it.

Chat solves the problem for someone who already knows what to ask. It doesn't help the customer staring at a blank input with no idea what's wrong, and that was a real question we kept hearing as customers started their SaaS management journey: where do we even start?

So we put Clarity on the pages customers were already looking at. A panel sits on key pages like Contracts, and opening it surfaces insights Clarity already generated for exactly what's on screen: contracts renewing without a baseline, an unusual spike of upcoming renewals, records that look like duplicates. No question required, the insight is just there, with a real number attached, and a way to keep asking from that exact context.

This is a high-level summary. The full write-up is available on request, happy to walk through the strategy, process, and outcomes directly at saitelbachj@gmail.com.

AI Spend Management shipped as a set of fixed lenses: organization, vendors, actors, budget, entitlements. Each one was built to answer a specific question well, and each one was also a guess about how a given customer's business was organized. Real enterprises rarely matched the guess. A department at one company was a cost center at another and a "pod" at a third, and building a new page for every org structure we ran into was never going to catch up.

So customers built the view themselves, just outside the product. Every spend question that wasn't already a built-in page got finished in a spreadsheet, an export that went stale within a day and quietly became the number the organization actually used. Whoever built that pivot became a bottleneck their own team had to work around.

The product's data sources (spend, vendors, actors, budget, entitlements) already described themselves the same way, labeled by things like vendor, model, actor, and org level. That shared structure meant a report could pull from more than one source at once (cost from spend, seats from entitlements, plan from budget) without the customer ever having to explain how those records related. A general-purpose report builder has to solve that connection problem for itself; here, the product already knew.

That's also why letting Clarity write the first draft of a report made sense. It doesn't answer the question and hand over a black box, it configures the report in the builder's own language (the same measure, dimensions, and filters a person could set by hand) and hands back something the user can still see, edit, and re-run. If a question can't be expressed as a report, it says so instead of faking one.

I designed Custom Reporting: pick a measure, add row and column dimensions, filter, and save the result as a definition that re-runs against live data, so opening it tomorrow shows tomorrow's numbers instead of yesterday's export. The product connects the data itself, so users choose what to measure without needing to know how vendors, actors, and spend records relate to each other.

Reports needed to hold up under real organizational complexity, not just simple one-level breakdowns. Rows nest as deep as the data goes, vendor into team into department into division, so a report stays a single saved view instead of a pile of one-off exports.

Zylo's existing search only searched applications. Vendors, contracts, and payments each lived behind their own page, so finding anything else meant guessing where to look, or asking a CSM. Customers noticed the gap, and it started showing up in competitive evaluations.

I designed Global Search to close that gap: one search that returns matching applications, vendors, and contracts together, labeled by type. Search "Docusign" and see the application, the vendor record, and the contract in one place, instead of guessing which page to search from.

Internal testing before launch surfaced real friction: people tried clicking the keyboard-shortcut hints like they were buttons, a single "X" was doing two conflicting jobs (clear vs. close), and Help Center being pre-selected caused accidental navigation. I fixed each one before launch: shortcut hints became inert with a hover tooltip, a dedicated Close button replaced the overloaded X, and nothing is pre-selected by default. Status badges were added to results too, so a search shows at a glance whether something's active, cancelled, or expired.

Procurement teams manage renewals across dozens or hundreds of vendors, each on its own timeline. Without a single view of what's coming due, renewals get caught late, and negotiations start from a weaker position, sometimes after the auto-renewal window has already closed.

I designed a renewal calendar that shows contract density at a glance: a multi-month heatmap where darker cells mean more contracts renewing that day. Toggle between number of contracts and total contract value to see what's really at stake, then drill into the list below to see exactly which vendors, dates, and dollar amounts are on the calendar.

Spend data lived in scattered reports and one-off exports. Anyone who wanted a portfolio-level read on SaaS spend, savings, or inventory had to go dig for it or build their own view, every time.

I designed the Analytics dashboard as a home base for that data: total annual spend, AP and expense spend, and app counts up top, with spend and savings trends and inventory breakdowns underneath, all in one view instead of scattered across reports.

As the dashboard proved out, I extended it with license utilization and contract renewal tracking, so teams could see who's using what and what's coming due without leaving the page.

Not every team needed the same view, so I designed a widget library letting teams browse and add modules to build a dashboard around what mattered to them.

Accessibility wasn't a single fix, it was a habit. We went through every state of every component, default, hover, focus, disabled, checking each against WCAG standards, and caught what the other missed along the way.

Rather than hand the whole system to engineering at once, we shipped it in batches, so the front-end team could start building while we kept working on the next piece. That kept the system moving instead of stalling behind a single massive handoff.

Same page, rebuilt on Horizon: a consistent color system, spacing, and typography in place of the legacy system's inconsistent, ad hoc styling.