Video: Streamlining Operations: How APIs Help Your Teams Meet Rising Expectations | Duration: 2204s | Summary: Streamlining Operations: How APIs Help Your Teams Meet Rising Expectations | Chapters: Welcome and Introduction (46.284996s), API and Automation (136.465s), Automation Driving Efficiency (231.165s), API Automation Benefits (423.41s), Advanced API Automations (734.615s), Customer Success Stories (1461.005s), Summary and Conclusion (1539.9349s), Q&A Session Conclusion (1691.65s)
Transcript for "Streamlining Operations: How APIs Help Your Teams Meet Rising Expectations": Hello, everyone. If you're already here, welcome to the webinar. My name is Connor. We'll get started in a few minutes here. Just gonna give folks a second to join. Thank you in advance for your attendance. Awesome. Now that we're a couple minutes past the top of the hour here, we'll get started. The session is entitled streamlining operations, how APIs can help your teams meet rising expectations. By way of introduction, my name is Connor Fulton. I'm a staff sales engineer here at Aurora Solar. I've been with Aurora for about four years, and I'm also a certified photovoltaic associate with NAVSUP. My role is at the intersection of working with customers and our product and sales teams, really to diagnose your technical workflow needs and solution with the Aurora feature set, which does include API. We'll have that top of mind today. Working through the agenda, we'll start with taking a look at some industry trends, then we'll dive into what an API is, that's relevance to automating, solar processes. We'll then talk through a couple of examples and recorded demonstrations, and then we'll end with a few customer spotlights and key takeaways. As far as q and a goes, I'll tackle that at the end. Please feel free to, throw questions in the q and a section, and we'll get to those after the presentation. Just taking a look at where we are in the automating solar webinar series. We started with optimizing solar sales, talked about, designing, smarter. Now we'll talk through streamlining operations, and then we'll finish up, next time with accelerating installs. Starting with industry trends and why automation is more important than ever, Aurora really focuses on automation. It's really at the core of everything we develop, and the reason being there is driving efficiency at scale. We're really looking to streamline repetitive tasks with fewer points of manual intervention. Additionally, managing rise complexity with this automation, that includes handling more complex designs a little bit earlier in the sales process, such as solar and storage, multi roof, etcetera, and then accuracy, through everything we do. So that's minimizing change orders, cancellations, any type of costly rework or revisions by automating data capture, shading and analysis, and compliance checks, TPO validation, things like that. You see there in the graph to the right, we are anticipating a bit of a dip with the ITC here in 2026, going away. But it's really important to think about how we can offset the impact of that by automating smartly. And when, the dip comes back into a rise in 2027 and beyond, you've already laid the foundation for automation, and you can scale very easily. Another industry trend here is soft cost still remaining a bit stubbornly high. Hardware has gotten cheaper, but now it's our turn at the rest of the industry to automate where we can and reduce those soft costs. Wood Mackenzie pegs the average solar project cost at $3.36 per watt, and the DOE, has the soft cost making up about 50% of that total, 57% to be exact, and that includes both fixed and variable. We obviously can't do too much about the fixed element, but the variable costs are where we can focus to really offset the ITC impact. And if we assume a company doing 500 installs in the course of a year, averaging some kilowatts, that translates into about $4,000,000 of soft costs over those 500 installs. So we really wanna think about how we can reduce that number. And to that end, we can take a look on the right here where we have a dollar and 31¢ representing, soft costs, and how can we lower that to something like dollar and 12¢? The value engineering team here at Aurora, assumes that the advent of AI for site modeling, auto designer for system design, and other platform automations throughout the platform, including an API, can result in significant reductions in cancellations and change orders, not to mention repeat site surveys. And the API can really help reduce manual intervention on the part of proposal creation, plan set prep, and manual handoffs. So assuming, some of these numbers here that our team has has put forth, that's about a 15% decrease in soft costs. And for this fictional solar business, about $600,000 in annual savings. So really a nontrivial amount if we focus in on those soft cost savings. API is a major part of that picture. Right? How can API automations help? When we think about API, we think more about augmenting and not so much replacing. Right? The beauty of automation is that it does take the monotony out of that kind of work and enables individuals to focus on higher value, higher octane tasks, freeing us up to, you know, focus on more complicated designs or increasing, the velocity of our sales cycles. And let's dive into what an API is before we get into some actual use case examples. An API is an application programming interface. It enables different software applications to communicate with one another. A good way to think of this is restaurant analogy, where you as a Patreon are making an order to a server who's bringing that to the kitchen, who's then furnishing your meal back via the server to your table. And we have this flywheel of orders being delivered and end products being brought back to you. Right? The solar use case is quite similar, actually. Instead of a patron, we have a CRM, like a Salesforce, for example, sending information to the Aurora application, and the API is delivering that information, right, as well as returning it to the CRM. So we have that same kind of flywheel effect. The Aurora API, I just wanna clarify. It is an open API. We publicly document it. We surely free it. And what I'll say is it is indeed available to enterprise customers. So any one on the enterprise plan can work with myself, a member of my team, to diagram an API integration and get started. And with that in mind, let's just take a step back and focus a bit on manual processes. You know, even the best CRMs are gonna have these rights, such as marking and opportunities qualified. However, context and data can end up in different silos, and manual input may be needed. We really wanna reduce how often that is needed. These manual processes can result in more work hours, and duplicate data entry can result in more mistakes. All told, this can slow down sales cycles. This can cause miscommunication and delays and overall slowdown company growth. When we think about what a CRM really could be, how it could be used, sure, it's a platform to store data. But with the API, we can actually send that data between platforms. That's not just limited to Aurora. You may be doing that already, for instance, your accounting software and your Salesforce. Additionally, CRM helps different teams hand over project information to one another. And with an API, we can really gather and bucket that information for different teams and their interests. So a sales team, they'd be interested in avoiding having to enter usage data twice. They can pass that over to Aurora, programmatically, whereas a post sale team might wanna have that design information brought back automatically without having copy and paste. And to that end, project tracking from start to finish is absolutely crucial. With the API, you can be notified when certain events in Aurora occur, such as a performance simulation, a project status change, a contract being signed, a proposal being generated. All of these can then reflect in your CRM so you know exactly where that project is and your platforms are in sync with one another. I'm not gonna go through all of these data points, but you get an idea here of the sheer abundance of data that's available for import into Aurora. So that's the CRM record for sure, but also things like consumption information, even requesting an expert design, or posting a price per watt or flat cost. In terms of exporting out of Aurora, this is also just the tip of the iceberg. But overall project info, proposal assets, a screenshot, for instance, and as we navigate on through the quoted financing, the quoted pricing, the actual agreement link, a copy of the proposal to have on record. There's a lot of use cases here from the API. There are two flavors to the Aurora API. There's the sync API, which serves for this basic data transfer of the CRM record, passing data back and forth all the way on through to retrieving a plan set PDF. And then there's also a more advanced API automation set in our design API, which we'll get into as well. The design API allows you to actually take design actions, via API from your CRM, such as triggering an AI run, panel placement, so on and so forth. We also encourage you to scan that QR code to just download a one pager summarizing a lot of these automations. We'll also show it at the end, and I'll be illustrating visually as well. To that end, let's start by taking a look at some basic API automations. This workflow here is a common use case that we see here in Aurora, where in presale, the consultation, and the post sale phase, we all see a bit of API, involvement. So on the presale side, we might see a lead entered, a lead qualified. The API can then create that project programmatically, pass usage data, and actually request an expert design service model. During the consultation, a rep can link directly from their CRM into Aurora to present the proposal, confirm energy usage, show the design, quote effectively, and sell the project, all leading up to post sale data retrieval. So you see that blue is now flipped. It's on top. That's indicating it's pushing to the CRM in gray. All of that energy usage confirmed design info, pricing info, screenshot asset, and proposal. And now we'll actually get into a demonstration video that we'll pull up that illustrates this in a Salesforce environment. Jumping into the Salesforce demonstration environment, I'm gonna start by just reviewing my opportunity and ensuring that my customer data is there already. And then we'll go ahead and create an Aurora project, assuming this is qualified. We're gonna go ahead and just ensure that Sammy Solaris' details are in there, and then we'll create the Aurora project. With that created, we can now click into the project record here in Salesforce, and we actually can click out into the Aurora environment. So this is obviously one very nifty example of being able to navigate directly into, Aurora from the CRM. And now we can navigate into the consumption profile where I already have this homeowner's energy profile. And notice how in Aurora, if I go to energy usage, we actually don't have anything quite yet for energy usage or bill values. So what I'm gonna do is I'm gonna go ahead and push this consumption to Aurora. I'm gonna push the consumption profile by clicking this button, and then our consumption is already passed to Aurora. So if I were to refresh this page in Aurora, we should see some usage data already populated without me having to key this into Aurora. And we also will see those associated values for every single month that we have the data passed in for. If I needed to make any changes to this, for instance, if February was, 1,300 kilowatt hours, we'll go ahead and do that. 1,300 in the app, but, of course, it only shows ten ninety here. So why don't we pull that consumption? Right? So this is really good for updating and keeping a central source of truth, if the rep is, you know, making a change to that consumption profile in the home. Now we can navigate back into the overarching project. Maybe we want to pass through a project status. So right now, the product status is blank. We don't have any product status here in Aurora. So why don't we just say, we've got here a standard design requested. That's all we're looking to do is just apply that status into Aurora. Now when I refresh this page, we see that standard design requested. Speaking of which, we can go ahead and actually push through an expert design request. So by clicking request design, I can specify thirty or a hundred eighty minutes, and then I can go ahead and hit submit. Now we'll want to actually pull the Aurora design information and get a screenshot asset based on the design that's been completed. So assume that the designers gone ahead, laid down panels, created this nice design, strung it, etcetera. And now we're ready to grab this information, which we see in the platform as, you know, about 9,200 kilowatt hours, of annual energy. Nice looking 7.5, kilowatt system. So we'll start by working within the CRM here to just go ahead and snag those Aurora design details. Design one is my primary design. I wanna go ahead and make that the primary. And I wanna get assets. So here's our screenshot, and this is now going to live in our CRM. And if we were to go into our project here, refresh, take a look at our designs, we see we have a design here that has our, production right there. It has our each roof face, pitch, panel, mount, our system size, DC and AC, link to that design, as well as our price per watt, and our total system cost. So this is really just the tip of the iceberg as to what can be pulled from Aurora. But you get the idea, the screenshot, basic design info, pricing info, and that complements well what we're doing presale, porting over information as well. Awesome. Thank you all for your attention on that. And like I said, if any questions came up from that demonstration, feel free to throw them in the q and a. Now that we have the table set of basic sync API data transfer back and forth, we'll level up a bit here and talk through some advanced API automations. Taking a look at this workflow, the top row is gonna look pretty similar to what we just covered. Right? So that's the lead profile being entered and qualified, the CRM record harmonizing with Aurora, energy usage being transferred. Where it gets a little bit more nuanced here is we're looking at a workflow in which Aurora AI and panel placement with AutoDesigner are triggered via API from your CRM, which is a really exciting new use case. It opens up all sorts of automation possibilities. So if we look at the presale site model row, the first step there is checking for lidar and imagery. There's two ways that we can accomplish this. First off, we can send a webhook to your CRM when lidar and imagery are loaded. So that's one way for your CRM to know that lidar and imagery are present. We also have a dedicated API call that your CRM can make to Aurora to check on that lidar source and the imagery source as well. In case you weren't aware of this, lidar and imagery are required for an AI run to occur, so you're gonna wanna know about that ahead of time. If indeed lidar and imagery are present, you can go ahead and trigger AI site modeling via API from your CRM. If not, the advice there would be to request an expert design service model so you do get a site model somehow, some way. Then when you have a site model completed via API, we can stay on this programmatic track. And in presale system design, you see pink there, that's the design API. You can place fire pathways according to our HJ database and then place panels via API as well. We have two ways of panel placement, energy target and max fit, which we'll see in the demo video shortly. Energy target will be a set kilowatt, hour number, and the max fit will be a max fit according to TSRF, specs of your choosing. And then an irradiance analysis can be triggered via API to generate module level radiance data and performance simulation to tie it all up. Right? So we'll pause the, the workflow visual here, and we'll actually go ahead and show another, video demonstration as well. And now we'll take a look at some of our most advanced API automations. So I want you to be thinking about the earlier example of the platform automation, running AI roof, and then also placing panels with auto designer. Right? So these are some things that we are doing to to automate the design process in Aurora. But now we'll actually hop into Postman. And within Postman, which is, by the way, a demonstration environment for advanced API testing, we have the entire Aurora API library that we could test. And I'm particularly interested in showing you all the AI roof post request. So what this is doing is it's saying, hey, Aurora. In this tenant and on this design, please go ahead and run AI roof. So this could be just like in Salesforce when I clicked click request Aurora expert design. This could be generate Aurora AI design. So I'm gonna go ahead and send that through. This was accepted, so our site model is kicked off. In just a few seconds, we know that we're gonna have a returned, AI, site model. We'll then wanna go ahead and place fire pathways just like we would do in app. This could be a place fire pathway button click. And then lastly, our auto designer call, which I'm running in the energy target mode. What energy target mode is allowing me to do is specify 13,000 kilowatt hours. Alternatively, we could do max fit. Regardless, I'm able to specify the solar panel I want. This is the ID in the Aurora Solar database as well as the inverter. I'm using a microinverter. Our preferred orientation, and then a laundry list of other specs as well, such as minimum SAP and TSRF, which I'm might actually increase to 78% just for the fun of it. And we have a wide open azimuth range. Obviously, we could change that if we wanted to eliminate north facing roofs, for example. But I'll just go ahead and send that through. And these three calls right here, the AI run, the fire pathway, and the auto designer can be ran in a waterfall. And they're typically also followed up by a radiance analysis and a performance simulation run. So this allows you to then pull in, everything that you would like pertaining to the design before a appointment has even occurred. Now let's return to Aurora Solar, and let's take a look at the consequence of those API actions, those advanced API automations. So upon refreshing this page, I'm already seeing that there is a site model created as well as panels placed and our fire pathways. So this is a a really solid looking design, 10.25 kilowatts that I completely controlled via API. So this really opens up a lot of use cases. For instance, if you're wanting to, maybe even have a design created before an appointment and you just wanna have a rep click a button in a CRM, voila, forty five seconds later, they have a design that they can walk into in Aurora Solar. Awesome. Thank you all for your continued attention there. I see the q and a is pretty active. Thank you for your questions. I'll we'll get to them at the end. I promise. So thank you for that. Now that we've taken a tour through both basic and advanced API automations, Worth just taking a look at a couple customer storylines here. Empower Solar, for instance, reduced their manual error rate from 50% to 0% with the HubSpot integration. Actually, I think that was one of the q and a questions. So there's your answer. HubSpot totally fine with API. That translated into forty five minutes saved, per project just by automating, the data transfer and reducing, manual data entry, duplicated data entry, and so on. Castleman Solar had a similar reduction 10% in manual errors by automating design requests via API and eliminating that data entry that resulted in two hours saved per project because it actually extended into how they, send through plan set requests as well. So being able to populate, all of the design request fields via API, proved to be really valuable for Castleman. And, again, this is all digging into that soft cost, bit that we're trying to bite off here. Moving into a summary here and some key takeaways. It can be a little overwhelming at first, especially as I'm working there in Postman and there's a lot of different code being thrown around. I really want to just simplify here for everyone. Start with scheduling a meeting either with your account executive at Aurora Solar, if you're not currently in enterprise plan, or your account manager if you are, and you can meet with the team to discuss goals. Chances are myself or a teammate of mine will also join that call where we'll diagnose your needs, map out your workflows, just kind of identify some quick wins that can be had. We're obviously gonna apply best practices with hundreds of other solar companies who've already automated, and then we'll launch by starting small, measuring impact, and expanding that over time. Just another way to kind of view how we, you know, would recommend getting started is is really focusing on process. Where are the bottlenecks? How can we dial in and be a little bit more optimized for that scalability? And then just try a couple of initial automations, maybe something as simple as just harmonizing the CRM record and just benefiting from that avoided, data entry to start. And then iterating and improving over time so we can get a little bit more nuanced with the entire flow. We can use tools like Lucidchart or Miro board to visually illustrate, kind of like a crawl, walk, run, and make sure that those quick wins are followed by iteration. In terms of preparing for what's next and looking into 2026, it's all about connecting those systems seamlessly. So using these APIs to integrate, every part of your value chain without that manual data entry, this will in turn, obviously, eliminate friction and cut out repetitive steps. That'll just expedite cycles even more and keep those teams moving. Scaling is smarter, like I mentioned. You don't wanna bite off more than you could chew to start. Even those small, API tweaks will compound over time into those major time savings, all the while reducing risk, data no longer ending up in different silos, manual processes being limited, and standardization across the entire life cycle. And future proofing growth, it's as much about thinking about, 2027 and beyond as it is, you know, 2026. We have those new tools working for us, and they're well oiled machines, going into the busy periods. And now we're on to q and a. There's a lot of activity here in the q and a. So just give me a moment here. I'm gonna scroll down to the beginning. For all who mentioned the QR code, expiration, check the chat. Member of our team provided updated links. Thank you for bearing with us there. Jose asked, does Aurora use API to retrieve weather data to perform, the radiation simulations? Great question. You actually are not able to override a weather dataset via API. What the API will do is when it runs a performance simulation, it'll use the dataset that is your tenant default or the default on that project. Right? So, whether it's team y three or PSM three, that is just going to be localized in the application. So whatever you are normally having as your dataset will, persist through the API. Joe asked about Aurora having an API with AccuLink CRM. I myself have not heard of AccuLink CRM, but that's where we just can go back to Aurora being, an open API. So what I'd recommend is just reaching out to your contact at AccuLinks and possibly send them our API documentation, which we can make available here today, to get their take on their ability to, develop against our our API. But the short answer is yes because it is an open API, so possibilities are endless to that point. Thank you, Joe, for the question. Ariel asked, for sales orgs using high level, would we need the EPC to set up the API? I'm not sure if that's in reference to go high level, the CRM. You know, oftentimes, with Aurora, you do see an EPC as kind of the parent organization and sales orgs as subtenants within that kind of umbrella org. In that case, you'd probably wanna ask your EPC, are you already, you know, working with the Aurora API? If you are wanting to develop independently, there's not already an existing API connection, that is a conversation that that we can have as well. There are some capabilities there to to work with your CRM. Short answer, check with their EPC first, and and we can kinda go from there. Sebastian asked about HubSpot. Yes. HubSpot, all good there. Cam asked about, is there a way to limit designs by sun hours specifically? ASA and TSRF are options for module placement. What about total sum hours? Short answer is, you're not able to control it by total sum hours, but rest assured, there's enough kind of levers in that panel placement API as it pertains to TSRF minimum contiguous panel count, azimuth range, even, like, tilt degree for flat roofs, that you can kind of solution towards, you know, a similar optimization point. I'll say this, the Aurora app does not optimize via sun hours. So just by virtue of that, the API does not as well. But there are definitely paths to work towards, an annual production target that you're looking to have. Monica asked, what is the wait time for a proposal? It's a great question. Our expert design service will complete a site model request. They have two SLAs, standard, which is a hundred and eighty minutes. Usually, that comes back in forty five to sixty minutes. And then expedited, which is thirty minute SLA, that'll jump to towards the top of our team's queues, and that often comes back in as fast as twenty minutes. What we're driving out there is, you know, if you're wanting, kind of a more sure bet to get the site model back and not having to rely on both lidar and imagery to be available, EDS as we call it in shorthand, expert design service, is a really good option. Just wanna caveat, they're not a proposal build service. So what I am referencing is is simply the turnaround time of that site model. Then you can hop into sales mode and finish your proposal, kind of in a self serve nature. Matthew, you mentioned you joined about ten minutes late. You're asking if this is a separate CRM or app that we're offering. This is, specifically an API to act as connective tissue with your existing CRM. Aurora does not have, kind of a classic CRM to offer, but we pair really nicely with your existing CRM, so that you can push and pull any kind of data that you've seen illustrated in this presentation. But just wanna be clear, not a CRM, just more so an API connection. Awesome. Jose, you asked about additional details for the radiance analysis approach. My associate, John, gave you a link to our methodology for that. It is dovetailed with our overarching performance simulation. Monica or Luis, excuse me, you asked if Postman is connected to the Aurora portal, or is that separate? Yeah. Great question. I should have clarified a little bit more clearly. That's a back end tool, that can be used to simulate API calls. So that's why I used it in this demonstration. Postman is really effective for developers to kind of stress test an integration. So it it may be used as a prelude to a full build. But I do just wanna confirm that with all that logic, would then be transferred into an actual production demo or excuse me, production development environment, on your side. Awesome. Imran asked if there's any demos or tutorials we can refer to for automating solar design through the CRM. My associate John is gonna be pulling something together as a lead behind for after the event, so stay tuned on that. Monice, you are just confirming here. API automations are basically to help with the efficiency of the data from the CRM into Aurora. Couldn't have said it better myself. That's a a really good summary. We wanna just think about preventing data silos. We wanna think about preventing duplicated data entry. So, you know, if you have a rep making a change in your CRM or Aurora, it proliferates across both platforms. And it is go high level use, which is great. Go high level integrates the Aurora to the extent that the developer on your side can use our APIs to make that bridge. The APIs are there to be developed against. So, effectively, yes. Zoho, Daoyang is, also available in the sense that Zoho can develop against our APIs as well. Jeremy, you asked if there's an added cost to basic and advanced API integration. It's actually a great question. The basic, sync API is part partial to the enterprise plan. The design API, because it is so nuanced, it does have a slight elevated, credit cost. That's the kind of thing that we would just wanna make sure actually is relevant for your flow. And then an account executive or account manager can work with you on the economics of baking that into your contracts with Aurora. Awesome. Jose, you asked about sending a contact, to evaluate a modeling simulation approach. Our our team will make note of that. What I would recommend, Jose, is that you reach out to your Aurora representative, your account manager namely, and they can pick up that conversation. Awesome. And I think that that more or less answers the q and a. I'll hang tight here for another thirty seconds or so just in case anyone has any leftover questions. But in closing, I just wanna say thank you all for your attendance, and your attention, your engagement. It was awesome to to meet you all today, and best of luck for the rest of the calendar year here with Aurora Solar. Take it easy. Bye bye.