Skip to content
Build log

Published 12 min read

Venture building

How we rebuild the installed base before the first service reminder

Customers who already own your equipment are often the nearest new revenue. We rebuild the installed base from every ERP generation, and reminders go only to owners of products still in production, ten years back at most.

Contents
  1. Why the installed base comes first
  2. Why we rebuilt before we mailed
  3. How we worked
  4. An invoice names a buyer not a device
  5. The loop
  6. The service visits without a device
  7. Quotes that looked like sales
  8. From one list to a service system
  9. The economics
  10. Rules that protect the record
  11. Calls our founder made
  12. What it unlocks
  13. Advice for an equipment business

The oldest database listed more units than the sales history could explain. Many of those documents had never received the flag that marks an order as placed, which made them quotes rather than sales. A device record built on that table would have held equipment that was never delivered. The next system had the same trap, and its records cover the customers we contact.

We caught it in analysis, before the import. In three weeks we joined nearly thirty years of sales records into one record per device, so that every check runs against the full history. Customers buy this kind of equipment once and run it for many years, and much of it is never put on a maintenance cycle. That is revenue a business has already earned the right to, and it can start long before the next new sale closes.

The records sat in three ERP generations, the oldest a retired in-house database from the late 1990s. We recovered it, joined it to the two systems that followed and rebuilt the installed base device by device. Every device now carries its own due date, and the reminder sequence is built into the same record. Contact is narrower than the record. Reminders go only to customers whose products are still in production, ten years back at most. The upside is recurring maintenance revenue from customers who already own the equipment.

What changes in the record, device by device.

  • Oldest records
    Extracted and loaded into the client’s data platform on the same day
    Usable for matching and checks
    Before
    Locked in a retired in-house database
    After
    Queryable tables with checked keys and references
  • Unit of the installed base
    Serial number and site are attributes of the record
    Service can be planned per device
    Before
    Invoice lines per customer
    After
    One permanent record per sold device
  • Maintenance status
    Last service or purchase date plus the service interval
    Due dates set the order of contact
    Before
    Unknown per device
    After
    Due date and uncertainty level per device
  • Sales timeline
    Three sources, one schema
    Full history for checks, contact limited to ten years
    Before
    Split across three systems
    After
    Late 1990s to today in one view
  • Rebuild
    Nothing is patched by hand
    Rebuilt without manual work
    Before
    Manual exports
    After
    One command, identical result on each run
  • Customer contact
    Replies update the device
    Only products still in production, ten years back at most
    Before
    No reminder sequence
    After
    Three mails and a call, drafted, driven by the device record

Why the installed base comes first

For many equipment businesses, equipment already sold is the cheapest growth available.

These customers cost nothing to acquire. Customer, address and device already sit in your records. They once trusted you with a large purchase, and a service offer starts from that relationship rather than from a cold approach. A sale arrives once and the next order may be years away, while service arrives every year and carries cash between sales. McKinsey’s 2017 article Industrial aftermarket services: Growing the core reports that, across industrial companies, service and parts often earn higher margins than new equipment. That is a general finding, not a figure from this project. Whoever services a device is also often first in line when it needs replacing.

Every year that passes, devices move sites, find another service provider or reach the end of their life. None of that shows up on an invoice, yet the base you could serve shrinks quietly.

Value driver tree for installed-base service Value driver tree. Service revenue per year equals serviceable devices times take-up rate times visits per year times price per visit. What moves each driver: cleaning device records, confirming sites and removing retired devices. The right message at the right time in small batches with an easy reply. An interval per product family, where the contract wins. A travel surcharge or route bundling for far sites. Minus the cost to serve: technician-days times full day cost plus travel. Capacity is the ceiling, because take-up can only grow as fast as bookable technician-days. Where service revenue comes from Service revenue per year Serviceable devices in use, reachable, end customer Take-up rate share that books a visit Visits per year set by the interval Price per visit per site, not per device × × × Clean device records, confirm sites, remove retired devices Right message, right time, small batches, easy reply Interval per product family, contract wins Travel surcharge or route bundling for far sites WHAT MOVES IT DRIVERS MINUS COST TO SERVE Technician-days × full day cost + travel and overnight stays Capacity is the ceiling: take-up can only grow as fast as bookable technician-days. Value driver tree for installed-base service Value driver tree. Service revenue per year equals serviceable devices times take-up rate times visits per year times price per visit. What moves each driver: cleaning device records, confirming sites and removing retired devices. The right message at the right time in small batches with an easy reply. An interval per product family, where the contract wins. A travel surcharge or route bundling for far sites. Minus the cost to serve: technician-days times full day cost plus travel. Capacity is the ceiling, because take-up can only grow as fast as bookable technician-days. Where service revenue comes from Service revenue per year DRIVERS Serviceable devices in use, reachable, end customer WHAT MOVES IT Clean device records, confirm sites, remove retired devices × Take-up rate share that books a visit Right message, right time, small batches, easy reply × Visits per year set by the interval Interval per product family, contract wins × Price per visit per site, not per device Travel surcharge or route bundling for far sites MINUS COST TO SERVE Technician-days × full day cost + travel and overnight stays Capacity is the ceiling: take-up can only grow as fast as bookable technician-days.
Service revenue as a value driver tree: serviceable devices, take-up, visits per year and price per visit, minus the cost to serve.

