StepStone Realty has built a successful business around creative real estate. They provide a number of services to help their investor agents close deals more effectively, from short sale processing to mentoring to training. StepStone prides itself on the flexibility it can offer to its agents, compared to more traditional real estate firms.

Problem

However, one consequence of all this flexibility and variety of services is a rather complex fee structure.  Some closings include multiple levels of referral fees, while others have fees for extra processing services or discounts based on sales volume.

Some of the fees and commissions are flat amounts, while others are a percentage commission.  Sometimes the commission converts to a flat fee after a certain threshold is met.  Some fees differ based on prior sales volume.  Suffice it to say, the calculations are somewhat complex.

The StepStone team was calculating all this manually, but the process was time-consuming and error-prone, and most importantly, as the company grew, the manual calculations wouldn’t scale.

Solution

To begin with, we spent time recording all the written rules and their logical flow.  StepStone already had a custom-built application for managing their agents and other key aspects of their business, and we knew we wanted this solution to fit in seamlessly with the existing application.

We built them a form that allows them to enter the key details about each closing (property, agent, sale price, date completed, services used, etc.), and store the details, allowing them to be linked to the agent data already stored in their database.

We converted all the rules for their fee structure to a set of functions within the app, which could take the provided data, look up previous sales, and calculate all the other related fees.  Once this logic was in place, we were also able to provide a preview functionality, where the user could see how the fees would calculate out based on the selected options, and determine if changes needed to be made before saving the entry.

After a few tests runs, we found that no matter how robust the fee calculation logic was, there would always be exceptions.  Maybe a custom service was being provided, or a special discount.  So we added an option to override any of the calculated values in the fee structure.  However, changing the value of one fee required the updating of another fee, so we structured the overrides so that each value could be overridden individually, and the overridden values could be used in the calculation of any related fees.  Thus, even if some fees or commissions did not adhere to the standard formula, we could still calculate the remainder of the structure, rather than forcing the user to manually run all the calculations.

Result

The module allowed each closing to be viewed as an individual report, but we also provide a list view that could be filtered and sorted, as well as exported to a spreadsheet.

In the end, the tedious task of calculating fees and commissions was lifted off the shoulders of the StepStone team, and they were able to focus their energy on what they do best: helping agents and investors close real estate deals.

Our client is a market leader in oil field logistics and transload services.  They own and manage a nationwide network of transload terminals where they store and move millions of pounds of bulk sand, crude, and other materials to and from trucks, railcars, silos, and other containers.  Their services are a critical element in the energy supply chain in North America.

Problem

The client runs transload facilities across the country, with an especially high concentration in the Southwest. At these facilities, they load, unload, and store bulk materials for their customers, primarily frac sand to be used in drilling oil wells. When material is loaded and shipped out from the terminal via truck, the driver is issued a bill of lading. The client manages all of the operations at their terminals with their custom terminal management application, which we helped them build.

All load actions are tracked in the application, arrival and departure weights for the trucks are captured from the on-site truck scales, and a signature is captured electronically from the driver. The application uses all this data to automatically generate a correct and accurate bill of lading, which is printed out and handed to the driver. A copy is also stored in the cloud as a PDF for later reference.

The process is highly efficient and allows them to quickly process trucks at their sites, and maintain uniform processes at every location across the company. In fact, the system worked so well that another company approached our client about licensing their system to manage their own terminals. However, the partner company had certain specific feature sets which they required before implementing the system at their own facilities.

The most significant feature request was an easier way to modify bills of lading after the fact, as well as tracking those modifications. The bill of lading contains a large assortment of data about the load: customer, service company, product, tare and gross weights, purchase order number, driver name, signature, etc. One strategy used in the terminal management system to eliminate data entry errors is to provide dedicated screens for different steps in the loading process. These dedicated screens only allow entering the specific data relevant to that step (entering order data, receiving a new truck, loading the truck, collecting the final weight and dispatching the truck), and a series of statuses ensures that only the trucks at a given step can be accessed on that screen.

