# Airful > Airful is an AI-native growth studio. We build operating platforms, investor intelligence systems and growth infrastructure for scaling companies, then run growth, marketing and AI governance on top of them. Canonical site: https://airful.io Legal entity: Airful Consulting LLP Primary contact: hello@airful.io Founder: Avishek Kedia Service area: Worldwide, remote-first --- # Investor Intelligence URL: https://airful.io/services/growth-architecture Enrichment, scoring and pipeline systems for fundraising and deal flow. We take the contacts you already hold, add signal from outside, score them against your thesis, and wire the result into the tools your team works in, so outreach starts from evidence rather than memory. Why this capability exists A founder's network is real, and it is scattered. Every warm relationship a team has built over years sits somewhere different: a Gmail thread, a LinkedIn connection, a spreadsheet someone updated during the last raise, a name a partner mentioned in a hallway. None of that is organised as a system, and the judgement about who matters and why lives in one person's head, recalled from memory whenever a deadline arrives. That is closer to a retrieval problem than a data problem: the information exists, but nobody can see it, rank it or act on it as a whole. We built this capability because a raise or a deal search should not start with someone trying to remember who they met at a conference several cycles ago. The network already exists. What's missing is a ranking anyone can trust. What we believe about it We believe fit is measurable, not a matter of taste. A profile that matches your stage, sector and thesis produces the same score however many times you compute it, and that consistency is worth more than any one person's gut feel, however sharp. We spend the machine's time on the part that is cheap to do at volume: pulling firmographics, funding history and signal from a name and a company. We spend a person's time on the part that is expensive and cannot be delegated: deciding what actually matters this quarter, and reading a nuance a score will miss. We also believe a list decays. A network scored once and left alone reads stale within a quarter: the funds have moved on, the roles have changed, and the ranking quietly stops matching reality unless someone keeps it current. How the engagements fit together The four engagements form one sequence. The audit comes first because it is the fastest way to see whether the network already justifies a platform. From there, each step hands off to the next, and you can stop after any of them with something useful already in hand. Run the audit on the network you already have, and get a first ranked list within a week Build the scoring platform if the audit shows a system is worth the investment Sync scores and enrichment into the CRM your team already opens every day Refresh the model monthly so the ranking keeps pace with the market A ranked list from the audit is worth acting on by itself. Add the platform and the sync layer, and the same list updates itself every day instead of once a quarter. The monthly refresh is what keeps a network from reading like history a few months after it was built. --- ## Contact Enrichment and Consolidation URL: https://airful.io/services/growth-architecture/contact-enrichment-and-consolidation Type: Build One clean, enriched contact set from every place your relationships currently live. We pull contacts from inboxes, messaging exports, professional networks and legacy CRMs into a single de-duplicated set, enrich each record with outside signal, and deliver it in a portal or your CRM. Two to three weeks, tooling at cost. The situation Relationships accumulate faster than anyone organises them. A founder's real network sits across a personal inbox, a phone's contact list, message exports, a professional network, and whatever CRM was set up once and then left alone. Each source holds its own version of the same person, often years out of date. None of this is unusual, and none of it is useful in its current form. There is no single place to search, no way to tell which record is current, and no consistent way to know what each person actually knows or does now. Every project that needs the network starts by re-discovering it from scratch. What changes Everything moves into one de-duplicated set, matched across sources and enriched with outside signal, so each record reflects who the person is now rather than who they were when the contact was first saved. The relationships were never the problem. The absence of one place to see them was. From that point on, there is one version of the truth for every contact, with a data-quality trail showing what was merged and why. Any project that needs the network, a raise, a launch, a community, starts from a working set instead of a search through old files. Someone building an outreach list now searches once, instead of checking a phone, an inbox and a spreadsheet in turn. A new project pulls its list from the same set within minutes, with the fields that matter already there or flagged as missing. How it runs Inventory sources and agree fields Import, normalise and de-duplicate Enrich in batches and score data quality Deliver into the portal or CRM and hand over You see the de-duplication and enrichment decisions before delivery, not after, so nothing about your own network gets merged or dropped without your say. What you receive The consolidated contact set itself, delivered into a portal built for this or synced directly into your CRM, so your team works from one place instead of five. An enrichment log showing what was added to each record and where it came from, which is what lets you act on a signal with confidence instead of treating it as a guess. A data-quality report on what the sources actually contained before the work started, useful when you want to see how much of the mess was duplication versus records that were simply out of date. And the pipeline that produced all of it, handed over so a refresh later is a re-run rather than a rebuild, and enrichment does not stop the day the project ends. Questions: - How do you de-duplicate? We match on hard identifiers first, such as an email address or a phone number, which resolves most duplicates without ambiguity. What remains goes through conservative fuzzy matching, and every merge from that second pass is left for you to review before it is made final. - What sources can you consolidate? We work with email, messaging exports, professional network exports, spreadsheets and most CRMs. If a source can be exported or read, it can usually be brought into the same set. - Is enrichment expensive? No. Enrichment is passed through at cost, and it is a small fraction of the overall engagement. The larger part of the work is the consolidation itself and the judgement calls around it. - Can we keep enriching after? Yes. Once the initial set is delivered, enrichment can continue as a monthly refresh, so the contact set does not start decaying the day the project ends. --- ## CRM Sync and Pipeline Analytics URL: https://airful.io/services/growth-architecture/crm-sync-and-pipeline-analytics Type: Build Your platform and your CRM finally agree, and the pipeline shows real velocity. A bidirectional sync between your data platform and the CRM your team works outreach in, with non-destructive merging, fail-open intake forms, and analytics that show deal velocity rather than activity. One to two weeks on the CRMs we already run. The situation Most teams end up running two systems that never fully agree. Outreach gets logged in the CRM because that is where the sales or investor-relations team already lives day to day. Enrichment, scoring and analysis happen in the data platform because that is where the model runs. Neither system has the full picture, and nobody trusts either one completely. The gap shows up at the worst moments: a contact scored highly in the platform never makes it into an active sequence in the CRM, or a reply logged in the CRM never reaches the model that should update the score. Reporting to leadership becomes an exercise in reconciling two spreadsheets by hand. What changes A sync keeps both systems current without either one becoming the single point of failure. Each field has a clear owner, changes move both ways as they happen, and the record your team works from in the CRM matches what the platform actually knows. The goal is not one system replacing the other. It is one truth, visible in both. Analytics sit on top of the synced record and show pipeline velocity, where deals are moving and where they are stuck, instead of activity counts that look busy without saying much about progress. A rep working the CRM no longer asks the data team whether a score changed, it already shows in the field they are looking at. Leadership's pipeline review pulls from the same analytics view instead of two exports stitched together by hand. How it runs Map objects and decide field ownership Build and test the sync in a sandbox Wire intake forms and enrichment events Ship analytics views and a runbook The sync is built and tested in a sandbox against your CRM before anything touches production data, so the first live sync is a formality rather than a leap of faith. What you receive The sync itself, running against your CRM's API on the field-ownership rules you signed off, so both systems stay current without anyone copying data by hand. An admin screen where your team can see sync status at a glance and resolve the rare conflict directly, instead of opening a ticket with us every time two records disagree. Analytics views built around the pipeline questions leadership actually asks, so a Monday review starts from real movement rather than a guess dressed up as a chart. And a written runbook covering how the sync behaves day to day, what to do if it stalls, and how to extend it to a new object or field later without our involvement. Questions: - Which CRMs? We integrate directly with CRMs that expose a proper API, and we have built against several of the common ones. A legacy CRM without a usable API is still in scope, handled through export rather than a live sync. - What does bidirectional mean here? Each system owns the fields it is best placed to own, your platform owns enrichment and scoring, your CRM owns outreach status, and changes flow both ways between them. Nothing is overwritten silently; conflicts are surfaced, not guessed at. - What if the sync fails? Intake forms are built to fail open into your platform if the sync itself is down, so a lead is captured even when the CRM side is unreachable. The sync catches up once it is back, rather than losing anything in between. - Can you replace the CRM instead? Sometimes replacing the CRM is the better call, usually when trust in it is already gone. We say so plainly if that is what the situation calls for, rather than building a sync onto something not worth keeping. --- ## Investor Intelligence Audit URL: https://airful.io/services/growth-architecture/investor-intelligence-audit Type: Assessment A ranked, enriched view of your own network inside a week. A one-week audit of the contacts you already hold, across inboxes, exports and your CRM, enriched with outside signal and scored against your thesis. You receive a ranked shortlist per persona, the reasoning behind each score, and a plan for the platform if one is warranted. The situation Every fundraise starts from a network that already exists, spread across an inbox, a handful of spreadsheets, old CRM exports and the private notes of whoever raised money before. Nobody has pulled it into one place, and nobody has scored it against what this round actually needs. Fit gets judged from memory: who was warm a while back, who replied to a cold message once, who a board member mentioned in passing. Outreach then runs on instinct rather than evidence. Messages go out to the names that come to mind first, not the names most likely to convert, and there is no record of why any name was chosen over another. A strong match can sit unopened in a spreadsheet nobody reopened. Without a system to catch it, the good matches move at the same pace as everyone else. What changes At the end of the week you hold a ranked shortlist for each persona in the raise, not one undifferentiated list of contacts. Every name on it carries the reasoning behind its score, so the shortlist reads as a case rather than a guess. Outreach can start from evidence instead of memory. The audit does not just rank your network. It tells you whether the network you have can carry the round you are planning. You also leave with a straight answer on the platform question. If the network is thin, or the scoring shows a gap in a particular persona, that is worth knowing before you commit to building anything further. If it is strong, the audit becomes the starting data for the platform rather than a one-off exercise that ages the day it is delivered. How it runs Agree personas and thesis Consolidate exports into one de-duplicated set Enrich and score against the model you approved Review the top lists together and adjust the weights Deliver the report and the recommendation The scoping call sets the thesis once, in writing, so scoring stays consistent across every contact reviewed that week. Nothing in your CRM or inbox is changed; the audit reads and reports. What you receive You receive the ranked list for each persona, the scoring model itself so you can see exactly how each score was reached, and a read on the quality of the data you started with: how much was missing, duplicated or stale. None of it is a black box. The report ends with a plain recommendation: build the platform now, wait, or treat this as a one-time exercise. That call is yours, made with a full account of what the model found rather than a pitch for the next phase. More than five enrichment and scoring pipelines in production More than twenty-five documented engineering patterns reused across client work Questions: - What do you enrich contacts with? We enrich each contact with firmographics, role changes, public signals of intent and warm paths into your network, drawn from sources we run at cost. You see exactly what was added to a record and where it came from. Nothing is inferred without a source behind it. - Is our data safe? Your data is processed in an isolated environment built for this engagement alone. At the end, it is deleted or handed back to you, and it is never used on anyone else's work. The scoping call covers exactly what access we need and for how long. - Do we need a CRM first? No. Exports from your inbox and network files are enough to start, and the audit itself tells you whether a system is worth building at all. Sometimes the honest answer is not yet, and that is a useful finding on its own. - What if the shortlist is short? Then that is the finding. A short list means the network in hand does not yet support the raise you are planning, and knowing that now saves you a stretch of outreach that would not have converted. It also points to where the gap actually is. --- ## Investor Scoring Platform URL: https://airful.io/services/growth-architecture/investor-scoring-platform Type: Build A living system that scores, refreshes and explains every prospect in your pipeline. A platform that consolidates organisations and contacts, enriches them continuously, scores them with a model written for your thesis, and shows the pipeline your team actually has. Built in phases over three to six weeks and handed over as your own system. The situation An audit proves the network exists and can be scored. It does not keep scoring it. Contacts change roles, firms raise new funds, a name that was warm not long ago has since gone quiet, and a static shortlist starts decaying the day it is delivered. Nothing about a point-in-time report catches that on its own. Most teams respond by re-running the exercise by hand every few months, which is slow, inconsistent, and dependent on whoever happens to have time that week. Nobody owns the refresh, so the shortlist that once drove outreach quietly turns back into an old spreadsheet, and the team is back to judging fit from memory. What changes The platform replaces a one-time report with a system that keeps working after the team stops thinking about it. Contacts refresh on a schedule, scores update as new signal arrives, and every score still carries the reasoning behind it rather than a bare number. A shortlist that does not update is a photograph. This is closer to a live feed. Because scoring runs continuously, outreach can draw from a pipeline that reflects the present rather than the week of the audit. Your team sees who moved up, who went quiet, and why, without asking anyone to re-run anything by hand. A Monday now starts with what changed over the weekend, not a stale spreadsheet. Whoever owns outreach works from the top of the ranked list, and when a partner asks why a name is there, the reasoning is already attached. How it runs Phase one: consolidated data model and import Phase two: enrichment queues and the scoring model Phase three: dashboards, ranked views and exports Phase four: sync to your CRM and a handover session Each phase ends with something usable, not a slide deck, so you can watch the system take shape and change course early if a phase reveals something the thesis missed. What you receive You receive the platform itself, running on your own repository and database, documentation written for whoever inherits it next, and the scoring model in a form your team can read and adjust without coming back to us. A runbook covers what to do when a stage of the pipeline breaks or a new data source needs adding, so the system does not depend on us being reachable to keep running. More than five enrichment and scoring pipelines in production More than twenty-five documented engineering patterns reused across client work Questions: - How is the scoring model built? The model starts as deterministic rules you can read line by line, built and tuned together with you against real examples from your own pipeline. We bring in a language model only where judgement is genuinely needed, such as reading an unstructured bio for relevant signal. Every score still traces back to a reason. - Can it run more than one model? Yes. The platform supports one scoring model per thesis or portfolio company, all running against the same underlying data. A contact can rank highly against one thesis and low against another, which is often the more useful answer than a single blended score. - What does it cost to run? Enrichment is passed through at cost, and it is usually a small ongoing figure relative to the build itself. The only other running cost is hosting, which sits in infrastructure you own rather than a recurring fee to us. - Who maintains it? Your own team can maintain it once handed over, since the system and its documentation are built for that from the start. If you would rather not, we can operate it for you as a monthly arrangement instead. --- # Operational Platforms URL: https://airful.io/services/product-platform Custom operating platforms, migrations off the tools you have outgrown, and the intelligence features inside the products you ship. Built on a stack we run for dozens of clients, delivered in phases you can see, and handed over with the keys. Why this capability exists Every operator eventually hits the same wall: the software that got the business this far was built for a workflow that is not this business's workflow. A page builder, a generic CRM or an inherited application handles the common case well, and handles the specific case, the one that makes this operation different from a hundred others, by forcing it into someone else's shape. That compromise is invisible on day one and expensive within a year or two, paid in workarounds, spreadsheets bolted onto the side of a tool, and a team that has learned to route around the software rather than use it. We build this capability because a business's operational advantage usually lives exactly where a generic tool refuses to bend, and that is not a place worth compromising on. What we believe about it We believe in one stack, run enough times that the decisions inside it are no longer experiments. The same combination of framework, database and hosting shows up on nearly every build, which means fewer surprises for you and faster delivery for us, because we are not relearning the fundamentals on your project. We also believe in phases with a working deliverable at the end of each one, so you are never asked to trust an unopened box for months before you see anything real. The back office decides whether the front door holds up. And we believe the back office comes before the front door: the data model, the permissions and the workflows that hold the business together get built first, because a handsome interface over a broken foundation just fails more visibly. How the engagements fit together Every engagement in this pillar sits on the same sequence, even though the entry point differs by client. Some businesses start here because they are leaving a tool that has stopped serving them. Others start with nothing built yet. Either way, the foundation comes first, because everything that follows depends on the data model being right before more gets built on top of it. Start with a migration if you are leaving a tool, or a foundation build if you are starting fresh Add the operations platform once the core data model is in place Layer in the channels your team and customers already use, including WhatsApp where that is where the conversation happens Build the intelligence features into the product last, once there is real usage data to learn from Some clients stop after the foundation and operate the platform with their own team from there. Others keep going through to the intelligence layer, because the operations platform has already generated enough real usage to make those features worth building. We hand over what is finished at every phase, so stopping early never means owning something incomplete. --- ## Intelligence Features in Product URL: https://airful.io/services/product-platform/intelligence-features-in-product Type: Build The feature your users expect now: matching, summarising, classifying, answering, built to be trusted. Language-model features designed and shipped inside your product: chat with lead capture, matching and recommendation, classification and routing, document extraction, report generation. Built with cost controls, evaluation and guardrails, so the feature works on a bad day too. Two to four weeks per feature. The situation Your users have started asking for the feature before you have decided how to build it. They want the product to match them to the right option, summarise what they would otherwise read in full, or answer a question directly, because they have used products elsewhere that already do this. The team's hesitation is usually well founded. A feature like this can be wrong in ways a normal feature cannot: confidently, plausibly, and in front of a customer. Nobody wants to ship something that invents an answer, and without a clear way to measure whether it is working, the safer choice looks like waiting, even as competitors move ahead and the manual version keeps costing someone's time. What changes You ship a feature with a measured pass rate. Before it reaches a real user, it has been run against a set of examples you helped define, so you know how often it gets the answer right and what it does when it does not, well before a complaint ever arrives. A feature earns trust by showing its failure rate before launch, not by promising there won't be one. You also get a known cost per use, agreed before the build starts. And you get a fallback: a defined path for the cases the feature is not confident about, so an uncertain answer is routed to a person before it ever reaches the user. How it runs Define the task and the acceptance examples Select the model ladder and the cost ceiling Build with guardrails, logging and evaluation Ship behind a flag, measure, then release Hand over the evaluation set and the runbook The acceptance examples come first because they define what "working" means for this feature specifically, in your product, for your users, rather than a generic standard borrowed from somewhere else. We select the model ladder and the cost ceiling against those examples, then build the feature with the guardrails and logging that let it be measured once it is running. Nothing ships to every user at once. It launches behind a flag, we measure its real pass rate against real traffic, and only then does it roll out fully, so the release decision is based on evidence gathered in production rather than confidence gathered in a demo. What you receive The feature itself, live in your product and instrumented so its behaviour can be watched after launch. The evaluation report shows how it performed against the acceptance examples, giving you a documented answer to whether it works. The cost model, showing what the feature costs to run at the volume you expect, and the runbook: what to check when it misbehaves, how to adjust the guardrails, and how to extend the evaluation set as new cases show up. Your team is equipped to own the feature, not dependent on us to explain what it is doing. More than five products shipped with intelligence features inside them More than five enrichment and scoring pipelines in production Questions: - Which models do you use? We use the cheapest model that passes the evaluation, with a ladder from small to large by task. We choose the model per task, which keeps the running cost of the feature honest. - How do you stop it saying something wrong? We build against evaluation sets, guardrails and logging, and we always leave a human path for the cases that matter. Every output is checked against known-good examples before launch, and every response in production is logged so a wrong one can be found and fixed before a user ever discovers it. - What does it cost to run? We design against a cost per use you approve before we build, usually a matter of cents. You see the full cost model during design, so the economics of the feature stay a decision you control throughout. - Can you secure it? Yes, and we recommend the application security assessment for anything customer-facing. A feature that reads or writes real user data carries its own exposure, and pairing this engagement with that assessment closes the gap between a feature that works and one that is also safe to ship. --- ## Operations Platform for Operators URL: https://airful.io/services/product-platform/operations-platform Type: Build A back office built around how you actually work, live in days, run with you for years. A custom operations platform for founder-led businesses: contacts and clients, enquiries and pipeline, bookings, documents, newsletters and payments in one place, built on a template we have run many times and shaped to your workflow. From a five-day setup to a full multi-role build. The situation The business runs, but it runs from the founder's memory. Which enquiry is warm, which client is due a follow-up, which booking still needs a deposit chased: all of it lives in a head, an inbox, and a spreadsheet that only makes sense to the person who built it. Ask a new hire to take over any of it and the answer is usually that they cannot, because nothing has been written down in a form another person could pick up. Meanwhile the business is paying for three or four tools that do not talk to each other: one for enquiries, one for bookings, a spreadsheet for the pipeline, a folder somewhere for contracts. Moving a single client from first message to signed agreement means re-entering the same facts in each place, and the version that is out of date is usually the one someone trusted. What changes You get one system your team actually lives in, covering contacts, enquiries, pipeline, bookings, documents and payments in a single place. A new hire can see the state of any client or booking without asking the founder, because the record is written down where the work happens, not held in someone's head. An operations platform is working when the founder is no longer the system everyone else depends on. Routine work stops needing the founder as a bottleneck. Enquiries route themselves to the right person, follow-ups fire on schedule, and documents generate on their own from the data already in the system, without being drafted from scratch each time. The founder's attention moves to the decisions that actually need it. How it runs Map the workflow and the data you already have Stand up the template or the foundation Shape modules to your process: pipeline, bookings, documents, comms Migrate data and train the team Run it with you, monthly, if you want that We start from a template we have run for other operators, which is why a working version exists inside a week rather than a month. The weekly session after that is where the platform gets shaped to you specifically: which pipeline stages matter, which documents need to generate themselves, which bookings need a deposit rule the template does not assume. Data migration happens once the shape is agreed, so nothing has to be re-entered when a field changes. Training runs against real records from your own business, not sample data, because a team learns a system faster when the first thing they see in it is a client they recognise. What you receive The platform itself, deployed and running on infrastructure billed to you, with your team already trained on the parts they use daily. Your existing data, migrated and checked against the source rather than assumed correct, so the system is trustworthy from the first day, with nothing left to verify later. A short manual, written in plain language for the people who will use the platform day to day. And the repository, handed over in full, so the platform remains yours to run, extend or hand to someone else regardless of whether the monthly relationship continues afterward. More than ten operating platforms and CRMs built for operators More than twenty-five documented engineering patterns reused across client work Questions: - Why not a generic CRM? Generic tools shape your work to their model; this is shaped to yours and costs less to run. A pipeline stage, a booking type or a document flow that does not match how you actually operate gets built to match it, so your team is never asked to adapt to a stranger's assumptions about the business. - How fast is the template version? A working platform inside a week from access being granted, covering contacts, pipeline, bookings and documents on the foundation we have already built and tested elsewhere. From there, further weeks go entirely to the modules specific to how you run things; the parts every operator needs are already built. - What does it cost to host? A few tens of dollars a month on infrastructure you own. There is no per-seat licence to climb as the team grows: you hold the account and the bill, and nothing about your data sits behind a vendor's pricing decision made after you are already committed. - Can it grow into a product? Yes, several have. What starts as an operator's own back office can become the product they sell, once the workflow is proven on their own business. --- ## Platform Migration URL: https://airful.io/services/product-platform/platform-migration Type: Build Off the tool you have outgrown, onto a stack you own, without losing a single URL. A rebuild of your website or application from a page builder, a legacy CMS or an ageing framework onto a modern stack you own, with every existing URL preserved, content migrated, and analytics reconnected. Two to six weeks depending on scale, phased so you can see progress. The situation The tool that got the business started is now the thing holding it back. A page builder that made the first version fast to launch now fights every request that is slightly out of the ordinary: a booking flow, a members' area, a page layout the template was never built to hold. Every small change becomes a workaround, and the workarounds are starting to show. Sometimes the barrier is a person rather than a tool. A developer built something bespoke, then left, and nobody on the current team can safely open the code without fear of breaking it. The site keeps running because nobody dares touch it, which is its own kind of debt: every good idea for the business now waits behind a fear of the thing that carries it. What changes You end the engagement holding a codebase your own team can read, run and change, on infrastructure billed to you directly and inspectable end to end. Nothing about how visitors find you moves: every URL that ranked before still ranks, still resolves, still leads where it always led. The only difference they notice is a site that loads faster than it used to. A migration should be invisible to the people who use the site and completely legible to the people who run it. For your team, the change is in what a request now costs. A layout change that used to need a ticket and a wait becomes a pull request reviewed the same day. Content changes ship in minutes because the person making them can see exactly what will happen before they publish it, on a stack built to be read clearly. How it runs Audit pages, assets, forms and integrations Build the redirect map and agree it Rebuild on staging in phases Reconnect analytics, forms and bookings and test Cut over the domain and monitor for a week We rebuild in phases you can see, instead of running one long build that reappears at the end as a surprise. Each phase lands on the staging domain first, where you review it against the live site before the next phase starts, so drift gets caught early, while it is still cheap to fix. The cutover itself is the smallest step in the project, precisely because everything before it was designed to make it small. The domain points at the new site, the redirect map takes over, and we watch traffic, forms and error rates for a full week afterward, so the calm cutover is a result of the work, not luck. What you receive The repository, handed over with the access and the history intact, so the site or application is yours to run whether or not you continue working with us. Alongside it, the redirect map itself, kept as a living reference in case a page ever needs to move again. You also get a content guide written for the person who will actually use it, covering how to add a page, swap an image or update a price without needing to understand the underlying framework. A monitoring report closes out the engagement, showing traffic, errors and redirect performance across the week after cutover, so you start on the new stack with evidence that it held rather than a promise that it would. At least twenty websites and platforms rebuilt on a modern stack Five platform migrations with full data and domain cutover Questions: - Will we lose search rankings? No, every legacy URL is mapped and redirected before cutover and verified after. We build the redirect map from your current sitemap and analytics, so pages that already rank keep the traffic they earned. You approve the map before anything goes live. - Can we edit content ourselves afterwards? Yes, content lives in files or a light admin your team can use directly. We choose the editing model during scoping, based on how often you change content and who on your team will do it. Either way, you keep access to your own site going forward. - What about our existing integrations? Forms, bookings, payments and analytics are reconnected and tested on staging first, before the domain moves. We treat each integration as its own checklist item, because a silently broken booking form is the failure mode that matters most. Nothing goes live until every one of them has been exercised. - How long is the site down? It is not, cutover is a domain change with the old site live until the new one answers. We build and test the new site on a staging domain for the full length of the project, so the switch itself takes minutes and carries no outage window for your visitors to notice. --- ## Product and Platform Build URL: https://airful.io/services/product-platform/product-and-platform-build Type: Build From a scoped idea to a working product in phases you can see and stop between. A phased build for a new product or platform: foundation with authentication, data model and one working flow; feature phases for the parts that make it yours; polish, compliance and launch. Four to twelve weeks, fixed price per phase, with a working deliverable at the end of each. The situation Somewhere between an idea and a business is a point where a spreadsheet, a prototype or a manual process stops being enough. The idea has a buyer now, or the internal workaround has grown past what one person can run by hand, and what is needed next is software that other people can log into and rely on. That point is also where a lot of builds go wrong. Scope grows without anyone pricing the growth, a single long build reappears months later as a surprise nobody signed off on, and the founder discovers the stack chosen for them the day someone tries to hire a second engineer. Something usually does ship in the end. The trouble is that it no longer matches what the business needed by the time it arrives. What changes You get a product your users can log into and depend on day to day. It ships in phases, so the parts that matter to your buyer exist first: authentication, the data model, one flow that works end to end, followed by the features that actually make the product yours rather than a template with your logo on it. A phased build turns a single leap of faith into a series of decisions you get to make with your eyes open. Each phase is priced and scoped before it starts, so you are choosing to continue, not discovering afterward what the whole thing cost. If priorities shift partway through, the next phase absorbs that shift on paper, in writing, before it touches the one already underway. How it runs Scope and phase the work, fixed price per phase Foundation: auth, data model, one working flow, deployed Feature phases: the pieces that make the product yours Polish: performance, privacy, analytics, launch checklist Launch, then operate monthly if you want that The scoping document is the one artefact everything else depends on, which is why it is written together and signed before any build begins. It names what each phase delivers, what it costs, and what counts as done, so a weekly working session is checking progress against an agreed plan, not negotiating the plan itself while the clock runs. Design is approved in writing before its phase's build starts, and the deployed environment updates continuously, so you are watching the product take shape on a schedule you can see instead of waiting for a single reveal. What you receive The product itself, live and usable by the people it was built for, deployed and monitored from day one. The repository that built it, complete and yours, on a stack chosen because it is the stack we run across our client work and the one you can hire for afterward. Documentation written for the team that will maintain the product once the build is done, covering how it is structured, how it is deployed, and how to extend it safely. A launch checklist closes the engagement: performance, privacy and analytics confirmed working before the product goes in front of real users, with the results recorded for whoever picks up the project next. More than ten operating platforms and CRMs built for operators More than twenty-five documented engineering patterns reused across client work Questions: - Why phases? Each phase ends with something that works and a decision about the next, so risk stays small. You are never committed to a build you have not seen, and stopping after any phase still leaves you with a working product at that stage. - What stack? One modern stack we run for dozens of clients, which is why we are fast and why you can hire for it. Nothing about the build depends on a framework only we understand, so any competent team can maintain your product going forward. - Do you do design? Yes, and no build starts until you have approved it in writing. Design happens ahead of each phase's build and is signed off before engineering begins, so the engineering work executes an agreed plan. - What happens to scope changes? They are written down, priced, and added to a phase openly. A change that seems small in conversation can move a timeline, and naming its cost up front protects both the schedule and the relationship, so it cannot erode either one quietly. --- ## WhatsApp Operations Layer URL: https://airful.io/services/product-platform/whatsapp-operations-layer Type: Build Every message answered, recorded and attributed, no matter whose phone it landed on. WhatsApp built into your operations platform as a shared, logged channel: enquiry capture, routing, templates, a shared inbox, automated follow-up and a daily digest. For businesses where customers message first. Two to three weeks, with a small monthly fee for the channel. The situation The first message from a customer usually arrives on WhatsApp, and it usually lands on whichever staff member's personal phone the number happened to be shared with. That person answers if they are on shift, remembers to follow up if they are not distracted, and carries the entire conversation history in an app nobody else on the team can see. When that person is off, or leaves, the thread goes quiet or starts over with someone else who has no context. Nobody can say with any confidence which message turned into a booking, because the record of it lived on a device the business does not own and cannot audit. The channel that customers actually prefer is the one the business trusts least. What changes The channel becomes one shared, logged record that replaces private threads scattered across personal phones. Any team member can see the full history of a conversation, pick it up mid-thread, and know what was already promised, because the conversation lives in the platform rather than in someone's pocket. The channel your customers already prefer should not depend on which phone happens to be charged. Follow-up stops depending on memory. A message that has not been answered inside an agreed window gets flagged instead of forgotten, and a daily digest tells the team what came in, what is still open, and what closed, so a shift change no longer means a conversation restarts from nothing. How it runs Set up and verify the business account Integrate with your platform or CRM Write and approve templates and routing Train the team and run in parallel for a week Switch over and monitor Verification of the business account happens first because it sets the timeline for everything after it; the platforms that issue it move on their own schedule. Once it clears, we connect the channel to your existing platform or CRM so a WhatsApp enquiry becomes a record in the same system as every other lead, not a separate silo to check. Templates and routing rules are written and approved with you before anything goes live, then tested for a full week running alongside the old habit, not replacing it outright. The team only switches over once the parallel run has shown the new channel holds up under real messages. What you receive The channel itself, running on a business account you own and can move between providers if you ever need to. A shared inbox your whole team can work from, with every conversation attributed to the person or automation that handled it, so nothing depends on one phone again. Approved templates for the messages you send often, and the daily digest that keeps the team looking at the same picture of what is open and what is done. Training runs against your own enquiry rules rather than a generic script, so the handoff from us to your team becomes a working habit the team actually follows. More than five WhatsApp integrations running for clients More than ten operating platforms and CRMs built for operators Questions: - Is this an official integration? Yes, built on the business platform with approved templates and an account you control and verify. Messages route through that account, so the channel survives a staff change and stays with the business. - Can it reply automatically? We set automated replies within rules you define, and you keep a person able to take over any conversation at any point. We do not let automation answer beyond what you have approved, and we log every automated reply the same way we log a person's. - What about existing chats on personal phones? They can be migrated in or run alongside during the transition, whichever fits how the team is used to working. We do not ask you to switch everything over on day one; the shared channel and the old habit can coexist until the new one has proven itself. - How does it connect to marketing? Enquiries carry the campaign that produced them, so spend can be judged by the bookings it actually produces. You see which channel converted a message into revenue, which is the question most WhatsApp-heavy businesses have never been able to answer directly. --- # Growth Operations URL: https://airful.io/services/business-transformation The layer that runs after a platform ships: analytics flowing in daily, a monthly optimisation cadence, automation of the work that eats your team's week, senior technology leadership on a fractional basis, and the AI skills your people need to do their own jobs better. Why this capability exists A platform is finished on the day it ships and starts decaying the day after. Traffic sources shift, a competitor changes their offer, a workflow that made sense for a handful of customers breaks quietly once the business is much larger, and nobody notices until someone asks why growth has stalled. Most agencies hand over the keys at launch and consider the job done, which leaves a gap exactly where a business needs attention most: the months when small decisions, made or missed, compound into either momentum or drift. Ownership of that gap tends to fall on whoever is already busiest, which usually means it falls on nobody. We built this capability because the work of noticing what changed and acting on it needs an owner with the time and the data to do it properly, month after month. Every platform needs someone assigned to notice what changed this month. What we believe about it We believe in daily data over quarterly reviews. A quarterly review tells you what already happened and rarely why; a daily dashboard shows the shift while there is still time to act on it, and that difference in timing is most of the value. We also believe in implementing the change ourselves, rather than handing over a slide deck and a recommendation someone else has to find the time to build. A recommendation nobody acts on is worth exactly nothing, however well argued. We put automation to work freeing people for judgement. We build systems that watch traffic, flag anomalies and handle the repetitive parts of a workflow, so your team spends its attention on the decisions only a person can make. You get the answer faster; you still make the call. How the engagements fit together You usually start with observability, because everything after it depends on trustworthy daily data. The monthly cadence follows naturally once that foundation is in place. We add automation, leadership or training only where a business genuinely needs that capability. Start with observability, so decisions come from data flowing in every day Move into the monthly cadence once the baseline is stable and trustworthy Add process and workflow automation where the team is spending hours on repeatable work Bring in fractional leadership or AI skills training as the business needs that capability Some clients run observability and the monthly cadence indefinitely and never need anything more. You might add automation within the first few months, once the case for it is obvious from the data. Either way, the cadence is the constant: a platform nobody is watching starts drifting again the moment attention moves elsewhere, no matter how carefully it was built at launch. --- ## AI Skills Training for Business Owners URL: https://airful.io/services/business-transformation/ai-skills-training Type: Programme You and your team using AI tools properly inside your own work, by the end of the day. Hands-on training for business owners and their teams on using AI tools in real work: setting up the tools, working with code and documents, building a first workflow, and knowing what not to put into them. A day on-site or remote for up to five people, with two weeks of follow-up, or a series of three sessions. The situation The tools are already on every laptop in the building. What is missing is the skill to use them on real work, and that gap shows up as a person opening a chat window, typing a vague question, and closing it again a minute later, unimpressed. Usually one person in the business, often the founder, has actually spent real hours learning how these tools behave: what they are reliable for, what they get subtly wrong, what should never go anywhere near them. Everyone else is waiting to be shown, and the founder is the only one who has time to show them, which means the bottleneck is exactly the person who is already busiest. What changes By the end of the day, the team is not guessing anymore. Everyone who attended has set up the tools on their own machine, run a real piece of their own work through it, and left with a finished task rather than a demo they watched someone else do. Skill spreads through a team the way habits do: by watching someone else do the task successfully once, on work that mattered to them. What spreads afterward is not just familiarity with a tool but a shared sense of the rules: what is safe to paste into a chat window, when to trust an answer, and when to check it against something real. The team now works from the same floor instead of five different private habits nobody else can see. How it runs Agree participants, tools and one real task each Set up the tools together Work each task through, with the method explained as we go Write the team guide and the follow-up plan Before the day starts, we agree who is coming, which tools are in scope, and one real task each person will bring, not a hypothetical exercise built for the room. Getting everyone set up happens first and together, account by account, so nobody spends the morning waiting on a password reset while the rest of the room moves ahead. The day itself moves in one direction: work every real task through from start to finish, with the method narrated as we go rather than handed over as a slide at the end. A question that comes up for one person usually matters to the whole room, so it gets answered out loud, on the spot, against the task in front of everyone. Nobody leaves until their own task is actually done, and the team guide is drafted from what actually came up during the day. What you receive Working setups on every participant's own machine, configured on the tools they will actually use going forward, and the real task each person brought, already finished. Nothing about the day was theoretical: what leaves the room is work the team can point to. A short written guide for the team, covering what was set up and the rules agreed on the day, plus two weeks of follow-up support while the habit is still forming. Questions from the first week of real use get answered directly, so the skill has a real chance to stick before the old habits return. Questions: - Is this a lecture? No, every participant works on a real task from their own job for the full session. The room works through actual documents, actual code and actual decisions, with the method explained as it happens. Everyone leaves with their own task finished, ready to use again the next morning. - Which tools? We train on the tools you already have or plan to adopt. Where nobody on the team has picked one yet, we recommend one based on the work in front of us that day. Either way, the day ends with tools chosen, set up and already in use. - Do you cover safety? Yes, part of the day covers what can and cannot be shared with these tools, and how to recognise the difference in the moment. We work through your own examples, a client file, a contract, a piece of financial data, until the rule is second nature. Everyone leaves knowing where the line sits for their own work. - What happens after the day? You get two weeks of follow-up support and a short written guide for your team, covering what was set up and how to use it. Questions that come up in the first fortnight of real use get answered directly, while the habit is still forming. The guide stays behind as the reference once the follow-up ends. --- ## Fractional Technology Leadership URL: https://airful.io/services/business-transformation/fractional-technology-leadership Type: Retainer Senior technology and product direction, a fixed number of days a month, with a plan to hand over. A named senior technologist embedded with your leadership team part-time: architecture and vendor decisions, hiring and team direction, roadmap and budget, and honest challenge on what you are being sold. For businesses that need the judgement without the full-time seat, on a defined and time-boxed basis. The situation Every growing business eventually sits across the table from a vendor pitch, a hiring decision, or an architecture choice that will shape the next two years, and nobody in the room has the technical seniority to know whether the pitch is sound. The founder nods along, or brings in an outside developer for a single opinion that arrives without the context to weigh it properly. An outsourced team can be excellent at building what they are told to build and still leave a business exposed, because nobody senior is checking whether what was asked for was the right thing to ask for. The bill arrives whether the architecture holds up in a year or not, and by the time it clearly does not, the cost of redoing it has grown along with the business. What changes A senior technologist sits with your leadership team on a fixed schedule, reviewing the vendor pitch, the hiring plan and the architecture before money moves rather than after. Every recommendation carries the reasoning behind it, in writing, so a decision made in month three can be checked against what was said in month one. Judgement is a service you can retain in fixed doses long before you can justify hiring it full time. The value shows up as much in what gets stopped as in what gets started. A vendor contract that does not hold up gets challenged before it is signed, not after the business is already locked into it for a year. That challenge is documented too, so the reasoning behind a stopped decision is there for whoever asks about it later. How it runs Agree the mandate and the days Review architecture, vendors, team and roadmap Run the standing cadence and write every decision Plan the hand-over from month one The mandate comes first: how many days a month, which decisions the technologist can make directly, and which stay with you. That written scope is what keeps the arrangement honest on both sides, because everyone can point back to what was agreed rather than relying on memory of a conversation months ago. From there, the standing cadence starts: architecture, vendors, the team and the roadmap reviewed on a fixed schedule, with every decision written down as it is made rather than reconstructed afterward for a report nobody reads closely. The mandate is revisited each quarter, so the days you are paying for stay matched to what the business actually needs. What you receive A written record of every decision made in your name: the architecture reviewed, the vendors challenged or approved, the hiring shaped. A roadmap that reflects what the business can actually build in the time and budget it has, reviewed and adjusted every quarter as circumstances change. Vendor and hiring support throughout: a second read on a contract before signature, and a hiring brief written around the role you actually need. And a hand-over plan, written from month one, so the day the function moves to your own hire arrives already planned, with nothing left to scramble for. Questions: - Is the person named? Yes, the technologist is named in the engagement documents from the start, so your team knows exactly who is showing up. The firm holds the engagement itself, which keeps continuity in place if anything on our side ever changes. You are never working with an anonymous resource. - Can they manage our developers? They direct the technical work within the mandate you set, reviewing architecture, code and delivery against the roadmap. Personnel decisions, hiring, firing, pay, stay with you as the employer of record. The arrangement gives your team technical direction without changing who anyone reports to. - How many days a month? The number of days is agreed at the start, based on the mandate and what the business needs that quarter. It is reviewed and can be adjusted every quarter as the work changes, up or down. Both sides know the commitment in writing before the engagement begins. - What does hand-over look like? Hand-over starts with a written plan setting out what your new hire needs to know and by when. We help write the hiring brief itself, defined by the actual work the role has been doing here. Once someone is hired, we run a reverse-shadow period, working alongside them until the mandate is genuinely theirs. --- ## Growth Observability Setup URL: https://airful.io/services/business-transformation/growth-observability-setup Type: Build Every source of growth data flowing into one place, daily, before you decide anything. We connect your web analytics, search console, session recordings, advertising and social accounts into one unified data store that updates every day, backfill recent history, and deliver a first review of what it shows. Two weeks, mostly access and configuration, and the prerequisite for everything continuous. The situation Every growth question splits into five logins. Web analytics gives one number, the ad platform gives another, the search console a third, and the session recordings sit in a tool nobody opens unless something has already gone wrong. Each source counts differently, updates on its own schedule, and disagrees with the others in ways nobody has ever reconciled. Ask a founder what changed last week and the honest answer takes twenty minutes of switching between tabs before it arrives, if it arrives at all. Marketing leads build the monthly report by hand, copying numbers into a spreadsheet that is already out of date by the time it gets sent. The business is not short on data. It has five separate stories about itself and no way to read them as one. What changes One store now holds all of it: web analytics, search console, session recordings, advertising and social, refreshed every day and backfilled far enough to show a real trend instead of a two-week guess. The numbers agree with each other because they come from the same place, on the same clock, and nobody has to decide whose report to trust. A number becomes a decision once you know where it came from and that it will still be there tomorrow. Before you decide anything, you have somewhere to look first. A founder asked what changed can pull one review instead of assembling one from memory or a folder of screenshots. Because the store is a database you own, the next question the business asks does not require another tool, only another query against data already sitting in one place. How it runs Grant access and list properties Configure each integration and validate the first pull Backfill and reconcile against the source tools Deliver the dashboard and the first written review Access comes first because everything else waits on it. Search console, ad accounts and social platforms each carry their own permission model, which we work through one at a time, and a missing scope shows up later as a silent gap in the data rather than an error today. We validate the first pull from every source before backfill begins, checking it against the numbers already sitting in your existing reports. Reconciliation is the step most vendors skip. We backfill recent history and check it against the source tool line by line, so a discrepancy gets caught before the dashboard ships instead of discovered by you a month later. What lands in the first review is a data set that has already been argued with. What you receive You receive the pipeline itself: every integration configured, validated and running on its own schedule, feeding one store your team can query directly. Alongside it, a live dashboard built from that store, showing the numbers your business actually needs to watch. And the first written review: a plain read of what the data shows before you have had time to form an opinion of your own, covering what is working, what is not, and where the biggest gap in the picture still sits. From here, the monthly optimisation work has data to run on from day one. Questions: - Which sources? The store covers web analytics, search console, session recordings, paid social and organic social by default. We add bespoke sources by arrangement when your business runs on something less common. Every source lands in the same daily update, so nothing you already track gets left out. - Where does the data live? The data lives in a database you own, one you can query and export directly. Any dashboard tool you already use, or add later, can point at it. It stays your store to keep, independent of any single vendor's report. - Is this a dashboard tool? No, it is the pipeline underneath any dashboard, and it is also the foundation for the monthly optimisation work. A dashboard shows a view of data; this is the store that view draws from and that updates every day. Once it exists, building or changing a dashboard becomes a much smaller task. - What if we already have a tool? We connect to the tool you already use and feed its data into the same daily store. Your team keeps working in the tool they know, with the underlying data now unified and backed up. If you change tools later, the store stays put and simply adds the new source. --- ## Monthly Growth Optimisation URL: https://airful.io/services/business-transformation/monthly-growth-optimisation Type: Retainer Three to five changes a month, shipped and measured, with a written record of why. A monthly cadence on top of your observability data: we review every source, propose three to five specific changes, ship the ones you approve, run the experiments, and write up what happened. The layer most agencies stop before. Requires the observability setup or an equivalent. The situation A website is sharpest on the day it launches and drifts from there. Copy goes stale, a page that used to convert quietly stops, a competitor changes their offer and nobody on your side notices for months. Nothing breaks in a way that trips an alarm; the business just slowly performs a little worse than it did on day one. Most businesses have already paid for a diagnosis of this. A consultant or an agency delivered a list of recommendations, and the list is still sitting in an inbox because nobody had the hours to build any of it. Advice without a hand attached to build it becomes a report, not a result. What changes Every month, the site gets reviewed against real numbers, three to five specific changes get proposed, and the ones you approve get built and measured. None of it depends on a single big swing landing perfectly; the value comes from the string of smaller ones that keep landing. Nothing waits for a big relaunch that might never get scheduled; the next change ships as soon as it is approved, whether that takes a week or a month. Compounding works in a growth programme the way it works in a bank account: small, repeated gains outrun one large leap that never comes again. Six months in, the site is not the one that launched. Every change is dated, every result is recorded, and a leader can trace exactly which decision moved which number, with the evidence sitting in the data itself. How it runs Review all sources against last month Propose three to five changes with expected effect Ship approved changes and set up experiments Report what moved and what did not The review comes first every month, run against the full data set rather than a sample, so a recommendation is grounded in what actually happened last month and a hunch about what usually works never gets the final say. Approved changes ship the same month, each one set up as a measurable experiment rather than a change made on faith. What moved and what did not both get written into the report, so a change that failed to help is recorded as clearly as one that worked. The same experiment framework applies whether the change is a headline rewrite or a full page redesign, so results stay comparable month over month. What you receive The changes themselves, shipped and live rather than sitting in a backlog, each one tied to the number it was meant to move. Every experiment's result is recorded, win, loss or inconclusive, so the record of what was tried is as complete as the record of what worked. And the report itself: one page, written for a leader who has two minutes, showing what shipped, what moved, and what is queued for next month. Read across a year, the reports become a written history of how the site actually improved, one decision at a time, with nobody having to remember what happened last quarter from memory alone. Questions: - What do we get each month? Each month you get a full review of your data, three to five recommended changes, and the ones you approve shipped and tracked as experiments. Every experiment is measured against your own numbers, producing evidence you can check for yourself. It closes with a one-page report, written in plain language, that a leader can read in two minutes. - Do you implement or only recommend? We implement the changes you approve. A developer on our team, or yours, ships the change, and its effect gets measured the same month it goes live. The record shows what happened, with the reasoning behind each change written down. - Can we pause? Yes, the retainer runs monthly and you can pause it with thirty days notice. There is no lock-in beyond that window, and resuming later starts from the same observability data, already current. Nothing about pausing puts the underlying setup at risk. - How is this different from an agency retainer? It is measured against your own data, every month, in writing. Every recommendation is a specific change tied to numbers you can check yourself, both before it ships and after. The report is written for someone making a decision, in the time it takes to read one page. --- ## Process and Workflow Automation URL: https://airful.io/services/business-transformation/process-and-workflow-automation Type: Build The weekly task that eats your team's afternoon, gone by next month. We map the repetitive work in your operation, pick the two or three processes worth automating first, and build them: intake, routing, reminders, document generation, reconciliation, reporting. Built on the tools you already run, with a person kept in the loop where judgement matters. One to three weeks. The situation Somewhere in the business is a task that happens the same way every week and has for years: an intake form gets re-typed into your second system, a reminder gets sent by hand from memory, an invoice gets reconciled line by line against a bank statement. Nobody questions it anymore. It has been done this way long enough to feel inevitable rather than chosen. The cost shows up in two places. The obvious one is the afternoon it eats every week, usually from whoever is most reliable and therefore most likely to be handed the boring thing. The quieter one is the error that only surfaces when a customer complains, because nobody was watching the step closely enough to catch it first. What changes The task still happens, only now a system you own does the repeatable part while a person checks the result before it goes anywhere that matters. Intake routes itself, reminders fire on schedule, documents generate from data that is already correct because it was typed once, not five times. The clearest sign a process is ready to be built once and repeated forever is that everyone already knows exactly what happens next, every single time. What used to disappear into a person's afternoon now takes minutes, and the minutes it does take go to the exceptions: the case that does not match the pattern, the one that genuinely needs a judgement call. Those get flagged and handed to a person, clearly marked, so they never blend into a queue of routine work that looks the same from the outside. How it runs Map the processes and measure the time Rank by frequency, rules and error cost Build the first two or three with logging and alerts Run in parallel, then switch over, then hand over the runbook We start by mapping the processes as they actually run today, not as anyone remembers describing them in a meeting once, and timing how long each one actually takes across a normal week. That mapping session usually surfaces one or two processes nobody had mentioned before, because the person doing them had stopped thinking of the work as unusual. The ranking is not a guess. Frequency, how rule-based the steps are, and the cost of a mistake each get weighed, and the two or three processes at the top of that list are the ones we build first, with logging and an alert built into the first version from the start. What you receive You receive the automations themselves, live and running on the tools you already use, handling the two or three processes that were costing the most time or producing the most errors. Each one logs what it did and alerts a person the moment it hits a case outside what it was built to handle. Alongside them, a runbook written for whoever owns the process day to day: what the automation does, what triggers a manual check, and how you extend it when the process itself changes. A short monitoring view lets you see what ran, what got flagged, and what still needs a person, so the whole automation stays visible even once it is running well. Questions: - Which processes are worth it? The processes worth automating first are the ones that happen often, follow clear rules, and produce errors when someone on your team does them by hand. We map every candidate process with you and rank them by frequency, rule-clarity and the cost of a mistake. The ranking becomes the build order, agreed together before any code gets written. - Do you use no-code tools? We use no-code tools where they fit the process cleanly and hold up under real volume. For anything with more complex logic or a real error cost, we write code, and we tell you which choice we made and why. Either way, you get an automation built to last, with the reasoning documented. - What if it breaks? Every automation we build logs what it did, alerts someone if a step fails, and defaults to a person whenever it hits a case it was not built for. Nothing fails silently. You can see exactly where a run stopped and pick it up by hand within minutes. - Will our team lose control? No, your team keeps every decision that actually needs a person; the automation only takes over the repetitive steps around it. What changes is the time available for the judgement calls that were getting crowded out by data entry. The exceptions the automation cannot handle still land on your desk, flagged and ready for someone to review. --- # Digital Marketing URL: https://airful.io/services/digital-marketing Agentic marketing for operators who want the consistency of a system and the judgement of a team. Performance media, conversion, content, social and email programmes built on unified analytics, with narrative reporting that tells leadership what changed and why. Why this capability exists Most marketing runs on two things: what someone remembers about last quarter, and a report that arrives a month after the decisions it should have informed. By the time anyone reads that report, the campaign it describes has already ended, the budget has already been spent, and the lesson it contains arrives too late to change anything. Meanwhile the channels keep multiplying: paid media, content, social, email, conversion work, each with its own login and its own version of what happened. Nobody has the hours to hold all of that in memory and act on it daily, which is exactly why so much marketing decision-making defaults to whoever spoke loudest in the last meeting. We built this capability because a business deserves to know what is working while there is still time to act, before the money is already spent. What we believe about it We believe the system should know more this week than it knew last week. We feed every send, every post and every dollar of spend back into what we recommend next, so the guidance you get is sharper the longer the system runs. We also believe a person owns every publish and every spend decision, without exception, because judgement about tone, timing and risk is never something we hand off, however good a draft looks. Every draft still needs a person to decide if it goes out. And we believe reporting should read like a narrative, not a dashboard: what changed, what caused it, and what happens next, in language a founder can act on between meetings. How the engagements fit together You usually stand up the system first, because everything else in this pillar depends on data flowing into one place and a clear approval path before it flows out. Some clients build it alongside their first programme instead of before it, when one channel is leaking too much value to wait. From there, programmes get added as the business actually needs them, never all at once by default. Stand up the agentic system first, or alongside your first programme if one channel needs attention now Add programmes such as performance media, content, social, conversion or email as the business needs them Keep marketing intelligence and reporting running continuously underneath everything else Layer in answer engine optimisation so you get named when a buyer asks an AI assistant who to work with Marketing intelligence and reporting run underneath every programme from the day you stand the system up, because the narrative reporting only gets richer as more channels feed it. Answer engine work runs the same way: continuously, in the background, alongside whichever programmes are live, so being cited stays current instead of becoming another project someone has to remember to revisit. --- ## Agentic Marketing System URL: https://airful.io/services/digital-marketing/agentic-marketing-system Type: Build Marketing that knows more every week: data in daily, drafts and flags by system, decisions by you. We wire your analytics, ads, social, email and enquiry data into one daily pipeline, then add the agents: drafting content and ad variants, scheduling, flagging anomalies, routing leads, and writing the weekly digest. A person approves every publish and every spend change. Three to six weeks, then run monthly. The situation Most growth teams run marketing from memory. Someone remembers the newsletter is due, someone notices the ad spend crept up after the fact, and a post goes out when whoever owns the calendar finds a spare hour. The engine behind all of it is a person's attention, and attention runs out before the week does. Operators with several properties, brands or channels feel this hardest. Every one draws on the same analytics, the same enquiry inbox and the same handful of people, so work that should happen daily happens whenever someone gets to it. The monthly report is usually the first place anyone learns that a channel spent badly or a lead went cold, days after either could have been caught. Nobody is short on effort. The work has simply never had a daily rhythm to run on. What changes Once the pipeline is running, your data arrives every day instead of once a month: analytics, ad performance, social engagement, email results and every enquiry, landing in one place before anyone has to ask for it. We run agents against that data that draft content and ad variants, flag anomalies the day they appear, and route leads to the right person while the enquiry is still warm. We draft the work daily. You still decide what goes out. You keep the decision throughout. Every draft sits in an approval queue until you or your named approver signs off, and any change to spend needs the same signature. The daily work reaches you already assembled and tested, which leaves your time for judgment rather than production. A weekly digest gathers what moved and what needs a decision onto one page, so keeping up no longer takes a Monday morning of tab-switching. How it runs The build starts with connection. We pull every source into the daily pipeline first and backfill enough history that the first output already means something, before a single workflow gets built on top of it. Connect the data sources and backfill Encode brand voice, rules and the approval queue Build the agent workflows for drafting, scheduling, flagging and routing Run in shadow mode for two weeks, then live Hand over or move to monthly operation Shadow mode is the step most builds skip. For two weeks we run the workflows exactly as they will run live, drafting, flagging and queuing, with nothing reaching a channel until you sign off, so you see two weeks of real output before you trust the system with a live send. From there you either run it yourselves with the runbook we leave behind, or move to the monthly operation and let us keep running it for you. What you receive You receive the daily pipeline itself, running on its own schedule and reaching every source we connected. Alongside it, the agent workflows for drafting, scheduling, flagging and routing, built around your brand voice and your rules, and the approval queue where every publish and every spend change waits for a signature. You also receive the weekly digest and the runbook that documents how the whole system works, so a new hire can pick it up without sitting through a training session again. Any advertising spend runs through your own ad accounts throughout and is never part of our fee. Questions: - Does the system publish on its own? No. We draft and queue every piece, and you approve what actually publishes. Rules you set decide which routine items can move once you have trusted them, and which always wait for a person. - Which channels? We cover web, paid social, organic social, email and messaging. Every channel connects into the tools you already use, so your team keeps working where it already works. - What is the running cost? Model and tooling costs pass through at cost and are usually small. If you want us running the system month to month, that sits on top as a separate monthly engagement. - Is this generic content generation? No. Every draft we produce is grounded in your data, your brand voice and your approval history. It is never written from a generic prompt with your name dropped in. --- ## Answer Engine Optimisation URL: https://airful.io/services/digital-marketing/answer-engine-optimisation Type: Assessment Know how AI assistants describe you today, and what to change so they cite you tomorrow. A one-week audit of how your brand appears when someone asks an AI assistant who to work with: what is said, what is missing, which sources are cited instead, and a three-month plan to change it. Continues as a monthly programme that tracks citations and ships the content and structure that earn them. The situation Buyers have started asking an assistant before they open a search bar. They describe the problem and take the two or three names the assistant offers, drawn from whatever it has read and trusts. That answer is being given today, with or without your business in it. Most businesses have no idea what that answer currently says. A brand can rank first on search and still be absent from the answer, or worse, be described inaccurately from an outdated page you never took down. You will rarely find the obvious sources among what gets cited, and nobody has looked closely enough to say why one competitor keeps coming up and another never does. The channel is already live. The only question is whether your business shows up in it. What changes You get a plain reading of what several assistants currently say about your business, run against a query set built from how your own buyers actually ask. Where you are missing or wrong, we show it; where a competitor is cited instead, we show which source earned that citation and why. You earned search rankings one way. Getting cited by an assistant takes different work. The three-month roadmap that follows turns that reading into a sequence: which structural changes come first, which content pieces close the biggest gaps, and in what order. You are not guessing at a channel with no evidence behind it. You are working from a scored baseline and a plan built to move it, with a monthly programme ready to run the plan once the audit ends. How it runs We start with your language rather than ours, building the query set from the questions your actual buyers would put to an assistant and the competitors they would be weighed against. Build the query set Measure across assistants and score Diagnose structure, entities and content gaps Deliver the roadmap and start the monthly loop Diagnosis is where most of the week goes. We trace each weak or missing answer back to a cause, whether that is a structural gap, an entity your site never establishes clearly, or content that simply does not exist yet, so the roadmap addresses causes rather than symptoms. What you get at the end is a plan any team could pick up and execute. What you receive You receive the written report itself: what several assistants currently say about your business today, scored for mention, accuracy and citation, and set clearly against your named competitors. Alongside it, the diagnosis behind the score, covering structure, entities and content gaps in plain, specific terms. You also receive the three-month roadmap that turns the diagnosis into an ordered sequence of work, written clearly enough to hand to whichever team is going to build it. If any part of the roadmap includes paid promotion, that spend stays in your own accounts and is never part of our fee. Questions: - What is answer engine optimisation? It is being described accurately and cited when a buyer asks an assistant. That depends on your site's structure, the entities it establishes and content worth citing, and much less on keywords. - How do you measure it? We run a fixed query set against the major assistants and score each answer for mention, accuracy and citation. We repeat the same query set monthly so the score becomes a trend you can watch move. - What is the monthly programme? It is the tracking plus the content and structural changes that move the score, priced at a thousand dollars a month. It picks up directly from the roadmap this audit delivers. - Is this instead of search? No, it is the next channel beside it. The structure and content that earn a citation from an assistant tend to help your search ranking too. --- ## Content Creation URL: https://airful.io/services/digital-marketing/content-creation Type: Retainer A publishing cadence that holds, in a voice that is unmistakably yours. Editorial, video and long-form content produced monthly by a system that drafts from your data and a person who edits to your voice: articles written to be cited by answer engines, short video from a template pipeline, newsletters and case-study pages. Consistent, on time, and measured. The situation Most founders have the thinking already. They can explain the business, the market and the decision behind every choice in five clear minutes on a call, and then the month ends without a word of it written down. The blog carries a post from a year ago, and the newsletter list has not heard from the business in longer than that. The gap is rarely ideas. It is the hour it takes to turn a thought into a finished piece, found on a day already full of client work. Buyers increasingly ask an assistant before they search, and if you have not published anything recently, you have nothing current for it to cite. Visibility now depends on being cited, and citation depends on a cadence that has not existed here for a while. What changes A monthly plan replaces the blank page. We draft from an interview or your own voice notes and from your data, so the first version already sounds like something you would say rather than a template filled in with your name. A cadence turns a good thought into something the internet can actually find. You edit and approve before anything ships, and the voice guide behind every draft gets sharper each month as we learn what sounds like you and what does not. Articles are written to earn a citation from an answer engine, which means structure and clear claims matter as much as the sentences themselves. The blog, the newsletter and the case-study page start moving on a rhythm instead of a memory. How it runs Every month starts with your voice. A short interview or a set of voice notes from you feeds the plan, so the pieces we build that month are grounded in what you actually said rather than what a template assumes founders say. Build the voice guide and the monthly plan Interview, draft, edit Publish and distribute Measure and adjust next month Drafting and editing run as two distinct steps, never collapsed into one. We produce the first draft; a person on our side edits it against your voice guide before it ever reaches you for approval. Publishing follows once you sign off, and the following month opens with a review of what the last one produced. What you receive You receive the monthly content plan itself, and every piece produced against it: articles, newsletters, case-study pages, short video and scripts, in whichever mix that month's plan called for. Alongside the pieces, the voice guide that keeps them sounding like you, updated as it earns new evidence of what works. You also receive the monthly performance review, showing what was cited, what ranked and what readers engaged with, so next month's plan starts from evidence rather than a guess. If any channel in the mix carries paid promotion, that spend stays in your own accounts and is never part of our fee. Questions: - Is it AI-written? We draft with models from your own words and data, and a person edits every piece. Nothing publishes without your approval. - What formats? We produce articles, newsletters, case-study pages, short video and scripts, chosen for where your buyers actually look. The exact mix is agreed fresh each month. - How do you keep our voice? We build a voice guide from your existing writing and from interviews with you, and we apply it to every draft. The guide gets refined as we see what sounds like you and what does not. - How is it measured? We measure against citations, search performance and engagement, reported to you monthly. The same numbers decide what gets made again and what gets dropped. --- ## Conversion Rate Optimisation URL: https://airful.io/services/digital-marketing/conversion-rate-optimisation Type: Programme The three biggest leaks in your funnel found, tested and fixed in four weeks. A four-week sprint that uses your analytics and session recordings to find the three largest conversion bottlenecks, builds and runs structured experiments against them, and ships the winners. Recommendation and implementation in one engagement, with a documented gain at the end. The situation Traffic arrives. Enquiries do not follow in the numbers the traffic would suggest, and the gap between the two sits somewhere in a funnel nobody has actually watched a visitor move through. Everyone in the room has a theory about why: the form is too long, the price is on the wrong page, the booking calendar is confusing. Opinions are cheap and every one of them sounds plausible. Some teams have already paid for a CRO report that named a dozen possible fixes and left the ranking and the building to them, which is where the report usually stayed. Without a way to test cheaply, teams either ship the loudest opinion in the room or ship nothing at all, and the site keeps converting at the same rate while everyone argues about which theory is right. What changes Four weeks produce evidence on the three leaks that matter most. The funnel data and the session recordings replace opinion with a ranked, defensible shortlist, and each hypothesis earns its place by the traffic and drop-off behind it, not by who argued loudest for it. Watch enough sessions and the funnel stops arguing with you. Winners ship inside the same engagement, so the sprint ends with a change already live and a documented gain behind it, not a recommendation waiting for a future budget. A method comes with it too: the next round of hypotheses follows the same path, so the business keeps testing after the four weeks end. How it runs The sprint opens with observation. We work through the analytics and enough session recordings to see exactly where visitors hesitate, backtrack or leave, building a picture of the funnel from real behavior before a single hypothesis gets written down. Analyse the funnel and watch the recordings Rank hypotheses and agree three Build variants and run the experiments Ship winners and write up the results Three is a deliberate limit. Chasing a dozen ideas at once dilutes the traffic each one gets and delays every result, so we run three well-powered tests instead and let the data decide each one on its own schedule. Winners ship as soon as they are proven; losers are documented and dropped. Each experiment runs only after you approve it, so nothing reaches your full audience without a decision you made first. What you receive You receive the funnel analysis itself: where visitors hesitate, where they backtrack, and where they leave, mapped from your own analytics and recordings rather than a generic conversion checklist. Alongside it, the three experiments we ran, built and shipped on your site behind a flag, with the reasoning for each documented as it was made. You also receive the written results: what won, what did not, and the gain each winner produced, stated plainly either way. If paid channels feed the funnel we tested, that spend stays in your own accounts throughout and is never part of our fee. Questions: - How do you pick what to test? We pick from the funnel data and the session recordings, ranked by traffic and drop-off, and agree the shortlist with you. The three tests we run are the three with the largest, most defensible upside. - Do you need a lot of traffic? You need enough traffic to read a result within the four-week sprint. Where traffic is lower, we test bigger, more visible changes so a result still emerges in the time available. - Who builds the variants? We build the variants, on your site, behind a flag. Nothing goes live to your full audience until the experiment has run its course and you have seen the result. - What if nothing wins? You still learn where the leak is not, which narrows the search considerably. The report says so plainly, and that finding becomes the starting point for the next hypothesis. --- ## Email Revenue Systems URL: https://airful.io/services/digital-marketing/email-revenue-systems Type: Build The flows that make money while you sleep, built properly and measured honestly. An audit-first build of the email systems that produce revenue: list hygiene and segmentation, welcome, abandoned-cart, post-purchase and re-engagement flows, behavioural tagging from your platform, and reporting by flow. Two to three weeks on the email platform you already use. The situation Most businesses with a list have a newsletter and nothing running behind it. Someone welcomed a subscriber manually eighteen months ago and nobody wrote the automation, so every new subscriber since has landed in a silent list. Carts get abandoned and nobody follows up. A purchase completes and the customer never hears from the business again until the next sale email goes out to everyone at once. The tool itself is rarely the problem. Most platforms already support flows, tags and segments, and the account is paying for capability nobody has switched on. Membership and booking businesses feel this sharply, because the behavioral signal is right there in the platform, a booking, a renewal, a lapsed visit, and none of it triggers anything. Revenue that should arrive automatically instead depends entirely on someone remembering to send a one-off campaign. What changes The account gets audited before anything gets built, because dead segments and broken automations are common and worth finding first. Once the audit is done, we build the flows that actually produce revenue: welcome, abandoned-cart, post-purchase and re-engagement, each one tagged from real behaviour on your platform. A welcome email a customer never sees might as well not exist. You approve every flow before it goes live, and every flow reports on its own, so you can see which one is earning its place and which needs a rewrite. The list stops being a static file that gets emailed occasionally and starts behaving like the asset it always could have been. How it runs We audit first because building on top of a broken account wastes the build. Dead segments, misconfigured automations and gaps in list hygiene get found and fixed before a single new flow gets designed. Audit the account and the list Design segments, tags and the flow map Build flows and templates, wire events Test, launch, and report by flow Segmentation and tagging come next, built from real events on your platform rather than guesswork about who your customers are. Flows are built and tested against real send paths before launch, and once live, each one reports separately, so you can see exactly which flow is earning its place and which one needs another look. Every stage waits on your sign-off before it goes live. What you receive You receive the flows themselves: welcome, abandoned-cart, post-purchase and re-engagement, built, tested and live on the platform you already run. Alongside them, the segmentation and tag taxonomy behind every flow, wired to real events from your website or store rather than a guess about customer behaviour. You also receive reporting broken out by flow, so performance is visible one at a time rather than buried in a single account number. If any campaign built on top of this work involves paid promotion, that spend stays in your own accounts and is never part of our fee. Questions: - Which platforms? We work on the major commerce and marketing email platforms, and we have built flows on several of them already. We use whichever one you already run, so your team keeps its existing workflow. - Why audit first? Most accounts carry dead segments, broken automations and profiles that have never received a message. The audit finds that revenue sitting on the floor before we build a single new flow. - Do you write the emails? Yes, drafted in your voice and approved by you before anything goes live. Nothing in a flow sends without your sign-off on the copy. - What about deliverability? Domain authentication and list hygiene are built in from day one. A flow that sends beautifully and lands in spam has not actually shipped. --- ## Marketing Intelligence and Reporting URL: https://airful.io/services/digital-marketing/marketing-intelligence-and-reporting Type: Retainer A weekly narrative that tells leadership what moved, why, and what to do about it. Analytics-driven insight generation on top of unified data: weekly and monthly narrative reports written by a system and read by a person before they reach you, anomaly flags the day they happen, and a monthly working session. The reporting layer for every marketing programme we run. Setup, then monthly. The situation Numbers are everywhere and insight is nowhere. A leadership team opens three dashboards before a Monday meeting, each one accurate and each one silent about what actually matters this week. Someone eventually asks the obvious question, what changed and why, and the room goes quiet while somebody scrolls. Reporting tools get bought to fix this and mostly sit unopened, because a dashboard answers questions nobody asked and stays mute on the one that came up in the meeting. Businesses running several programmes with us feel it most: separate numbers from separate engagements, no single narrative tying them together, and a founder left to reconcile five views of the same quarter in their head before the board call. What changes You get a narrative instead of a wall of charts. Every week, a short digest lands on what moved and what it means, with anything needing a decision named plainly. Every month, a longer report reads the quarter the way a person would explain it out loud, in language a director can act on directly. A page you can read is worth more than a dashboard you have to interrogate. Anomalies get flagged the day they happen, before they surface in a review nobody scheduled. Because it is the reporting layer underneath every marketing programme we run for you, one working session a month covers all of them, instead of a separate stand-up for each programme. How it runs Setup starts by asking what leadership actually wants to know, which is a shorter list than the dashboards suggest. We build report templates and anomaly rules against your unified data so the first draft already answers questions your team actually asks. Agree the questions and the audiences Build templates and anomaly rules on your data Run weekly and monthly, edited by a person Review together once a month Once running, the weekly digest and the monthly report arrive on their own schedule, each one drafted from data and edited by a person before you see it. The monthly working session is where you push back on the narrative, adjust what gets tracked, and raise the next question worth building a report around. What you receive You receive the weekly digest and the monthly narrative report, both written from your unified data and edited by a person before they reach you. Alongside them, the anomaly flags that arrive the day something moves, and the monthly working session where we go through what the numbers mean together and agree what to watch next. If any of the underlying programmes involve paid media, that spend stays in your own accounts throughout and is never part of our fee. What you keep, across every report, is a narrative you can hand to a board without translating it first. Questions: - Is the report written by a machine? We draft it from your own data, and a person reads and edits every draft before it reaches you. Nothing arrives unchecked. - What is in the weekly digest? The digest holds what changed, what it means, and anything that needs a decision, on one page. It is built to be read in the time it takes to finish a coffee. - What is the setup fee? The setup fee runs between fifteen hundred and thirty-five hundred dollars depending on how many sources feed the reports. It is agreed on the scoping call, once we know what you already have connected. - Can it feed our board pack? Yes. The monthly report is written to be pasted straight into a board pack, with the narrative already in a form a director can read without a translator. --- ## Performance Marketing URL: https://airful.io/services/digital-marketing/performance-marketing Type: Programme Paid media run as a measured system, with every spend decision grounded in yesterday's data. Paid social and search built and run as a system: tracking that reaches the enquiry and the booking, structured campaigns for prospecting, retargeting and messaging, daily performance logging with automatic flags, and a person deciding what to scale. Two-week setup, then monthly. Ad spend stays with you. The situation Money leaves the ad accounts every day, and the business spending it can rarely say which campaign produced which booking. Retargeting is often missing entirely, so a visitor who nearly booked simply never sees the business again. Tracking usually stops at the click, sometimes reaches the form, and almost never gets as far as the enquiry or the calendar, which is the only place that tells you whether the spend actually worked. Left with that gap, most decisions come from the platform's own dashboard, graded against a goal the platform itself defined. That number can look strong and still miss the booking that paid for the month. Operators feel the imbalance clearly: spending steadily, watching the numbers move, and still unable to answer the one question that matters, which campaign earned the right to be funded again. What changes Tracking now reaches the enquiry and the booking, so a campaign is judged by what it actually produced. Campaigns are restructured around prospecting, retargeting and messaging as three distinct jobs, each measured on its own terms rather than blended into one number that hides which part is working. You see what a dollar earned before the week is out. We log performance daily and flag waste the day it appears, before a month's budget has already gone out the door. A visitor who leaves without booking is now followed by retargeting built for that exact moment in the funnel, rather than a generic ad running everywhere at once. You decide what to scale, working from a report that already shows what earned it. How it runs Tracking comes first because every later decision depends on it. We fix the pixels, events and offline conversions until spend can be traced all the way to an enquiry and a booking, not just a click, before any campaign architecture gets built on a foundation nobody has verified. Fix tracking through to enquiry and booking Build the campaign architecture and first variants Switch on daily logging and flags Review weekly, decide monthly, write it down Once logging is live, waste gets flagged the same day it happens, well before it would otherwise surface in a report weeks on. You review the numbers weekly and make the scaling calls monthly, and every decision gets written down, so the campaign history explains itself the next time someone asks why a budget moved. What you receive You receive the tracked funnel itself, wired from the ad platforms through to the enquiry and the booking, so every future report rests on numbers you can trust. Alongside it, the campaign architecture and the creative variants built to run in it, structured around prospecting, retargeting and messaging as three separate, measured jobs. You also receive the daily log with its flags, and the monthly report that ties spend to what it produced. Ad spend stays in your own accounts throughout, paid by you directly to the platforms, and is never part of our fee. Questions: - Do you handle our ad spend? No. Your ad spend stays in your own accounts throughout, and it is never part of our fee. We manage the campaigns; you fund the budget directly with the platforms. - What is the monthly fee? The monthly fee runs from fifteen hundred to three thousand dollars depending on the channels in scope. It is stated in the engagement block on this page, beside the setup fee. - Which platforms? We run the social and search platforms where your buyers actually are, chosen from your data and not from habit. Which platforms qualify can change as the data changes. - How soon do we see results? Tracking is fixed in week one, so every dollar spent after that is measured. The first month establishes the baseline, and we optimise against it from month two onward. --- ## Social Media Management URL: https://airful.io/services/digital-marketing/social-media-management Type: Retainer Channels that post on schedule, sound like you, and report what they produced. Social channels run as a system: a monthly calendar built from your content and data, posts drafted and scheduled by the pipeline, a person approving and replying, and a report that ties activity to enquiries. For operators who want presence without a daily chore. The situation Posting happens when someone remembers to post. A good week produces three pieces of content and a quiet one produces none, and the gap between them tracks whoever on the team currently has a spare afternoon rather than anything the audience actually needs. Hospitality, wellness and service businesses feel this most, because their customers are already looking on social before they ever reach the website. Many teams already have a designer making things look right and nobody turning that into a schedule that holds. A comment sits unanswered for two days because nobody owns replying. Nobody can say afterward whether any of it produced an enquiry, because the posts and the enquiry log have never been looked at together. Presence exists, sporadically, and nobody is quite responsible for whether it works. What changes A monthly calendar replaces the guess about what goes out this week. We build it from your content, your brand assets and your own data on what has worked before, then draft and schedule against it so the pipeline handles the routine parts and a person handles judgment. A channel that posts on a schedule starts sounding like a business that is actually there. You approve the month in one sitting rather than a post at a time, and replies happen inside hours you set, with anything sensitive routed to you directly. A monthly report closes the loop by tying posts back to the enquiries that followed them, so presence stops being a feeling and becomes something you can point to. How it runs We start by auditing what exists and cutting the channels that are not earning their place. A business rarely needs to be everywhere; it needs to be reliably somewhere your buyers already look. Audit channels and choose the ones that matter Build the calendar and the drafting pipeline Approve, schedule, reply Report monthly Once the calendar is running, drafts arrive on their own schedule for your monthly approval session, and scheduling happens automatically once you have signed off. Replies follow the policy you set, with anything outside it held for you rather than answered on your behalf. The report at month's end shows what ran and what it produced, which becomes the input for next month's calendar. What you receive You receive the monthly calendar itself, built from your content and your own performance data, and the drafting and scheduling pipeline that keeps it running day to day. Alongside them, the reply handling inside the hours you set, with anything sensitive escalated straight to you. You also receive the monthly report tying activity to the enquiries it produced, plus the growing library of captions and creative assets built up as the calendar runs. If any posts in the calendar are boosted or promoted, that spend stays in your own ad accounts and is never part of our fee. Questions: - Which channels? We run the two or three channels where your buyers actually are, chosen from your data. A channel earns a place on the calendar; it does not get added by default. - Do you reply to comments? We reply within the hours you agree and the rules you set. Anything sensitive is routed straight to you. - How much do you post? We agree a cadence monthly and hold it, valuing consistency over volume. A quiet week with three good posts beats a noisy one with ten forgettable ones. - Can this run with paid campaigns? Yes. Organic and paid share the same calendar and the same report, so a promoted post and an organic one are planned together as one effort. --- # AI Governance and Security URL: https://airful.io/services/ai-governance-and-security Assessment and build work that gives leadership a defensible picture of where AI reaches data and decisions, installs the controls that keep it that way, and tests the AI systems you build before someone else does. Why this capability exists AI arrived in most organisations without a decision being made. Someone started drafting with it. A tool got connected to email and files because a button offered to. A feature shipped inside a product because it was easy. None of that was wrong. What is missing afterwards is the ability to answer three plain questions: what AI is touching our data, who authorised it, and what happens when it does something we did not intend. Most organisations do not have an AI problem. They have an ownership problem that AI made visible. What we believe about it Prohibition does not work. It moves usage onto personal accounts where nobody can see it, and it costs you the productivity your competitors are quietly gaining. The useful position is enablement with visibility: know what is in use, decide what may reach which data, and put a name against each decision. Identity is the perimeter. Most intrusions today begin with a valid login rather than malware, and an AI assistant inside your environment inherits the permissions of whoever asks it a question. Half of the exposure people worry about in an AI tool was already there in an over-shared folder. The assistant simply made it easy to notice. Evidence beats assurance. A policy that says controls exist is documentation. A record that shows who decided, what the system could reach and who could stop it is governance. Everything we deliver is written to be shown to an auditor, an insurer or a customer, not filed. How the engagements fit together Discovery comes first. The assessments give you the inventory, the data map and the configuration facts. The builds turn the decisions those facts force into controls, policy and evidence inside the platforms you already run. The continuous seat keeps direction and ownership alive as the tools and the rules change, which at present is every quarter. Start with the assessment that matches your exposure: usage, an AI system you ship, or the platforms your business runs on Read the findings with the people who own the decisions, not only the IT team Choose the controls and policy worth installing, sequenced by risk and effort Keep a named person responsible for the loop, inside your team or through us Who delivers it Airful fronts the work and holds the relationship. Delivery is by security practitioners who work as Airful consultants, under Airful's engagement terms and insurance. Where a client needs legally independent assurance or a formal certification, we say so and route it to a qualified third party rather than pretend to provide it. --- ## AI Application Security Assessment URL: https://airful.io/services/ai-governance-and-security/ai-application-security-assessment Type: Assessment Know how the AI feature you shipped can be misused, before someone shows you. A structured assessment of a language-model feature or agent you have built or bought: threat modelling of prompt injection, data leakage through retrieval, over-broad tool permissions, and model and vendor handling of your data, with hands-on testing and a prioritised fix list. One to two weeks. The situation You shipped a chat, matching or extraction feature, or gave users an assistant that can call tools inside your systems, because speed mattered more than caution at the time. That trade made sense in the moment. You rarely test afterward what a determined stranger can get the feature to do, or check what the company behind the underlying model does with the data you send it. You do not know whether the feature will repeat back a document it should not surface, or whether the tools you gave it are reachable in ways nobody intended. Then a customer's security team sends a questionnaire, an insurer asks for evidence, or a curious user finds the edge case first, and you answer from memory because there was never a test to point to. The exposure was there before anyone went looking for it. What changes You move from trusting the feature because it shipped, to trusting it because you tested it against someone trying to break it. We build a threat model naming exactly how the feature could be misused: through the words a user types, through documents or search results it retrieves, through the tools it can call, and through what the vendor behind the model receives when you send it data. A feature earns your trust the day it survives someone actually trying to break it. We confirm each path by testing your working system directly, so nothing here is inferred from a diagram alone. You also receive a fix list ranked by what an attacker could do and how hard closing the gap is, so your engineers know what to fix first and what can reasonably wait. How it runs Agree scope, environment and authorisation Review the architecture and build the threat model Test against the model with real inputs Write findings with severity and fixes Replay with your engineers Scope comes first: which feature, which environment, and what authorisation your organisation is giving us to act like an adversary against it. We agree a stop condition before any testing starts, so the boundary between test and production is never in question. From there we build the threat model from your actual architecture, not a generic checklist, because the permissions you granted and the data your retrieval step can surface differ in every build. Testing itself runs against real inputs an attacker would try: injected instructions, boundary cases in retrieval, permission checks pushed past their limits. We write findings as we confirm them, so severity reflects what a finding actually lets someone do rather than how alarming it sounds on paper. The replay session puts your engineers in the room with the exact reproduction steps. What you receive You receive the threat model itself, written in plain terms your engineers and your leadership can both read: every path we tested, and why it matters for this particular feature. Alongside it, the full findings: what we found, how we found it, and the exact steps to reproduce each one, so nothing has to be taken on faith. You also receive the fix list, ordered by what an attacker could actually do, and the replay session, where your engineers watch each finding reproduced and ask their own questions about it. Take the governance controls build next, and the fixes here become logged, monitored controls instead of a report that sits in a folder unread. Questions: - What do you actually test? We test injection through inputs and retrieved content, leakage across users and documents, what tools the agent can call and with whose permissions, and how the vendor handles the data it sees. We run these against your actual build, using real inputs designed to find the edge cases a normal user never reaches. - Is testing safe for our production system? Testing runs against a test environment under written authorisation with a stop condition you control. We never touch your production system during the work, and you can halt it at any point without needing to explain why. - Do you fix the issues? We deliver fixes for every finding, each scored by severity and the effort to close it. Your team can implement them directly, or ours can, whichever fits how you work. - Can this satisfy a customer's security questionnaire? It gives you the evidence to answer a questionnaire honestly, which is what most questionnaires actually ask for. You get the threat model, the test results and the fix list as the backing for every claim you make. --- ## AI Discovery and Data Exposure Assessment URL: https://airful.io/services/ai-governance-and-security/ai-discovery-and-data-exposure-assessment Type: Assessment Know every AI tool touching your data, what it can reach, and who let it in. A read-only assessment that inventories every AI tool and AI-connected application in use across your organisation, maps the data each one can reach and under whose authority it was granted, and hands you a keep, restrict or revoke decision for each. One to two weeks, a couple of hours of your time. The situation Your people are already using AI. In most organisations it arrived one person at a time: a drafting assistant here, a meeting summariser there, a plug-in that offered to read the inbox and was allowed to. Each choice was reasonable. Together they add up to a set of standing permissions over your email, your files and your customer data that nobody has listed, let alone approved. The exposure is rarely where leadership expects it. The browser tab someone types into is visible and usually harmless. The application that was granted permission to read every message and file in the organisation, by an employee who left last year, is neither. When a customer, an insurer or a regulator asks what AI touches their data, the honest answer today is usually that nobody knows. What changes At the end of the engagement you hold an inventory you can defend. Every AI tool and AI-connected application in use, which parts of the business use it, exactly what data and permissions it holds, and who granted them. Each item carries a risk ranking and a recommended decision, so the conversation with leadership is about choices rather than discovery. You also learn something the inventory alone does not show: which business needs are driving unsanctioned use. That list usually points to two or three tools you should be providing properly, which is the difference between a governance exercise that restricts and one that enables. The goal is not to catch anyone. It is to replace a guess with a record. How it runs A scoping call to agree the platforms in scope, typically your collaboration suite and identity provider, and to provision read-only access We inventory connected applications, permission grants and AI features from the platforms' own audit and administration data, which records activity regardless of whose device produced it We map each tool to the data it can reach and rank it by vendor data handling, permission scope and sensitivity A two-hour findings session with your nominated data owner to test the ranking against how the business actually works A written report and a decision list, delivered with a short note on what to do first Nothing is changed by us during the assessment. Where a revocation or restriction is recommended, your administrators make the change with our guidance, which keeps you in control of your own environment. What you receive A complete inventory of AI tools and AI-connected applications, and the parts of the business using each. The exact data and permission scope each one holds, and under whose authority it was granted. A risk ranking and a keep, restrict or revoke recommendation per item. A short approval process for future connections, so the list does not simply regrow. And a view of the unmet needs behind unsanctioned use, which is often the most useful page in the report. Keep the approval process running and the inventory stays current; where you want new AI connections flagged as they appear, we can monitor for them as part of the controls build. Questions: - What counts as an AI tool in this assessment? Anything that sends your data to a model: consumer assistants used through the browser, AI features switched on inside the software you already pay for, and third-party applications granted standing permission to read your email, files or calendars. The last group is where most of the exposure sits, and it is the group nobody has usually reviewed. - Will this disrupt our team or slow anyone down? No. The assessment runs on read-only access and log data. Nobody is asked to stop using anything while it runs, and no setting is changed by us. The findings session is the only time we need from your people beyond the initial scoping call. - What do we actually receive at the end? A written inventory of every tool and connected application, the data and permission scope each holds, a risk ranking based on the vendor, the scope and the sensitivity of what is reachable, and a recommended keep, restrict or revoke decision for each item. It is written so a general counsel or a board can read it without a technical translator. - Can this feed into a governance programme run by someone else? Yes, and it is designed to. Governance advisors decide what AI should and should not do in your business. This assessment gives that work its facts. We deliver the findings in a form their assessment can rely on and stay available to them for questions. --- ## Governance Controls Build URL: https://airful.io/services/ai-governance-and-security/governance-controls-build Type: Build The decisions your governance work produced, installed as controls in the platforms you already run. We turn an AI governance design into working controls: an AI system register, approval workflow for new tools, data-classification and sharing rules, logging and retention, monitoring data reaching AI services, and evidence an auditor or insurer can read. Built inside your platforms over two to six weeks. The situation You went through a governance assessment, or wrote the policy yourselves, and reached real decisions: which AI tools may touch customer data, who approves a new connection, how long logs are kept. Those decisions live in a document, a slide deck, or the notes from a workshop. Nobody has gone back and built them into the platforms your business actually runs on. The exposure the assessment found has not moved, because a decision that only exists on paper does not stop anyone from doing anything. Six months from now, the same conversation happens again: the same gaps, the same recommendations, because deciding and installing turned out to be two different pieces of work, and only the first one got done. What changes Your decisions stop being a document and start being the way the platform actually behaves. The tool a new hire tries to connect either matches an approved pattern or waits for a real approval. Data classified as sensitive carries sharing restrictions that hold, because the platform enforces them rather than a policy asking politely. A decision that only lives in a meeting note has not actually been made yet. The register at the centre of it stays current on its own, updated by the approval workflow every time something changes, so you are never presenting a document that was accurate six weeks ago, and an auditor or an insurer can see exactly when each control last changed. How it runs Translate decisions into a control list with owners Implement in the platforms you already run Stand up the register and approval workflow Switch on monitoring and evidence reports Hand over with a runbook We start from your decisions, not from a generic control framework, translating each one into a specific control with a named owner and a platform it lives in. Implementation happens inside the tools you already run: your identity provider, your collaboration suite, your data platform, so nothing new appears for your team to learn. Once the controls exist, we stand up the register and the approval workflow that keeps it accurate, then switch on monitoring for new connections, data reaching AI services, and control drift, with reports landing in your inbox every month. Handover includes a runbook, so the loop keeps running under your own team if that is the direction you choose. What you receive You receive the controls themselves, installed and enforcing inside the platforms you already run rather than living in a separate tool your team has to remember to check. Alongside them, you get the register: every AI system in use, its owner, its data and its approval, kept current automatically by the workflow underneath it. You also receive the approval workflow itself, the monthly monitoring and evidence reports, and a runbook that hands the whole loop to your team with nothing left implicit. Afterwards someone has to keep the loop running: a named owner inside your team, or a standing seat we provide. Questions: - We have a policy. Is that not enough? A policy says controls should exist. This installs them, and produces the record that shows they actually work. - Do you replace our governance advisor? No, we implement their design and hand the evidence back to them. Their assessment stays the one governing the decisions; we simply build what it calls for. - What is an AI system register? You keep an AI system register: a maintained list of every AI system in use, its owner, the data it touches and its approval status. The approval workflow keeps it current automatically, so you never depend on someone remembering to update a spreadsheet. - What does monitoring cover? Monitoring covers new AI connections, data moving to AI services, and control drift. We report all three to you every month, so nothing changes quietly between reviews. --- ## Policy and Evidence Pack URL: https://airful.io/services/ai-governance-and-security/policy-and-evidence-pack Type: Build The documents auditors, insurers and enterprise customers ask for, written to be used. A proportionate policy set for your size: acceptable use covering personal devices and AI tools, data classification, access and joiner-leaver procedure, incident response with named roles, and an evidence pack that maps each policy to the control that satisfies it. Two to three weeks, with an annual review option. The situation Most businesses this size have no written policies at all, or they have a set someone downloaded years ago, renamed, and never opened again. Nobody in the building could tell you what the incident response plan says, because there has never been one, or because the one that exists was written for a business twice this size and nobody adjusted it. Then a customer's procurement team sends a security questionnaire with a deadline on Friday, or the insurance renewal asks what your incident process actually is, and there is nothing accurate to send. Writing something under that kind of deadline pressure rarely produces a document anyone can stand behind a year later. What changes You get a policy set sized to your actual business: acceptable use, data classification, access and joiner-leaver procedure, and incident response with a named person against every role. Each policy maps to the control that actually satisfies it, so when someone asks how a rule is enforced you have a real answer rather than a paragraph of intent. A policy nobody has read protects nobody, least of all the business that wrote it. The whole set assembles into one evidence pack, organised the way the questionnaires you actually receive are organised, so answering one stops being a week of writing and starts being a matter of finding the right page. How it runs Interview and collect what exists Draft the set proportionate to your size Review with leadership and adjust Map policies to controls and assemble the pack We start with an interview covering how your business actually runs, plus whatever documents already exist, used or not, so nothing gets rebuilt from nothing when a usable piece is already sitting in a drawer. From there we draft a set proportionate to your size: enough to be credible to an auditor, small enough that your team can actually read it in one sitting. Leadership reviews the draft and adjusts anything that does not match how the business really works, because a policy leadership has not actually agreed to is not a policy your staff will trust. Once it is approved, we map every policy to the control that satisfies it and assemble the evidence pack, ready for the next questionnaire that lands. What you receive You receive the policies themselves: acceptable use, data classification, and access and joiner-leaver procedure, each one written in language your staff will actually read. Alongside them, the incident response plan, with named roles against each step so nobody is improvising who calls whom at two in the morning. And you receive the evidence pack: every policy mapped to the control that satisfies it, assembled and ready to hand to an auditor, an insurer, or a customer's procurement team the next time they ask. Take the annual review if you want the set to stay current as your business changes, rather than drifting quietly out of date the way most policies do. Questions: - Are these templates? No, we write them from how your business actually operates. That is the only way staff read them and follow them when it matters. - Can they answer an enterprise questionnaire? The pack is organised to answer the common enterprise questionnaires directly, section by section. You can hand it to whoever is asking and point them straight to the relevant answer. - Do you provide legal advice? No, where a regulation applies we map the obligation into the pack and recommend your counsel confirm it. That keeps the legal judgement with a qualified professional, where it belongs. - What about our AI use? Acceptable use covers AI tools directly: what may be shared with them, and how staff tell the difference in the moment. It is one section inside the same pack, so nobody treats it as a special case. --- ## SaaS and Identity Posture Assessment URL: https://airful.io/services/ai-governance-and-security/saas-and-identity-posture-assessment Type: Assessment How the platforms your business runs on are actually configured, and what to fix first. A read-only review of your email and collaboration suite, identity provider and core apps: multi-factor coverage, administrative privilege, external sharing, mail rules, logging and retention, and every third-party application holding standing access. A remediation plan your administrators can execute in a week. The situation Every platform your business runs on shipped with defaults chosen to get you adopting it quickly, not to keep you safe. Multi-factor authentication got turned on for some accounts and quietly skipped for others. A contractor kept access after the project ended because revoking it was one more task nobody got to. An early employee granted a third-party application permission to read the whole mailbox, and neither the employee nor the application has been looked at since. None of these choices was reckless on its own. Together they form a shape nobody in your organisation has ever stood back and looked at, because owning that whole picture was never anyone's job. When a customer or an insurer finally asks how your accounts are actually configured, the honest answer today is that nobody knows. What changes You get a clear picture of how every platform is actually configured against a recognised baseline, not against what you assumed when it was set up. Multi-factor gaps, administrative privilege sitting with people who no longer need it, external sharing left open, mail rules nobody remembers creating, and every third-party application still holding standing access: all named, all ranked, and all traced back to the account or the approval that put it there. A default is a decision nobody remembers making, until someone asks who made it. The plan that follows is sequenced by risk and effort, so your administrators know exactly what to fix first, what can reasonably wait, and what is already safe to leave as it is. How it runs Provision read-only access Review configuration against the baseline Rank findings by risk and effort Your team remediates with our review Re-check and close Access comes first, and it stays read-only throughout: nothing changes because we are looking at it. We compare your configuration against a recognised baseline covering multi-factor coverage, administrative privilege, external sharing, mail rules, logging and retention, and every connected application still holding standing access, then rank what we find by risk and effort so the list reads as a plan rather than a wall of findings. Your administrators make every change themselves, working from that ranked list with our guidance available for anything unclear. We review each change as it lands, and once the agreed items are closed, we re-check the whole picture and confirm it against the baseline again before calling the engagement done. What you receive You receive the findings themselves, written against the baseline we tested against: what is misconfigured, why it matters, and what a similarly configured account has allowed to happen elsewhere. Alongside them, the remediation plan your own administrators can execute in a week, sequenced so the riskiest gaps close first. And you receive the re-check: confirmation, after your team has acted, that the changes landed and the picture now matches the baseline. Carry that picture into the governance controls build next, and these findings become the starting inventory for a register that stays current, rather than a report nobody opens again. Questions: - Why identity first? Most intrusions today begin with a valid login, and you hand your AI assistant whatever that account can already reach. Identity is the control that limits every risk that follows, which is why we start there. - Do you change our settings? No, your administrators make every change themselves, with our guidance, and we verify the result afterwards. You keep sole control of your own environment throughout. - Which platforms? The review covers the major collaboration suites and identity providers, plus the business applications you name. We add any platform that holds real access to your data, so nothing material to your posture sits outside the review. - How long does remediation take? Most findings close in days once your administrators act on them. The plan sequences what remains by risk and effort, so the highest-risk gaps close first and the rest follow in order. --- # Health, Wellness and Longevity URL: https://airful.io/industries/health-wellness-and-longevity Care-grade platforms and growth for practitioners who are also the operators. Clinics, practitioners, wellness brands and longevity businesses handle personal data in every workflow and are usually run by the person delivering the care. We build the platforms, funnels and content systems that let the practice grow without the practitioner doing everything, and we govern the AI inside the work. Where the pressure sits A clinic or a wellness practice holds personal data in nearly every workflow it runs: intake, notes, payment details, sometimes health history itself. That data has to be handled, stored and evidenced properly, and if you are like most practices, you built for the clinical work first and left record-keeping to follow as an afterthought. The practitioner is usually the operator too. The same person delivering care also answers admin emails, chases the marketing calendar and follows up on old questions. Clinical time wins that competition, and the rest quietly falls behind. The practice should not depend on one person being everywhere at once. Content adds its own pressure, because it has to be accurate as well as warm. Claims here are regulated, and trust is the product, so a tone that overstates a treatment costs more than it gains. Meanwhile you already have staff drafting, summarising and searching with AI tools nobody approved, and no policy says what they may see or do. What changes We build a platform that takes over the admin the practitioner has been carrying: intake, scheduling, follow-up and the record of who saw what, so the practice keeps running while the practitioner is in a session. Funnels then qualify interest before it reaches a calendar, so time goes to people who are actually ready rather than to triage by hand. Content gets built to be accurate first and warm second, reviewed by you before anything publishes, so trust rests on the claim being true rather than on the writing being persuasive. And you make a point of knowing the AI already inside the work: which tools are in use, what they can reach, and a policy that says so in writing. How we work with practices Start with the workflow that eats clinical time Build the platform with data handling designed in Run content and conversion on the data it produces Know and govern the AI already in use The practitioner joins the first working session together with whoever runs the front desk and the diary, since between them they know exactly where a day breaks down. Between phases we check back in with you before moving on, so we build the platform around what the practice has actually confirmed, not around a guess made in the opening week. Bring your current intake forms and a plain list of the tools staff already reach for, and the first session moves faster because of it. The earliest visible change, usually in how follow-up gets handled, tends to land well before the practice reaches its next full season of new patients. What practices tend to notice first Did anyone get back to the person who asked about Wednesday? That question used to end most days at the practice, asked by whoever was closing up and answered by nobody in particular. It stops getting asked once we have follow-up running on a fixed schedule, sent whether or not the practitioner is free to think about it. A quieter shift follows a few weeks later, on the day a partner or an insurer sends a questionnaire that once meant an afternoon spent searching old files. The answer now comes straight from the evidence pack the assessment has been building since the day it started, and it goes back the same day, with the practitioner barely involved. Questions: - Do you understand health data obligations? We design for health data obligations from the start and map each one to a specific control in the platform. Where a regulation applies to your practice, we recommend your counsel confirm the interpretation before you rely on it. - Can you build patient or member portals? Yes. We build patient and member portals with role-scoped access and a full audit trail, so who saw what is always answerable. - Will content make medical claims? No. We draft content to be accurate, and you review and approve it before anything publishes. - Can staff keep using AI tools? Yes, once you know which tools are in use and what data they can touch. The discovery assessment gives you that picture, so staff keep working inside a clear boundary. --- # Hospitality and Retreats URL: https://airful.io/industries/hospitality-and-retreats Every property, every enquiry and every guest in one system your team already lives in. Hotels, resorts, retreat centres and boutique operators run on bookings that arrive from everywhere and guests who research on AI before they call. We build the platforms that hold it together and run the growth work that keeps the calendar full, property by property. Where the pressure sits A hospitality business is a fixed asset chasing a moving calendar. When demand is high the constraint is capacity and the risk is a missed enquiry. When demand is low the constraint is attention and the risk is a quiet marketing budget. The systems most operators inherit were built for one property, one channel and one season, and they are asked to do all three at once. The enquiry problem is the sharpest. A guest who researched for twenty minutes, asked an assistant for a shortlist, and then sent a WhatsApp message at eleven at night expects an answer that knows what they asked. The message lands on a phone, is answered from memory, and disappears when the person who answered it changes shift. Nothing connects the marketing that produced the enquiry to the booking that followed, so the next budget decision is made on instinct. The property is beautiful. The system around it is where the bookings are lost. What changes We build the operating platform first: one place where every property, every enquiry from every channel, every guest conversation and every booking lives, with the people who need it able to see it. Websites for each property feed that platform rather than an inbox. WhatsApp becomes a shared, logged channel. The team stops asking who spoke to the guest and starts asking what to do next. Then we run growth on top of it. Analytics flow in daily from the sites, the ads and the channels. Campaigns are built and measured as a system with a person deciding what to spend and where. Content and social programmes hold a voice across properties. And because guests increasingly decide inside an AI assistant, we make sure the properties are described accurately and cited when someone asks. How we work with operators Start with the property and the channel where enquiries are being lost, and put a working platform behind it within weeks Connect the booking engine, the website forms and WhatsApp so every enquiry is captured, routed and attributed Extend the same platform to the next property without rebuilding, keeping one team in one system Run growth continuously on the data the platform now produces, with a monthly cadence and a written record of what changed and why The general manager sits in the first working session alongside whoever currently answers guest messages, since together they know which channel is actually losing enquiries. Between phases we check back with that same pair before extending anything further, so a second property never inherits a decision the first property never confirmed. Have a list of every channel guests currently use to reach you, plus login access to the booking engine, ready before we start. We typically have a working platform behind the first property well before the next change of season. What operators tend to notice first The first change is usually quiet. Enquiries stop going missing. The second is visible in a month: the team can say which property, which channel and which campaign produced each booking, and the marketing conversation changes from opinion to evidence. The third compounds. Every season the system knows more about your guests than it did the season before, and the work gets sharper instead of louder. None of this depends on remembering who spoke to which guest. The same enquiry that arrived on WhatsApp last night is the one the team points to when a channel gets credit for a booking, and the same record is what next month's campaign decisions draw on. Operators come to trust the pattern because they can see it building, week after week, property by property. Questions: - Do you work with a single property or only groups? Both. Most engagements begin with one property and a single enquiry channel that is not working. The same platform then extends to the next property without starting again, which is why groups tend to arrive after a first site has proved the pattern. - Can you connect the booking engine and channel manager we already use? Yes. We connect to the engine you already run and leave it in place. What we add is the layer around it: enquiry capture from every channel, a shared inbox, follow-up that does not depend on who is on shift, and reporting that shows which property and which channel produced the booking. - Our guests mostly message us on WhatsApp. Can that be part of the system? It is usually the centre of it. We build WhatsApp into the operating platform as a shared, logged channel with templates, routing and a daily digest. An enquiry at midnight is answered, recorded and attributed inside that channel, so nothing depends on one person's personal phone or memory. - Do you run our advertising and social media too? We can. Performance marketing and content programmes are built as systems on top of the platform, so the campaign, the enquiry and the booking are one connected record. Ad spend stays with you and is never part of our fee. --- # Investor Relations and Capital URL: https://airful.io/industries/investor-relations-and-capital A network you can score, a pipeline you can defend, a raise that runs on evidence. Funds, founders raising capital, family offices and the advisors around them run on relationships that live in inboxes and judgement that lives in one person's head. We build the intelligence systems that rank and refresh them, and the platforms and marketing that carry a raise from first contact to close. Where the pressure sits A raise runs on relationships, and most of them live in the wrong place: an inbox, a spreadsheet passed between two people, a memory of who was warm eighteen months ago. Thousands of contacts exist somewhere, but none of them sit in one place, and by the time anyone needs a name the file has gone stale. Deciding who to call next comes down to recall. The person who remembers last year's best conversation calls that name again, while a stronger prospect sits untouched a few rows down because nobody has scored it against what this raise actually needs. A network is not an asset until it is scored, refreshed and shared. Outreach compounds the problem: messages go out, replies land in someone's personal inbox, and nothing comes back into a shared record. The next list gets built from scratch, by hand. Disclosure, consent and record-keeping duties sit around every raise, and a spreadsheet cannot produce the evidence a fund or a regulator eventually asks for. What changes We consolidate the network into one place: every contact, every past touch and every note, pulled together and deduplicated so the list reflects what is actually true. Then we score it against the thesis, with a reason attached to every score, so a ranked list is something a team can trust and argue with. The score refreshes on a schedule, so the list a team works from reflects the current state of the network rather than last quarter's export. It syncs into the CRM the team already runs, so the scored network and the pipeline live in one record. On top of the platform we run outreach content aimed at the readers most likely to respond, because the same intelligence that ranks a prospect can describe what they need to hear. How we work with raising teams Audit the network and score it against the thesis Build the platform that refreshes and explains Sync it into the CRM the team works in Run outreach content and reporting on top Whoever owns the raise sits in the first working session together with the person who actually manages the CRM day to day, since both need to agree on how we sync the two systems together. Between phases we bring the same pair back in before extending the platform further, so nothing gets built against a thesis nobody in the room has actually confirmed. Have your existing contact exports and a plain description of your current CRM setup ready before the first session. A first ranked list is usually ready well before the raising team's next full round of investor calls. What raising teams tend to notice first The first thing that changes is what the list looks like. The very first ranked output usually surfaces prospects who were already in the network, just buried under names that got called out of habit, and that alone reframes a few conversations before anything new gets added. The bigger change shows up in the weekly refresh. Scores move as new information arrives, so who gets called this week is rarely who would have been called last week, and the team stops working from a list that was accurate the day it was exported and wrong ever since. Questions: - Do you work with funds or founders? Both, and with the advisors who serve them. We run the same system for each: relationships scored against a thesis, refreshed on a cadence, and synced into the CRM the team already runs. What changes is the thesis itself and the criteria that define a fit. - Is our investor data safe with you? Investor data is processed under a signed agreement inside isolated environments built for that engagement, and it is handed back or deleted once the work ends. We keep it out of any shared system with other clients' data. - Can this replace our CRM? It sits beside your CRM and syncs into it, so the scored network and the pipeline live in the same record. When the CRM itself is the problem, we say so plainly and scope a replacement. - How fast is a first ranked list? Inside a week of receiving your exports, provided the data arrives in a workable format. We keep improving that list with every refresh after. --- # Professional Services and Advisory URL: https://airful.io/industries/professional-services-and-advisory Expertise that scales past the founder, with client data that stays where it should. Advisory firms, consultancies, accountants and agencies sell judgement. We build the platforms that let that judgement reach more clients, run the marketing that fills the pipeline, and govern the AI that is already inside the work. Where the pressure sits A professional services firm sells the judgement of a small number of people, and every hour of it is already spoken for. Revenue is capped by the hours of the people who know the most, because the person who understands the client best is also the one writing the memo, taking the call and chasing the fee. Client material follows wherever it was last sent. Contracts, filings and correspondence sit in whichever inbox or drive was open when the file arrived, and the tools people reach for to move faster now read that material by default. Nobody wrote a policy for it, because nobody expected there would be one to write. At the same time, you draft with an assistant, summarise with it, and send the result to a client with no second read and no record of what it touched. Clients, insurers and regulators increasingly ask for evidence of exactly that, and most firms cannot yet produce it. The judgement is the product. Everything around it should be infrastructure, not memory. What changes We build one operating platform that holds clients, matters and work in a single place, so the answer to where a file lives and who has touched it stops living in someone's head. Client material moves to storage built to hold it, with access logged so a firm can show exactly who could reach a document and when. We run marketing as a system in the founder's own voice, with content, outreach and follow-up that keep the pipeline moving without spending the hours that produce billable revenue. The firm stops treating marketing as whatever gets squeezed in between client work. We govern the AI already drafting inside client work, so the firm can defend it: a named review standard, a record of what a tool touched, and a policy that a client or an insurer can actually read. Governance closes the gap between what people already do and what the firm can prove it does. How we work with firms Start with the platform or the governance assessment, whichever hurts more Put client data where it should be and record who can reach it Run marketing as a system in the founder's voice Keep a named person on security and AI direction The founder sits in the first working session, together with whoever currently manages files or fields client questions day to day, since both shape which path we start on. Between phases we return to you with what we have found before moving to the next one, so nothing gets rebuilt around an assumption nobody confirmed. Have a rough map of where client files currently live and who can already reach them ready before the first call. A firm typically sees its first concrete change, usually in how a file request gets answered, well before the founder's calendar clears for a full quarter. What firms tend to notice first The questionnaire that used to take a week to answer starts taking an afternoon, because the evidence already exists rather than needing to be assembled from memory and old emails. That alone changes how a firm responds to a client or an insurer who asks hard questions. The bigger shift comes after. The pipeline stops depending on the founder's calendar, because content and outreach keep moving on their own schedule and the platform keeps matters visible to whoever is covering that week. Growth becomes something the firm can point to, built on a record instead of a memory. Questions: - We are a small firm. Is this built for us? Yes. Most of the firms we work with are founder-led and under fifty people. The engagements are sized so a small firm can take one at a time and see a result inside a month. - Do you understand our confidentiality obligations? We work under a signed confidentiality agreement, on read-only access wherever possible, and every change to your systems is made by your own people with our guidance. - Can you work with the tools we already use? Yes. We connect to the practice management, email and document tools you already run. We recommend replacing one only when it cannot do the job, and we say so plainly. --- # Real Estate and Proptech URL: https://airful.io/industries/real-estate-and-proptech Listings, owners, partners and leads in one intelligent system built for how property actually moves. Developers, brokers, property operators and proptech founders run on listings spread across portals, owners spread across records, and channel partners who each need their own view. We build the platforms and intelligence pipelines that hold it together and score what matters, and the marketing that fills them. Where the pressure sits Property data multiplies faster than anyone can reconcile it. Listings sit in portals, owners sit in spreadsheets and outdated internal tools, and the version an agent has on their phone rarely matches the one in the office. Nobody is wrong exactly, but nobody agrees either, and every conversation starts with checking whose number is current. A portal is not a report. It is a shared record everyone can trust. Every partner wants their own view of it. A channel partner wants a portal, a builder wants a dashboard, an advisor wants a report, and each one currently gets an email, assembled by hand from whatever was current that morning. The team spends more time formatting updates than generating them. Meanwhile every enquiry costs a full conversation before anyone knows whether it was worth having, because nothing about the lead is scored before a person picks up the phone. And underneath all of it sits identity, financial and ownership data that has to be handled and evidenced properly. What changes We model the data once: one place where listings, owners, partners and leads live as connected records rather than separate exports that go stale on their own schedule. On top of that single model we build a portal with a view scoped to each role, so a partner opens a dashboard built for them. We score leads and owners as they enter the platform, using models tuned to what predicts a good outcome in your market, so a call starts with context rather than a guess. Where buyers and owners already message on WhatsApp, we build it into the platform as a shared, logged channel that the business keeps when someone leaves. Marketing then runs against the same data, measured all the way to the enquiry, so spend follows what actually converts. How we work with property businesses Model the data once: listings, owners, partners, leads Build the portal with a view per role Add scoring and enrichment where judgement is expensive Run marketing and optimisation on the data it produces Whoever owns the listings feed sits alongside a partner-facing lead, since we build the data model to satisfy both before anything else goes on top of it. After each phase we bring both of you back in before moving further, so you can confirm the portal and the scoring rules match what the business actually uses. Have a current export of your listings, owner records and partner list ready going in, since that alone shortens the modelling phase. You typically see a first working view well before the next reporting cycle closes. What property businesses tend to notice first A recurring block on a partner's calendar, set aside every week for chasing a spreadsheet update, disappears once the dashboard starts refreshing on its own. You spend that time on the relationship, because we have taken the paperwork behind it off your desk. On the phone, the shift is just as immediate: an enquiry now arrives with a score already attached, so the opening question moves from whether the lead is worth pursuing to what to do about it next. The person answering can act inside the same call, without needing to put the caller on hold to check. Questions: - Do you build for brokers or developers? Both, and for the software founders building the tools that serve them. In every case we build the same pattern: one data model underneath, with a portal view scoped to each role on top. - Can you score properties or owners? Yes. We tune the scoring model to the criteria that matter for your market, whether that is owner intent, property fit or lead quality, and we keep the per-record cost small enough to run at volume. - What about regional payment and identity rails? We build on the payment and identity rails already standard in your market. That keeps checkout, verification and compliance native to the region you operate in. - Can this handle several roles and partners? Yes. Role-scoped access on one platform is the usual shape: brokers, owners, partners and internal staff each see only what belongs to their role, on the same underlying data.