Why we rebuilt before we mailed

Mailing every past buyer would have been the fastest start. We ruled it out early. Records from decades ago are not a mailing list, and contact reaches back ten years at most. Within that window, old addresses bounce, retired devices get reminders, and a wrong mail costs trust with a customer who knows better. Chasing new buyers would grow the base, but each of them costs money to win and waits on a long sales cycle.

So we rebuilt the installed base first and planned contact in small batches. That meant a slower start with a more reliable list. It cost a few weeks of data work before the first reminder, and technician capacity sets the pace. In return, every reminder names the right device, site and due date, and every reply makes the record better. Both costs are smaller than a campaign that damages trust with the customers you most want to keep.

The service list holds business and public-sector customers. Mails go only to addresses collected with a purchase or a service, stay on the service of the equipment bought and carry an opt-out. The closing call is only about due maintenance of the customer’s own device. Customers can object at any time, an objection ends all further contact, and open tracking is switched off.

How we worked

The Capcelerate team did the work, with AI as part of its toolkit. The live ERP is JTL-Wawi, which we read through a read-only database user and never wrote to.

The two older systems entered the client’s data platform as separate, additive tables. Existing production tables stayed untouched, which we checked by comparing their row counts before and after every load.

Each structural choice went onto a written decision sheet with our recommendation, and our founder ticked, amended or overruled each item. The work took three weeks.

Three ERP generations, one device record Data lineage. Three sources feed a reconcile step and then one record per sold device. Generation one: a retired in-house database from the late 1990s, which holds serial numbers on order lines and a delivery address per document. Generation two: a commercial ERP, loaded as history, which holds invoices, the customer master and past maintenance invoices. Generation three: JTL-Wawi, the live master, read-only, with current orders and delivery addresses. The reconcile step filters quotes, matches customers on name and postcode, uses a reviewed list of maintenance items and lets the delivery address decide the country. The device record holds a permanent ID, model and purchase date, site, serial number, segment, last service and due date. The full history serves matching and checks. Contact covers only products still in production, ten years back at most. Three ERP generations, one device record GENERATION 1 In-house database Retired, from the late 1990s. · Serial numbers on order lines · Delivery address per document GENERATION 2 Commercial ERP Exported and loaded as history. · Invoices and customer master · Past maintenance invoices GENERATION 3 JTL-Wawi Live master. Read-only access. · Current orders and invoices · Delivery addresses RECONCILE Quotes filtered out Customers matched on name and postcode Maintenance items from a reviewed item list Delivery address decides the country ONE RECORD PER DEVICE Device ID permanent, never reused Model and purchase date from the invoice line Site provisional until confirmed Serial number attribute, if known Segment end customer, reseller, export Last service linked service events Due date last service plus interval Full history for matching and checks. Contact only for products still in production, ten years back at most. Three ERP generations, one device record Data lineage. Three sources feed a reconcile step and then one record per sold device. Generation one: a retired in-house database from the late 1990s, which holds serial numbers on order lines and a delivery address per document. Generation two: a commercial ERP, loaded as history, which holds invoices, the customer master and past maintenance invoices. Generation three: JTL-Wawi, the live master, read-only, with current orders and delivery addresses. The reconcile step filters quotes, matches customers on name and postcode, uses a reviewed list of maintenance items and lets the delivery address decide the country. The device record holds a permanent ID, model and purchase date, site, serial number, segment, last service and due date. The full history serves matching and checks. Contact covers only products still in production, ten years back at most. Three ERP generations, one device record GENERATION 1 In-house database Retired, from the late 1990s. · Serial numbers on order lines · Delivery address per document GENERATION 2 Commercial ERP Exported and loaded as history. · Invoices and customer master · Past maintenance invoices GENERATION 3 JTL-Wawi Live master. Read-only access. · Current orders and invoices · Delivery addresses RECONCILE Quotes filtered out Customers matched on name and postcode Maintenance items from a reviewed item list Delivery address decides the country ONE RECORD PER DEVICE Device ID permanent, never reused Model and purchase date from the invoice line Site provisional until confirmed Serial number attribute, if known Segment end customer, reseller, export Last service linked service events Due date last service plus interval Full history for matching and checks. Contact only for products still in production, ten years back at most.
Three ERP generations feed one installed-base record per device. Data lineage of the build. Sources: ERP exports and a recovered in-house database.