While this structure is very effective at preventing errors, on the rare occasion that an error did occur, resolving the issue was a bit cumbersome. A user with administrative access would have to manually revert the statuses on the truck to edit the different fields. As the client’s business continued to grow, even a steady low error percentage inevitably grew to a larger administrative task, and for their partner, it was a non-starter. They needed a way to edit all the relevant details about a truck on a single page.

Solution

Making a single page form with all the relevant fields for a truck is trivial. However, the system provides numerous checks to make sure that the order matches the customer, the job matches the order, the product matches all these things, and so on. Additionally, the quantity for each draft (load event) needed to total up to match the net weight calculated from the gross and tare, and vice versa. Since every piece of data could be modified, every other piece of data needed to be checked in real-time to make sure things still added up. Additionally, there were a series of dependent select fields (drop-down menus), where the user’s choice in one menu would affect the available options in other menus.

The core terminal management system was built as a web application, running in the cloud, backed by a relational database, with the user interface rendered in the browser with HTML. Additional UI enhancements were implemented using JavaScript. However, the level of interactivity required for this page would have been an overly complex mess to implement. Instead, we opted to use Angular.

Angular is an open-source JavaScript UI framework built by Google and used by a wide range of organizations around the world. Angular allows you to define a scope, a set of JavaScript variables. You can then reference those scope variables in your page template, in functions you write to call on that page, and in event triggers. The variables in the scope are shared around the page, so any time the variable is updated, the references to it are automatically updated as well.

We used these capabilities to automatically update the gross tare and net weights based on the total of the drafts, keeping the net weight matched to the sum of the drafts. We built a integration to allow Chosen.JS’s searchable select boxes to interact with Angular scope variables. Any time a value was updated in a drop-down menu (Customer, Order, Job, Product) we could automatically trigger updates elsewhere in the form. When a change in value caused the available options in another select box to be modified, we would pull an updated option list from the API via AJAX.

One particularly challenging component was dealing with transient load sources. The system tracks which container is used to load each draft in the truck. That way, if there is a contamination or other quality issue with the material on that truck, the system can easily tell you where it loaded from, in order to locate and mitigate the source of the problem. However, trucks are often loaded directly from railcars, which by their nature are mobile. Every day, empty railcars are removed from the facility, and full ones arrive to replace them. The system provides a list of railcars, silos, and other containers that are available to load from and have the matching product for the truck. However, if you are editing a BOL from a truck that has already left, the current list of load sources may be different from the list at the time that truck was on site. And if you modify the arrival and departure timestamps for the truck, the list of available load sources will change again. We had to extend the load source API so that you could query based on timestamps and lookup which load sources were on-site during that window of time and contained the specific product at that time (because a container might be emptied of one product, and refilled with another). Any change to the truck’s arrival and departure times would trigger another query to this API, causing the list of available load sources to be updated in real-time.

All of these changes are managed exclusively on the client-side, without modifying the database. Once the user is happy with their changes, they submit the edits to the system. A series of validation checks are run, to make sure the business rules are applied correctly, and the bill of lading is updated in the system. A new PDF is generated and stored in the cloud for future reference.

However, since this modified BOL is different from the document the driver signed, and was handed during dispatch, the modified BOL document does not bear the driver’s digital signature. Instead it contains a note indicating that the BOL has been modified, as well as an attached log, listing all the changes made to the document.

The system stores the original BOL document, as well as every revised version, with the attached change log. Each version can be downloaded on demand from the application.

Result

This project was a huge time saver for the administrative support team tasked with handling these BOL modifications. Changes that were once a considerable headache could be handled in a matter of seconds. Because there were fewer opportunities for error, much of this work was able to be delegated back to the terminal operations team, which dramatically reduced turn around time, since the fix could be made by a manager who was physically on-site, rather than submitted to a queue with a host of other issues to be resolved by the support team, who would previously have to call the terminal and investigate the issue to determine exactly what the correct data would be.

The revision history showing previous versions, and listing the corrections, provided traceability in case of any questions down the road.

Additionally, the same single-page interface also allowed us to implement a “Manual BOL” process. If a facility loses Internet access, they cannot access the terminal management system, since it is hosted in the cloud. However, trucks still need to be loaded and processed. Delaying loads could cause well site operations to stop, which can be extremely costly for our client’s customers, and might even lead to canceled contracts. Thus, if a facility’s Internet access is down, they must revert to a paper BOL form, a copy of which is kept in a file at the terminal. Once Internet access is restored, the paper BOL can be scanned, and the relevant data is entered on the “Manual BOL” screen. This screen is basically the same form as the BOL editing interface, except a new bill of lading is created, rather than modifying an existing one.

Finally, this feature was a non-negotiable requirement for our client’s partner who licensed the system, and implementing this allowed this strategic partnership to move forward. This lead to deploying the client’s custom terminal management system to over 40 locations across the US and Canada, and opening an entirely new revenue stream for the business. It also strengthened the partnership with that client, leading to additional future projects.

Our client is a market leader in oil field logistics and transload services.  They own and manage a nationwide network of transload terminals where they store and move millions of pounds of bulk sand, crude, and other materials to and from trucks, railcars, silos, and other containers.  Their services are a critical element in the energy supply chain in North America.

This client operates transload facilities, where they transfer products between trucks, railcars, and on-site storage containers. They specialize in transloading frac sand for the oil and gas industry, particularly in the Southwest, although they handle a variety of materials at locations all over the country.

Problem

The railcars, trucks, and materials they handle do not belong to the logistics service provider, but rather belong to their clients, who either produce and sell materials or consume them. Either way, they need to move large quantities of bulk materials using multiple modes of transport, which our client facilitates.

The client’s business is not based on the products they handle, but on the handling itself. As such, they bill their clients based on the weight transported, with rates varying based on location, customer, mode of transport, material type, container type (silo, hopper, warehouse, etc.), and various other factors. Some of these rates are set on a sliding scale based on volume. Some include minimum volumes that must be achieved within a certain time frame.

They also bill demurrage fees for railcars stored at their facilities, which vary based on the type of car. Most of these are actually charged by the railroad and passed through to the client. They typically have a certain number of free days, with a charge daily for each day after that threshold.

Many of our client’s customers are multi-billion dollar companies, and their requirements can vary greatly. As such, each contract is negotiated separately and will have different terms.

Because of all this, calculating exactly what each customer owes them at the end of the month is an extremely complex task. Data on every truck to visit each facility was being exported into a spreadsheet, and the accounting department would add all the various calculations, manually entering the more complex variations. But as the business grew, this became too time-consuming, and they simply could not keep up.

Solution

We built them a system where they could enter all the complex details of the billing agreement for each contract. Then we built a report generation system where they could grab all the transactions for each customer, have the fees automatically calculated, and quickly review them. Once reviewed, they would click a button and all the transactions would be exported to their accounting software, and an invoice would be generated. Later, as the client’s business grew, we modified the export to send the transactions to an enterprise ERP system instead.

Result

This system allowed them to recoup lost revenue that would have been missed by the manual process, and easily generate accurate invoices for all their clients with only a couple of accountants, instead of an army of analysts, which they would need at this point.

Our client is a market leader in oil field logistics and transload services.  They own and manage a nationwide network of transload terminals where they store and move millions of pounds of bulk sand, crude, and other materials to and from trucks, railcars, silos, and other containers.  Their services are a critical element in the energy supply chain in North America.

Problem

This transload company contracted with one of their clients to install 4 200 ft silos to store frac sand and more quickly process inbound and outbound loads from one of their facilities. The silo installation included a pit and bucket elevator system for unloading railcars, truck scales and gate valves for loading trucks, and an automation system to control all this equipment remotely from an onsite scale house.

The facility is owned operated by the transload provider, but the silos would be owned by the client and used exclusively for their product. The silos were constructed because this was one of the busiest terminals in the region, with an extremely high volume of trucks.

The facility is located in a small town on one of its major thoroughfares, and the long line of trucks waiting to be loaded had caused traffic blockage for the entire town, much to the annoyance of local residents.

The silos were designed to be managed using an piece of industrial automation software called a SCADA (short for “supervisory control and data acquisition”). This significant investment in mechanical equipment and software promised to increase throughput for the terminal. However, since the SCADA was provided by their client, the transload company had no control over the software, and limited access to its data.