An invoice names a buyer not a device

A sales invoice tells you who paid. It does not tell you which device is still running, or where. The buyer may be a procurement office while the devices stand at three different sites, and a reseller may have passed some of them on. Others were shipped abroad or have been retired.

So we stopped treating the invoice as the unit. Every sold device received its own permanent ID, minted once from the invoice line and its quantity. A line with four units creates four records.

We deliberately did not key on the serial number. Serial numbers arrive late, in varying formats and with typos, and for old equipment some will never arrive at all. Many service businesses handle assets the same way: the asset gets its own number, and the maker’s serial number becomes an attribute.

The maintenance state lives on the device, while the mail goes to the customer as one message per customer and model family. A customer with six devices at one site receives one reminder, not six.

From one device record to a due date and a contact sequence Timeline for one device. Only devices of products still in production, ten years back at most, enter the contact sequence. The clock starts at purchase or the last service. After the interval set per product family, the device is due. Mail 1 sends a reminder and offer, mail 2 follows about three months later, mail 3 about two months after that asks for a one-digit reply, then a call, then a pause until the next cycle. Replies update the record: book a visit resets the clock, serviced elsewhere keeps the device marked in the base, retired or moved removes it from the loop while keeping its history. Uncertainty levels: low for devices bought or serviced in the last three years, medium when the last known event is three or more years ago, high for devices bought over eight years ago and never serviced. For high, mail 3 asks whether the device was retired. One device, one due date Contact only for products still in production, ten years back at most Start purchase or last service Due date interval reached Mail 1 reminder and offer Mail 2 about 3 months later Mail 3 one-digit reply Call then pause interval by product family REPLIES UPDATE THE DEVICE RECORD 1 Book a visit Service event resets the clock 2 Serviced elsewhere Stays in the base, marked 3 Retired or moved Leaves the loop, history kept UNCERTAINTY BY AGE OF THE LAST KNOWN EVENT Low bought or serviced in the last 3 years Medium last event 3 or more years ago High bought over 8 years ago, never serviced From one device record to a due date and a contact sequence Timeline for one device. Only devices of products still in production, ten years back at most, enter the contact sequence. The clock starts at purchase or the last service. After the interval set per product family, the device is due. Mail 1 sends a reminder and offer, mail 2 follows about three months later, mail 3 about two months after that asks for a one-digit reply, then a call, then a pause until the next cycle. Replies update the record: book a visit resets the clock, serviced elsewhere keeps the device marked in the base, retired or moved removes it from the loop while keeping its history. Uncertainty levels: low for devices bought or serviced in the last three years, medium when the last known event is three or more years ago, high for devices bought over eight years ago and never serviced. For high, mail 3 asks whether the device was retired. One device, one due date Contact only for products still in production, ten years back at most interval by product family Start purchase or last service Due date interval reached Mail 1 reminder and offer Mail 2 about 3 months later Mail 3 one-digit reply Call then pause REPLIES UPDATE THE DEVICE RECORD 1 Book a visit Service event resets the clock 2 Serviced elsewhere Stays in the base, marked 3 Retired or moved Leaves the loop, history kept UNCERTAINTY BY AGE OF THE LAST KNOWN EVENT Low bought or serviced in the last 3 years Medium last event 3 or more years ago High bought over 8 years ago, never serviced
How one device record becomes a due date and a contact sequence. Timeline of the reminder logic per device.

The loop

Every step of the build followed the same cycle.

  1. Recover: copy the source, never touch the original, and rebuild everything from scripts.
  2. Reconcile: match customers, items and dates across systems, and make every mismatch visible.
  3. Rebuild the device record: mint IDs, attach sites and service events, and compute due dates.
  4. Check: run the checks and confirm that the rebuild converges on the same result.
  5. Decide: put open questions on the decision sheet for our founder.
  6. Contact: send in small batches within the contact window, each approved before it goes out.
  7. Learn: let replies update the device record, so the next batch starts from the corrected list.

Steps one to five ran many times in three weeks. The speed came from one rule: nothing is patched by hand, and everything is rebuilt.

Inside the rebuild step, every record passes the same gates in the same order. Quotes drop out, parts never become devices, and an unclear customer match goes to a person instead of a guess.

Match and merge pipeline ERP exports from three sources pass three checks. Order placed? If no, the document is a quote and is dropped. Device item? If no, it is parts and not a device. Customer match? If ambiguous, it goes to a review list for a human decision and returns when resolved. Matched lines mint one device per unit. Then sites are attached, with the delivery address winning, and service events are attached explicitly or derived. If an event covers more devices than its capacity, it gets a review flag. Checks run on counts and references. If two rebuilds produce the same hash, the due list is published. If not, the run stops. Match and merge, with review ERP exports three sources order placed? no quote, drop yes device item? no parts, not a device yes customer match? yes mint devices one per unit ambiguous review list human decision resolved attach sites delivery address wins attach service explicit or derived within capacity? no review flag yes run checks counts, references same hash? yes due list no stop, investigate key path human review or stop Match and merge pipeline ERP exports from three sources pass three checks. Order placed? If no, the document is a quote and is dropped. Device item? If no, it is parts and not a device. Customer match? If ambiguous, it goes to a review list for a human decision and returns when resolved. Matched lines mint one device per unit. Then sites are attached, with the delivery address winning, and service events are attached explicitly or derived. If an event covers more devices than its capacity, it gets a review flag. Checks run on counts and references. If two rebuilds produce the same hash, the due list is published. If not, the run stops. Match and merge, with review ERP exports three sources order placed? no quote, drop yes device item? no parts, not a device yes customer match? ambiguous review list human decision yes mint devices one per unit resolved attach sites delivery address wins attach service explicit or derived within capacity? no review flag yes run checks counts, references same hash? no stop, investigate yes due list key path human review or stop
Match and merge pipeline with its review steps: order filter, device filter, customer match, device minting, sites, service events, checks and hash convergence.

The service visits without a device

One thread shows how the loop works in practice. After the first build, a handful of past maintenance visits pointed at customers with no device purchase on file, and the system could not say which equipment had been serviced.

Our first guess was that these customers had bought before the second ERP generation began, which that system could not know. Testing the guess needed the oldest records, and they were not yet available.

When the retired database arrived, we extracted it on a Mac with open-source tools, without the original software. The extraction checks that keys are unique, that every order line has an order and that every order has a customer, then loads the records into their own tables.

Some of the orphaned visits found their devices at once. The others stayed open with a likely reason attached, such as a purchase through a reseller or spare parts only. We did not guess them into the base, and they wait on a review list.

The same pass taught a matching lesson. Customer numbers can collide across ERP generations, with one number belonging to different people. We matched on name and postcode instead. Where those two could not settle a match, a person decided from a review list.

working notes · thread

  1. Team

    The old system shows more units for those years than the sales history suggests.

  2. Capcelerate systemSystem

    Many documents never received the “order placed” flag. They are quotes, not sales.

  3. Team

    Then only invoiced orders create devices. Does the next ERP have the same trap?

  4. Capcelerate systemSystem

    Yes. Quotes there carry their own number prefix. Both filters are now part of the rebuild checks.

Recreated from our working notes. Details anonymised.

Quotes that looked like sales

In the oldest system, quotes and orders shared one table, and only one flag told them apart. Without that filter, the installed base would have included equipment that was never delivered.

The later system has the same trap, with quotes under their own number prefix, and its records fall inside the window we contact. A reminder built on the raw table there would have named a device the customer never received.