Our client has a custom terminal management application, which we helped them build, and which manages inventory, bills of lading, transload billing, and all other aspects of on-site terminal operations. It also feeds data to report systems used by management and customers to make strategic decisions.

Any loads into and out of the silos needed to be tracked in the terminal management application in order to maintain accurate inventory, and to generate correct bills of lading. Additionally, the terminal management application needed to feed data into the SCADA system about the trucks being loaded through the silos, to ensure the correct product was loaded on each truck.

Solution

The SCADA system implemented at this site had limited integration capabilities. However, it was configured to write out a log of trucks unloaded and railcars loaded to a local MySQL database, in two separate tables. The system also had the ability to consume an XML feed of incoming trucks.

We had previously built the client a custom microservice service in Node.JS. It ran on an appliance installed at each of their facilities, and collected data from truck scales, interfacing with the terminal management application in the cloud through a REST API.

We modified this service, adding a microservice to provide the XML feed the SCADA required, pulling data from the terminal management application. We also added a service which would repeatedly poll the SCADA database for new and updated records in the relevant tables. Any new loads would be translated to the format required by the terminal management system’s REST API, and forwarded to that system, in as close to real time as possible.

Result

This project had a very tight deadline but we were able to execute quickly and deploy our solution within just a few days. Our client’s operators on-site were able to run the automation system and load trucks far more quickly, increasing throughput while decreasing traffic.

The automation system received the truck and product data it needed to correctly assign products. The operations team was able to generate bills of lading through the terminal management application, utilizing all the optimizations already present in that system.

Since all load and unload events occurring at the silos were automatically logged in the terminal management application, they were able to track inventory without manual double entry, saving time and avoiding errors.

The transload provider was able to exceed expectations for their client, and the terminal became the most productive site in the client’s entire logistics network.

Our client is a market leader in oil field logistics and transload services.  They own and manage a nationwide network of transload terminals where they store and move millions of pounds of bulk sand, crude, and other materials to and from trucks, railcars, silos, and other containers.  Their services are a critical element in the energy supply chain in North America.

Problem

The client has a proprietary cloud-based operations management application they use to track all material and asset movements at each of their facilities.  A key part of this process requires capturing bill of lading signatures from truck drivers before they leave the facility. Different facilities require different configurations, based on available equipment, facilities, and staffing.  Some facilities use desktop PCs with a USB signature pad, while others use a ruggedized mobile device with a touchscreen.  Still others use custom-built kiosks with larger touchscreens.  No matter the hardware used, signatures need to be captured and stored in a consistent format, and must be easily retrieved later for auditing and verification purposes.

Solution

Using an open source jQuery signature plugin, and the proprietary SDK from the device manufacturer, we built a single, reusable component which allows signatures to be captured via any method: signature pad, touch screen, mouse drawing, and saved to the app’s datastore as a PNG file.

If the signature pad is installed, impressions are captured in real time, and rendered on the screen.  If the signature pad is not installed, the system will fall back gracefully.  A message informing the user on how to install the signature pad can be displayed.  Meanwhile, the other signature methods are still available.

Result

Our client no longer has to be concerned about signatures when planning deployments.  Any possible situation can be handled with minimal overhead, whether they are using desktop computers or mobile handhelds.  Not only that but some time after this solution was deployed, the transload company began installing kiosks with a large desktop-sized touch screen at certain facilities.  Because of the flexibility of the signature solution, the kiosks were able to support on-screen signature capture without any additional development.  Whether the facility uses touch screen kiosks, handheld devices, or a signature pad attached to a desktop PC, the application is able to handle it seamlessly.  Digital signature capture for Bill of Lading documents will be available in any scenario.

For this project, we worked with a local IT staffing agency that placed contractors with major employers in need of supplemental technical talent and specialized expertise.  They work with businesses of all sizes, filling short- and long-term vacancies.

Problem

Our client was having a hard time requesting, receiving, sorting, and overall managing invoices from their vendors and contractors. They needed a solution to allow their vendors and contractors to submit and manage invoices, all the while having back-office access in case any unforeseen circumstances happen.  They also needed to be able to correlate these invoices with their clients, to make sure they bill properly for everything.