The recovery paid off in another way too. Older systems hold detail that later exports sometimes drop, such as serial numbers on order lines. For the checks, old records add detail as well as history.

From one list to a service system

Once the device record held, the build widened.

Sites. A billing address is not an installation site. Every customer starts with one provisional site, and real sites come from delivery addresses, replies, calls and technician reports. Devices move between sites without changing their ID.

Segments. Devices sold to marketplaces, resellers and export customers stay in the base but outside the reminder loop. The same applies to devices of models no longer in production and to purchases more than ten years back. Excluding them keeps them out of every mail. Where billing and delivery country differ, the delivery address decides.

Pricing by distance. A distant visit can carry the same price as a nearby one while using far more technician time. We modelled two tests. Does a surcharge cover the extra travel cost? And does the visit still earn as much per technician-day as nearby work? A surcharge can pass the first test and fail the second, and bundling visits into one route changes both answers.

Two ways to price a distant service visit Grouped bar chart, price index where a nearby visit of half a technician-day equals 100. Each extra technician-day adds travel cost of about 33. Nearby, 0.5 technician-days: all three prices 100. Mid distance, 1 technician-day: same price 100, cost-covering price 117, capacity-equal price 200. Far, 2.5 technician-days: same price 100, cost-covering price 167, capacity-equal price 500. A surcharge that covers travel cost is the lower bound. Earning the same per technician-day is the upper bound. Bundling two visits into one trip halves the extra days and the surcharge. Covering travel is not the same as earning the day 100 100 100 Nearby 0.5 technician-days 100 117 200 Mid distance 1 technician-day 100 167 500 Far 2.5 technician-days Bundling two visits into one trip halves the extra days, and with them the surcharge. Same price everywhere Covers the extra travel cost Earns the same per technician-day Two ways to price a distant service visit Grouped bar chart, price index where a nearby visit of half a technician-day equals 100. Each extra technician-day adds travel cost of about 33. Nearby, 0.5 technician-days: all three prices 100. Mid distance, 1 technician-day: same price 100, cost-covering price 117, capacity-equal price 200. Far, 2.5 technician-days: same price 100, cost-covering price 167, capacity-equal price 500. A surcharge that covers travel cost is the lower bound. Earning the same per technician-day is the upper bound. Bundling two visits into one trip halves the extra days and the surcharge. Covering travel is not the same as earning the day Nearby 0.5 technician-days 100 100 100 Mid distance 1 technician-day 100 117 200 Far 2.5 technician-days 100 167 500 Bundling two visits into one trip halves the extra days, and with them the surcharge. Same price everywhere Covers the extra travel cost Earns the same per technician-day
Two ways to price a distant service visit: covering travel cost versus earning the same per technician-day. Index: a nearby visit takes half a technician-day and is priced at 100. Each extra technician-day adds travel cost of about 33.

Contact. No reminder text goes out before a person has approved it. Prices stay as highlighted placeholders until they are confirmed. The third mail asks for a one-digit reply: book a visit, serviced by another provider, or retired and moved. Each answer updates the device record.

The mail tool only sends mail. The data platform remains the source of truth.

The economics

Service revenue follows a simple chain that you can write down for your own business. Multiply serviceable devices by the share of customers who book, the visits per year and the price per visit. Then subtract the cost to serve, which is mostly technician-days, travel and overnight stays.

A clean device record raises the number of serviceable devices, and accurate, well-timed reminders raise take-up. The interval sets the visits, while route bundling protects the price on far sites.

The ceiling is capacity. Take-up can only grow as fast as bookable technician-days allow, so batches stay small and follow the calendar.

Over a customer’s lifetime the effect compounds. Take one service visit a year at 8 percent of the sale price. If the customer books every year for ten years, that adds 80 percent to the revenue from that customer. That is the upper end of the example. A customer who books every other year adds 40 percent. Service also keeps the business in the room when the device needs replacing.

Customer lifetime revenue with and without service Line chart over ten years, index where the original sale equals 100. Sale only stays at 100. Sale plus one service visit a year at 8 percent of the sale price, booked every year, reaches 180 after ten years. Booked every other year, a dashed line reaches 140. The every-year line is the upper end of the example, and the service relationship puts the business in position for a possible replacement sale at the end. Revenue, not profit. Revenue from one customer over ten years 0 50 100 150 200 Year 0 Year 2 Year 4 Year 6 Year 8 Year 10 Every other year 140 over ten years Sale only 100 Sale + service 180 over ten years + possible replacement Cumulative revenue from one customer, index: original sale = 100 One service visit at 8 percent of the sale price, booked every year or every other year. Revenue, not profit. Customer lifetime revenue with and without service Line chart over ten years, index where the original sale equals 100. Sale only stays at 100. Sale plus one service visit a year at 8 percent of the sale price, booked every year, reaches 180 after ten years. Booked every other year, a dashed line reaches 140. The every-year line is the upper end of the example, and the service relationship puts the business in position for a possible replacement sale at the end. Revenue, not profit. Revenue from one customer over ten years 0 50 100 150 200 Year 0 Year 2 Year 4 Year 6 Year 8 Year 10 Cumulative revenue from one customer, index: original sale = 100 Sale + service 180 over ten years + possible replacement Every other year 140 over ten years Sale only 100 One service visit at 8 percent of the sale price, booked every year or every other year. Revenue, not profit.
Cumulative revenue from one customer over ten years, with and without service. Index, original sale equals 100. Assumes one visit at 8 percent of the sale price, booked every year or every other year.

This can also be the quicker revenue. A new buyer pays after a full sales cycle, whereas an existing owner can be offered a visit as soon as the due list exists.

Rules that protect the record

Service only works if customers can trust the data behind each reminder. These rules protect it.

  • Read-only master. The live ERP is read through a read-only user, and older systems load into their own tables.
  • Untouched production. Row counts of existing production tables are compared before and after each run.
  • One rebuild path. A single script runs import, matching, decisions, timeline, due list and checks in order, and leaves no partial state behind.
  • Convergence. Two consecutive rebuilds must produce identical results.
  • Identity protection. Once the first reminder is logged, a guard blocks any rebuild that could reassign device IDs. A reply must never drift away from its device.
  • Contact window. Reminders go only to customers whose products are still in production, ten years back at most. Older records serve matching and checks. They never feed a mailing.
  • Approval before contact. Mails are prepared as draft campaigns, and a person sends them after sign-off. No test mails go to real addresses.
  • Stop rule. A batch stops if too many of its addresses bounce, and the data gets checked first.
  • Customer files stay out of the code. Raw exports and customer files are excluded from version control.

Checking before contact caught two problems early. The quote trap surfaced in analysis rather than as a customer complaint, and a second review across all three systems found one device model missing from the item list. It was added before any reminder was built on it.

Calls our founder made

A handful of decisions shaped the build, and our founder made each of them.

The oldest records went into the database before anyone rewrote the study, so the evidence led the story. We keep one record per unit, which costs more rows but survives split sites, partial retirement and per-device billing. Marketplace, reseller and export devices are excluded rather than deleted, and they stay visible outside the loop.

Each batch is to stay small enough for the team to answer every reply personally. Every distance is to be served, with distance handled in the price and the route. A clear go signal is agreed before the first batch, so success is defined before anyone sees results.

What it unlocks

Once the device record exists, each next move reuses it instead of starting from an export.

Recurring service comes first, since every due date is a reason to call, every year. Replacement planning follows, since the age profile of the base shows when product families are due for renewal. New offers can then sit on the same base, where rental units, loan devices and upgrades can share one record.

Once batches run, the measures are booked appointments, delivered visits and collected payments, paced to technician capacity.

Advice for an equipment business

Start with the customers you already have. They are often the cheapest growth you will find.

Count devices, not invoices, since service is sold per machine and per site, never per purchase. Treat old records as a check, not as a mailing list. A retired system often knows more about each device than its successor, yet contact belongs with current customers. Choose accuracy over reach, because a wrong reminder can cost more trust than several right ones earn. And price the technician-day, not only the visit, because capacity is the real limit of a service business.

A first test needs no project. Pick one product family, list the units you sold over the past decade and mark which of them have a service date on file. If most have none, your next revenue line may already sit in your records. The Hidden Cash Flow explains how to turn that list into service income, and we can build the device record with you.

Credits

Built by the Capcelerate team. AI speeds up our work, and our team is responsible for every result. Open-source extraction tools read the retired database, and the client’s team gave us access to their records. Thank you.

Tell us what you want to grow. The intro call is free.

Request a free intro callFree, up to 30 minutes. No obligation.