Solution

In order to allow our client’s vendors and contractors to create and manage their invoices that can be accessed by multiple people at the same time remotely, we created a small web app that provided a web interface for third-party vendors to access, as well as a FileMaker interface for back-office access, all backed by a MySQL database. For this project, we used PHP, MySQL, Symfony, JavaScript, jQuery, Twitter Bootstrap, and FileMaker Pro.

Results

The web app has enabled our clients’ vendors and contractors to not only create but also manage invoices on just a single platform and has been rid of the worry that they may have missed the last month’s invoice somewhere in an email thread. 

Client

Locals Know is a social travel application for the iOS and Android platforms. They provide a multimedia virtual tour guide experience for visitors to a new city.  The user has a map view to see all the points of interest and attractions in their vicinity.  Each location has audio, video, and text content to help users get unique insights into the place they are visiting.

Problem

Our client already had robust mobile apps for Android and iOS, which received data from their servers.  However, they were trying to get more users involved who had not yet installed the app.  They needed a way for existing users to share content from the app and have it viewable by their friends in a web browser.

Solution

We worked on a web-based RESTful API used by the mobile applications to pull data from the server.  Much of the structure for the API was already built by a previous developer.  However, the existing code base had several outstanding issues.  First of all, the database schema did not match the intended design of the app, and there were some other issues.  We restructured the database, wrote migrations, modified the API responses, and fixed several other bugs.  Beyond bug fixes, we also added additional API endpoints for new features and helped troubleshoot some issues with the API requests from the iOS application.

As well as dealing with the RESTful API, we built a client-facing web interface to allow users to view this content outside of the native mobile apps.  Using the responsive design features in the Bootstrap Framework, we built this web interface to render on desktop web browsers, tablets, and mobile browsers.

In addition, to support this web interface, and the social nature of the app, we built a custom URL shortener system to aid in sharing content via Twitter and Facebook.  The URL shortener created compact URLs, uniform in length, with no discernible pattern, guaranteed to be unique.

For this project, we made use of PHP, MySQL, Yii MVC Framework, JavaScript, jQuery, Google Maps API, and Bootstrap Framework.

Results

With the improvements we made to the API, the mobile development teams were better able to build out new features for their users.  The web UI and short URLs made it easy for app users to share content from the app with their friends, facilitating a form of viral marketing to help grow the brand.

Our client is a leading asset liquidation company in Texas that provides data center decommissioning, e-waste recycling, and generator removal services that go above and beyond other liquidation companies.  They have serviced numerous businesses like hotels and large enterprises by helping them resell old but still functional equipment at a  good value. They are a green company whose aim is to reduce the e-waste footprints left when equipment upgrades are made within a company.

Problem

The client had a somewhat unique business model, in which they would inventory and process assets from numerous client companies.  They would ensure the destruction of any sensitive or confidential client information, test all equipment, resell it online, and then pay back a commission to the client who owned the equipment.

This model was very appealing to clients, but it presented certain complexities.  It meant the client was still the owner of the asset until final disposition.  Because of the sensitive nature of the arrangement, great care must be taken to protect client data and track all assets, and report inventory effectively.

Meanwhile, in addition to serving these clients, they were also running an eCommerce business, managing online listings, titles, shipping, and everything that comes with that.  They needed to track everything in a consistent manner while processing goods efficiently in order to maintain profit margins.

Solution

We built a custom FileMaker application that managed nearly every aspect of the company’s day-to-day operations.  This included tracking of incoming trucks, pallets, and assets; automatically importing product photos for online sales; ODBC import/export with MSSQL-based eBay listing tool; complex financial report generation; and automated pick and shipping systems.

We also built a web interface, allowing clients to log in and view the complete status of items entrusted to the company in real-time.

During this project, we used FileMaker Pro, PHP, MySQL, MS SQL, eBay Blackthorne, ODBC, rsync, Groovy, UPS Shipping XML API, Java printing APIs, among other technologies.

Results

With the improvements and automation implemented, our client was able to successfully streamline their business processes easily and efficiently and had greatly reduced (if not eliminated) basic system errors that usually came along with the process.