# Alfaveo: full site text Generated at build time from 11 pages. --- # Alfaveo: operational systems for businesses that outgrew their processes > We map what your current way of working costs you, then build the system that removes it, starting with one workflow and a working build on your own data. Source: https://alfaveo.com/ ## We lead your digital and AI transformation First we put a number on where your time and money leak. Then we build you a custom system, with AI where it pays. Find your biggest constraint Book a 30-minute call with our CEO 30 minutes, no proposal, no pitch. How it runs with us ## We start with one process and finish with a solution that pays for itself 1 #### We pick the one process worth doing first Purchasing, production, approvals, invoicing, service. Candidates get scored on benefit, feasibility, data access, risk and time to value. You keep the plan and the design of that workflow. 2 #### We work out what it costs today and what it should earn Together we price the current state: hours, errors, rework and delays in that one process. Then we agree what will change, how we will know, what we measure it with, and what it is worth per year. You keep those numbers and the way of measuring them. 3 #### We build a working version on your own data Not a clickable mock-up but a running workflow, with AI on the parts it is good at. This is usually where people work out what they actually want: a presentation does not show you that, clicking through something that runs does. You keep the working version and a readout of the findings for your leadership team. 4 #### We put the finished solution into production The workflow taken to production quality, connected to the systems you already have, and your people trained on it. Then we keep tuning it on the feedback from real use until the result you agreed on is actually there, and we run and support it from then on. ### We carry the risk of the engagement, not you If the workflow we pick together does not deliver at least a 2× return in practice, we refund what you paid us for it, you keep every deliverable, and you walk away. ## A straight answer on fit ### This is for you if: you're owner-managed or mid-sized, roughly 20–500 people, growing; you already have an ERP or core system; and the processes around it have outgrown spreadsheets and email. ### This isn't for you if: you want a website, a consumer app, or a document about AI strategy. We build the operational layer a business runs on, and we only take work where the return is provable. Not sure what the problem is? ## Then start with a digital audit Some companies know exactly which process hurts. Others only know that the month is somehow slower than it should be. The digital audit is for the second case: a week with your people, mapping your processes, systems and data, ending in a report that says where the time and money actually go and what to fix first. How the digital audit works ## Systems we've built are running at Mid-sized and multi-billion-turnover businesses across Europe. ## The results speak for themselves Owners, directors and finance leads of the companies we build for. Previous ### Makro We replaced our outdated system for calculating transport and storage costs with a modern one that simplified our operations. Pavel Břicháč , Director ### ABB The approval workflow matches our complex process for quotes and contracts, driven by limits and roles. It brought clarity. Ivana Lastomirská , Director, ABB SK ### HM Gastro Group Our finance application handles invoices, integrations, approvals, timesheets and holidays, and it keeps evolving as our needs change. Jan Šimčík , CFO ### vielWerk Two years ago you'd have seen piles of paper in my office. Now we have one application where we handle every project. Jan Mathis Laackmann , Owner ### Národní divadlo What someone keeps telling you cannot be done, you find out it can, and that you have it the next day. That is what is great about Alfaveo. Dagmar Růžičková , Head of Economics and Administration ### Elánek Looking back, it's a real question whether we could have grown this fast on our old system. Sylva Pavelová , Director ### Brasche Immobilien Managing digital communication through the Alfaveo application is one of the main reasons clients choose to work with us. Robert Langen , Owner B ### Bamboolík Things we thought couldn't be solved, they simply solved. The application is exactly what we need. Zuzana Lálová , Director ### Makro We replaced our outdated system for calculating transport and storage costs with a modern one that simplified our operations. Pavel Břicháč , Director ### ABB The approval workflow matches our complex process for quotes and contracts, driven by limits and roles. It brought clarity. Ivana Lastomirská , Director, ABB SK ### HM Gastro Group Our finance application handles invoices, integrations, approvals, timesheets and holidays, and it keeps evolving as our needs change. Jan Šimčík , CFO ### vielWerk Two years ago you'd have seen piles of paper in my office. Now we have one application where we handle every project. Jan Mathis Laackmann , Owner ### Národní divadlo What someone keeps telling you cannot be done, you find out it can, and that you have it the next day. That is what is great about Alfaveo. Dagmar Růžičková , Head of Economics and Administration ### Elánek Looking back, it's a real question whether we could have grown this fast on our old system. Sylva Pavelová , Director Next - 1 - 2 - 3 - 4 - 5 - 6 - 7 - 8 Research ## What more than 100 managers told us about digitalisation We interviewed over a hundred managers and business owners across industries: what actually blocks digitalisation inside a company, and what the ones who got it right did differently. The findings are written up as a report you can read in twenty minutes. - Where the hours go, including the work that never shows up in any system. - Why projects stall after the pilot, and what the ones that landed had in common. - What to sort out before you buy software. Get the report Get in touch ## Tell us what isn't working Describe the process that costs you the most, and our CEO will come back to you personally. If you'd rather talk it through, book a 30-minute call instead. ### Send us a message Website Name * Work email * Phone * Company * What's the process that costs you the most? * Send message ### What happens next - 1 Our CEO reads your message himself, with no account manager in between. - 2 You get a reply with an honest first read on what's worth fixing first. - 3 If it's worth a conversation, we book 30 minutes. No proposal, no pitch. Book a 30-minute call ### Company details info@alfaveo.com Rašínova 2, 602 00 Brno ## Questions we get asked ### How quickly do we see something working? A working build lands inside that first step, on your data. Weeks, not quarters. ### What does working with you look like week to week? You see progress every week, not at the end. Short iterations against your real data and your real workflow, reviewed with you as they land. Our CEO runs the first step personally, so you are not handed to an account manager. We build on our own low-code/AI platform (Jetveo), which is why weeks replace quarters, and why you keep full control of the system we build. ### We already use ChatGPT and Copilot. Isn't that the same thing? No. Those make individual people a bit faster, and the gain disappears with them, because nothing in the business captures it. Company-level AI sits inside a process: the work arrives, gets handled the same way every time, and leaves a record. That's what shows up in capacity and margin. ### Will AI be making decisions in our business? No. We put AI on volume, rules, surfacing information and consistency. Judgement stays with your people. Automating judgement is the most common reason AI projects fail, and we won't sell you that. ### Do you replace our ERP? No. We connect to it. The new process feeds the ERP through its APIs; ripping out a working core system is the expensive way to solve a process problem. ### What does it cost? The first step has a fixed price, agreed in writing before it starts. Implementation is quoted only after the plan it produces is approved. We don't publish either number, because scope drives them and we'd rather give you a real one on the call. ### How is that 2× return measured? The calculation is part of the work itself, not an afterthought. Together we price what the process costs you today, then agree what will change, how we will know, what we measure it with and what it should be worth per year. When we look at the result later, we compare it against those numbers, agreed in writing up front, rather than against impressions. ### What do you usually build? The operational layer around a core system: approval workflows, document and invoice processing, warehouse and stock operations, project and service delivery, and the reporting that comes out of them. Sometimes that means extending an ERP, WMS or CRM you already run; sometimes it means building the process that never had a system. ### Who does the work? Our own team, on our own platform. No offshore hand-off. ### What happens after go-live? Run and support on a monthly basis, and, only if you want it, a dedicated development capacity for continuous change. ### We've been burned by a software project before. Then start with the map. That first step exists to prove the return is real before anyone commits to building. ## Start with the constraint, not the software. Take the one-minute analysis, or talk it through with our CEO for 30 minutes. Either way you'll leave with an honest view of what's worth fixing first. Find your biggest constraint Book a 30-minute call 30 minutes, no proposal, no pitch. --- # Find your biggest constraint | Alfaveo > Seven questions, about a minute. Get the practical guides that match your situation, and a short audit that estimates what the problem is costing you. Source: https://alfaveo.com/analysis Seven questions, about a minute ## Find your single biggest constraint Seven questions, about a minute, no login. You’ll get the practical guides that match your situation, the same thinking we use with clients. Then, if you want, a short audit that puts a number on what the problem is costing you. Start the survey No login. Takes about a minute. Trusted by teams at --- # AI process automation | Alfaveo > Individual AI tools make people faster. They don't make the business more efficient. See where AI could lift your margin, and roughly what it's worth. Source: https://alfaveo.com/ai AI process automation ## Using ChatGPT isn’t the same as your business using AI. Individual tools make people a bit faster. They don’t make the business more efficient, because nothing captures the gain. Answer a few questions and we’ll show you where AI process automation could lift your margin, and roughly what it’s worth. Start the free analysis Takes about a minute. No login. Trusted by teams at ## Where AI actually pays ### Volume. Work that arrives in hundreds: documents, invoices, orders, tickets. ### Rules. Decisions with a right answer someone can write down. ### Surfacing information. Flagging an invoice that doesn't match its PO before it reaches the approver. Churn-risk patterns before the account manager notices. ### Consistency. The same quality of output whether it's Monday morning or Friday at five. ## Where it doesn't Judgement calls, genuine exceptions, and anything you can't measure. Automating judgement is how AI projects fail. We won't sell you that. ## What company-level AI looks like Not a licence for everyone and a hope that productivity follows. A specific process where the work arrives, gets handled, and leaves a record, with the saving showing up in capacity or margin, not in a survey. --- # Digital audit | Alfaveo > A week with your team mapping how work actually moves, which systems and spreadsheets it passes through, and where the time and money go. The written report is yours whoever you continue with. Source: https://alfaveo.com/digital-audit ## A digital audit, for when you know it's slow but not why Some companies can name the process that hurts. Others only see the symptom: the month closes late, nobody trusts the numbers, and every answer needs three people. The digital audit finds the cause. We spend a week with your team mapping how work actually moves, which systems and spreadsheets it passes through, and where the time and the money go. Book a 30-minute call Find your biggest constraint 30 minutes, no proposal, no pitch. ## When this is the right first step You are considering a new system but cannot yet say what it has to fix. You have an ERP and a layer of spreadsheets around it that nobody has mapped. Reporting arrives late and by hand. Or a bigger project is coming and you want the ground truth before you commit budget to it. The audit is a standalone piece of work: it stands on its own whether or not you build anything with us afterwards. ## How the week runs 1 ### Preparation Before we arrive We ask for the basics and agree who we need to talk to, so the week on site is spent on substance rather than orientation. - The org chart, and who people actually go to when a system does not work. - The list of officially used systems, and access to them where your policy allows it, read-only is fine. - The people to interview across sales, finance, warehouse, operations and IT. - A set of questions for management, sent ahead. 2 ### Systems and data Days 1 to 2 We start with what is genuinely in use, as opposed to what is officially deployed, and we walk the operation to see it rather than hear about it. - Software inventory: the official systems next to the shadow IT that grew around them. - A walk through the operation: the floor, the stores, the desks where the work lands. - Hardware in the process: terminals, scanners, counters, anything that produces or consumes data. - Backups and data safety, including the spreadsheets nothing is backing up. 3 ### Data flows and processes Days 3 to 5 Then we follow the work itself, department by department, looking for master data and for the places where it gets retyped. - Where each record is born, and whether the systems holding it agree with each other. - Bottlenecks: data retyped by hand between systems, printed and typed back in again. - Processes that exist only in one person's head or one person's file. - Traceability: what you can reconstruct after the fact, and what is simply gone. - Records of downtime, rework and exceptions, and whether anyone can act on them. 4 ### Synthesis and report Days 6 to 7 We turn the findings into a written report and then walk your team through it, so the conclusions are yours and not a slide deck you have to interpret. - Findings priced where the data allows it, rather than described. - Priorities argued from what we found, not from what we sell. - A read-through with your team, so the report survives contact with the people who run the process. ## What you get, in writing The report is yours. It stays useful whoever you continue with, including your own team. - A map of your information architecture: inputs, systems, outputs. - A catalogue of applications, shadow IT included, each with its risk level. - A catalogue of processes and data with the level of digitalisation marked: paper, spreadsheet, system, automated. - A gap analysis: what your systems can do next to what people actually use. - A risk analysis, including the bus factor on the people the process depends on. - A roadmap split into quick wins, stabilisation and transformation. ## Why start here ### A first step that stands on its own You get a clear picture of your processes before deciding to invest in any system, ours included. ### Vendor-independent output The conclusions hold whichever direction you take. The document is yours and works for an internal team or another supplier. ### Visibility where there is none Where reporting is weekly and quality data is monthly, the audit names the data you need for a live view and how to get there. ### The processes nobody owns The work that grew around the system, approvals, change requests, exceptions, gets named and measured instead of tolerated. ### Incremental, not a big bang Recommendations are split into quick wins and strategic steps, so you can move in batches at a pace your IT capacity can absorb. ### Less operational risk Critical spreadsheets with no backup and processes that depend on one person surface before they become an incident. ## Systems we've built are running at Mid-sized and multi-billion-turnover businesses across Europe. ## What it costs The audit has a fixed price, agreed in writing before it starts. You get that number on the call, because it depends on the size and spread of your operation. The price of any implementation afterwards is set only once the audit has found what it finds, so that every further investment has a reason attached. ## The next step A 30-minute call to see whether the audit is the right first step at all. If it is, we agree the scope in writing, send the questions for management ahead, and book the week on site with the people who know the processes in detail. Book a 30-minute call --- # Development & Testing | Alfaveo > Process for raising development requests, estimates, approval, testing and acceptance with Alfaveo. Source: https://alfaveo.com/development-and-testing ← Back to home 🇬🇧 EN ## Development request, estimation and approval process How collaboration works for raising requests, producing estimates, approval and acceptance. Company: Alfaveo Platform: Jetveo Document version: 1.2 (customer) Date: May 2026 Audience: customers of Alfaveo ## Contents - 1. Introduction - 2. Submitting requests and communication - 3. New applications - 4. Estimation - 5. Estimate approval - 6. Execution and development - 7. Testing and acceptance - 8. Request changes - 9. Classifying reported issues: bug vs. new request - 10. Warranty bugfixing, SLA bugfixing and new requests - 11. Invoicing - 12. Dispute and complaint resolution - 13. SLA (Service Level Agreement) - 14. Key definitions and principles - 15. Process overview ## 1. Introduction This document describes how Alfaveo and its customers work together when raising development requests, producing estimates, and going through approval and acceptance of delivered features. The aim is for both parties to be clear on what happens when, what gets approved, what gets invoiced, and how disputes are resolved. This document complements the General Terms and Conditions of Alfaveo.cz s.r.o. ("GTC"), available at www.alfaveo.cz. In case of conflict between this document and the GTC, the GTC prevails. ### 1.1 Customer cooperation The customer is required to provide Alfaveo with the maximum cooperation needed to deliver the request (in particular: responding to questions, supplying inputs, and granting access). If the customer fails to cooperate, all deadlines stated in this document are automatically extended by the time spent waiting on cooperation. ## 2. Submitting requests and communication ### 2.1 Channels for submitting a request Requests are submitted to the Alfaveo helpdesk in one of three ways: By phone the customer calls the support line. If support picks up, the request is discussed live. If no one answers, the customer leaves a voicemail; the helpdesk processes the recording and creates a ticket. If the phone number is paired with an email contact in the system, the customer receives a notification with a link to the ticket. By email to podpora@alfaveo.cz the helpdesk mailbox is read periodically and tickets are created automatically. Subsequent emails about a ticket carry the ticket code in the subject; the helpdesk uses it to route replies to the right ticket automatically. Via the helpdesk website the customer signs in (login + password) and creates a ticket. After login, the system already has the email and customer/application assignment from the account, so nothing has to be entered manually. The web helpdesk is always behind login; there is no public ticket-creation page. When signed in, the customer sees an overview of all their tickets and a chat component on each one for direct communication with support. Notification links in emails (see 2.3) lead to a specific ticket without login the link contains a one-time token. This mode lets the customer respond quickly (e.g. approve an estimate) without having to log in every time. ### 2.2 Ticket priority When creating a ticket, the customer sets a priority: - MID standard request. Handled in the regular order. - CRITICAL critical request. Procedurally identical to MID the customer must state why the request is critical. Differs only in SLA response times (see 13.3). After review, Alfaveo may reclassify the priority (CRITICAL → MID if the actual severity does not match the set priority, or MID → CRITICAL, e.g. when a regression or outage is identified). The customer is notified about the reclassification. If they disagree, this is handled via the standard escalation (see 12). ### 2.3 Notifications to the customer The customer automatically receives an email with a link to the ticket in the following situations: - ticket creation, - priority change, - work on the request started, - estimate sent for approval, - handover for testing / acceptance, - ticket closure. The link in the email allows access to the specific ticket without login. ### 2.4 Ticket closure Whenever a ticket is closed, the reason is recorded: - Accepted by customer the customer confirmed acceptance, - Auto-accepted the customer did not respond within 14 days, - Cancelled the request was cancelled by the customer or by Alfaveo, - Duplicate the request duplicates another ticket. A closed ticket cannot be reopened. If a new issue arises (including a bug under warranty), a new ticket is created. ### 2.5 Customer-side approver For each Application, the customer designates an approver a specific person responsible for approving estimates and accepting deliveries. If the approver is unavailable (illness, vacation, leaving the company), the customer must appoint a replacement and inform Alfaveo. Without a valid approver, an estimate cannot be sent for approval. ## 3. New applications Requests for an entirely new application are handled individually. Even in that case, the resulting scope is broken down into individual features, each going through the standard estimation and approval process described in this document. ## 4. Estimation ### 4.1 What an estimate contains Each estimate contains: - Request description a clear specification of what is to be delivered, optionally what is explicitly out of scope. - Test and acceptance criteria concrete, verifiable conditions that the output must meet to be accepted. - Time estimate broken down into items (see 4.2). ### 4.2 Structure of the time estimate The estimate consists of a development estimate plus derived items covering analysis, testing, communication, and a buffer for bugfixing: Item | % of dev | Description Analysis | 15% | Understanding the request, designing the solution, preparing the spec Development | 100% (base) | Implementing the solution on the Jetveo platform Testing | 20% | Internal testing before handover to the customer Communication | 10% | Time for consultations, questions and clarifications with the customer Bugfixing | 15% | Buffer for fixing bugs found during acceptance Total | 160% | Example: development estimated at 10 hours → total estimate = 16 hours (1.5 h analysis + 10 h dev + 2 h testing + 1 h communication + 1.5 h bugfixing). ### 4.3 Estimate delivery time Alfaveo delivers an estimate within 48 hours of receiving the request. If the request is so complex that this deadline is insufficient, Alfaveo informs the customer and provides an expected estimate delivery date. ### 4.4 Maximum estimate size Requests with an estimate exceeding 20 hours must be split into smaller, individually estimated and approved parts. This rule reduces the risk of inaccurate estimates and lets the customer manage priorities better. ### 4.5 Scope definition The scope of the request is critical. The description and acceptance criteria define exactly what is and is not part of the estimate. Anything not explicitly stated in the description and acceptance criteria is out of scope and requires a new estimate. This protects both sides the customer knows exactly what they will get, and Alfaveo has a clearly defined scope of work it commits to deliver within the estimate. ## 5. Estimate approval ### 5.1 Sending for approval Once the estimate is finished, it is sent to the approver (see 2.5). The approver sees: - the request description and what is not part of it, - acceptance criteria, - the time estimate and its breakdown. ### 5.2 Approval by the customer The customer reviews the whole project in the application not just the estimate, but also the scope and delivery conditions. Specifically, they approve: - Request description (scope) whether the spec matches what the customer needs and what is out-of-scope, - Test and acceptance criteria whether the conditions for successful handover are correct and complete, - Time estimate whether they agree to the price for the defined scope. Before approval, the customer can amend or refine the request and the test criteria. If the customer proposes changes, Alfaveo reviews them and adjusts the estimate if needed. Approval is repeated against the updated project. Estimate revision limit: a single estimate can go through at most 3 revision rounds (i.e. estimate → comments → estimate → comments → estimate → final decision). If no agreement is reached after the third round, the situation is escalated to the Alfaveo manager (see 12). This rule prevents an endless loop of small estimate tweaks with no real progress. Only by clicking "Approve" does the customer consent to delivery at the given scope, against the given acceptance criteria, and at the stated price. After approval, Alfaveo can begin work. Important: by approving, the customer confirms that the scope and acceptance criteria are complete and correct. After approval, any change is handled as a new request (see 8). ### 5.3 Estimate rejection If the customer rejects the estimate, no fee is charged for preparing the estimate or analysis. Time spent on a rejected estimate is borne by Alfaveo. ### 5.4 No response to the estimate If the customer does not respond to the estimate within 10 working days, the estimate is automatically closed (rejected). The customer is notified before closure. ## 6. Execution and development ### 6.1 How development runs After approval, Alfaveo delivers the request in line with the description and acceptance criteria. ### 6.2 Communication during development Alfaveo contacts the customer only when: - something in the request is unclear and clarification is needed, - the feature is ready for testing. Periodic status reports during development are not provided by default. The customer can track the request status in the helpdesk. ### 6.3 Scope protection during development Scope changes are not allowed during development. Any new or modified request including ones raised during communication or testing requires a new estimate (see 8). Examples of situations that are out of scope and require a new estimate: - "It would also be good to add this field…" - "Could it work a bit differently than we agreed…" - "It occurred to me it would be better if…" - Requests raised during testing that are not covered by the acceptance criteria. Alfaveo is responsible for identifying these situations and explaining to the customer that they constitute a new request. ## 7. Testing and acceptance ### 7.1 Handover for testing Once development and internal testing are complete, the feature is handed over to the customer for acceptance testing. The customer receives a notification with a link to the application. ### 7.2 Acceptance by the customer The customer tests the delivered feature against the acceptance criteria and has two options: - Accept confirm that the delivery meets the requirements, - Return for fixes describe the specific mismatch with the acceptance criteria. ### 7.3 Iterative testing Testing is iterative the request can be passed back and forth between customer and Alfaveo. The maximum number of iterations is 3 rounds. If no agreement is reached after the third round, the situation is escalated to the Alfaveo manager who decides on the next steps (see 12). ### 7.4 Automatic acceptance If the customer does not respond within 14 calendar days of handover for testing, the delivery is automatically considered tested and accepted. ### 7.5 What is not a reason for return Returning for fixes is only justified when the delivery does not meet the defined acceptance criteria. New requirements or scope changes cannot be handled as fixes they require a new estimate. ## 8. Request changes ### 8.1 Change before development starts If the customer wants to change the request before work begins, the original estimate is cancelled and a new estimate is created with the updated specification. ### 8.2 Change during development If a change happens mid-development, the procedure is: - The original estimate is closed and invoiced in full at the approved amount, regardless of how much work was actually done. For the customer, that is the commitment they already approved; for Alfaveo, it protects already-performed work from being retroactively devalued by a later change. - A new estimate is created covering the entire new scope (the remaining original work after the change + the new requirements). - The new estimate may be reduced by the part of the original work that can be reused typically analysis, parts of the implementation that are not changing, environment setup. In the new estimate, Alfaveo transparently lists what part of the original work is being credited and to what extent, so the customer can see they are not paying twice for the same thing. - The new estimate must be approved the customer approves it via the standard process. This approach ensures transparency and a fair distribution of risk: the customer pays for the original commitment (analysis and development did happen), but does not pay again for the reusable part. Alfaveo does not lose the time it actually invested. ## 9. Classifying reported issues: bug vs. new request This chapter is critical to the cooperation working well. It clearly defines what counts as a bug fix vs. a new request (feature), how the call is made, and who pays for what. ### 9.1 Core rule The single criterion for distinguishing a bug from a new request is the approved specification and acceptance criteria. What is written down decides not what someone had in mind. ### 9.2 Decision tree For every reported issue, Alfaveo answers these questions: - Is the behavior contrary to the acceptance criteria? → YES = Bug. The feature does not do what was approved. - Did it work correctly before and now it does not (regression)? → YES = Bug. Even if not directly related to the latest request a regression is always Alfaveo's fault. - Does it work per the criteria, but the customer wants different behavior? → NO = New request. The customer wants a change or extension a new estimate is created. - Customer says "that's not how I meant it" or "it's only logical"? → The text of the acceptance criteria decides. If the desired behavior is not defined there, it is a new request. ### 9.3 Practical examples Situation | Classification | Reason The "Save" button does not write to the database | Bug | Contrary to acceptance criteria After deploying a new feature, export stopped working | Bug (regression) | Previously working functionality is broken "I'd like the form to close automatically after saving" | New request | Behavior after save is not defined in the criteria "Export works, but I'd also like it to PDF" | New request | Extension beyond the original scope "The filter works but is slow" | Depends on context | If performance is defined in the criteria → bug. If not → new request "Surely every system has to do this" | New request | Implicit expectations are not part of the delivery ### 9.4 Gray zone ambiguous specification If the acceptance criteria are ambiguous and both sides have a defensible reading: - Alfaveo and the customer try to reach an agreement. - If they fail, the issue is escalated to the Alfaveo manager. - The manager decides. If they conclude the spec was insufficient, the fix is delivered under warranty. - Acceptance criteria are tightened for next time so the situation does not recur. Lesson: the more precise the acceptance criteria, the fewer gray zones. That is why investing time in a high-quality specification is critical (see 4). ## 10. Warranty bugfixing, SLA bugfixing and new requests Alfaveo provides three different modes for handling issues and requests. It is important to understand how they differ and when each applies. Is bugfixing conditional on having an SLA? Not in the short term. Warranty bugfixing for 1 month after acceptance is always included in the price of the delivered estimate, regardless of whether the customer has an SLA. After the warranty expires, long-term application servicing (bug fixes, regressions, maintenance) is either covered by an active SLA, or each fix is handled as a paid new request per the price list. Without an SLA the customer still gets fixes they just pay for them individually after a year or two of active use, rather than as a flat fee. ### 10.1 Mode overview | Warranty bugfixing | SLA bugfixing | New request When it applies | 1 month after acceptance of the specific request | Continuously for the duration of the SLA contract | Anytime What it covers | Bugs within the just-delivered request | Any bugs in the application (including older features, regressions) | New features, behavior changes, extensions Capacity | Unlimited (within request scope) | Within SLA, no hourly limit | Per the approved estimate Price | Included in the estimate | Included in the SLA flat fee | Per the new estimate Response time | Not guaranteed | Guaranteed per SLA tier | Not guaranteed (estimate within 48 h) Condition | Bug found within 1 month of acceptance | Active SLA contract | Approved estimate ### 10.2 Classification and approval Alfaveo classifies the issue based on the decision tree from 9.2 and acts immediately bugs are taken to fix, features are estimated. If the customer disagrees with the classification, it is escalated per 12 (Dispute resolution). Customer approval is always required even for bugs. Why: the customer must have visibility into what is happening in their application, what classification was chosen, what the fix description is, and (for SLA) how many hours are being consumed. However, approval does not block the start of work for bugs, fixing starts immediately to honor response times, and approval happens in parallel. #### What gets approved by mode: Situation | What the customer approves | Does approval block fix start? | Invoicing Bug under warranty (within 1 month of acceptance) | Classification as a bug + fix description | No (fix starts immediately) | Not invoiced Bug via SLA | Classification, fix description | No (fix starts immediately) | Not invoiced (in the SLA flat fee) Bug outside warranty, no SLA | Standard estimate as for a new request | Yes work does not start without approval | Invoiced per the estimate New request (feature) | Standard estimate | Yes work does not start without approval | Invoiced per the estimate Key distinction: for bugs under warranty and within SLA, approval is informational the customer confirms they understand the classification and description, but is not approving a price (there is none). For bugs outside warranty/SLA and for new requests, approval is binding on price without it work does not begin. If the customer does not approve the classification of a warranty/SLA bug within 5 working days, the fix is either already done (if it was quick) or in progress, and after this period the classification is considered confirmed. Any dispute is still resolved per 12. ### 10.3 Warranty bugfixing detail After acceptance, a 1-month warranty period runs. During it, bug fixes are included in the price of the estimate. The warranty period starts on the date the customer clicked "Accept" or the date of automatic acceptance (after 14 days without response). The warranty covers only bugs within the delivered request i.e. mismatches with the approved spec and acceptance criteria. It does not cover new requests, behavior changes, or extensions. After one month, any fix is handled either via SLA (if active) or as a new request. ### 10.4 SLA bugfixing detail SLA covers bugs across the whole application including older features no longer under warranty. Bugfixing is included in the SLA flat fee, independently of the SP1 tier, with no monthly hourly limit. Key difference vs. warranty: SLA provides guaranteed response times (see 13.3). Warranty bugfixing has no guaranteed response times. If a bug falls under both warranty and SLA at the same time (within warranty and the customer has an SLA), SLA response times apply. ### 10.5 New request detail Anything that is not a bug is a new request no exceptions. A new request always requires a new estimate and customer approval. Typical examples: new features, changes to existing behavior, scope extensions, work after the warranty period, "improvements" to existing features. ### 10.6 Communication with the customer When classifying a reported issue, Alfaveo always tells the customer: - whether it is a bug or a new request, and why, - if a bug which mode it falls under (warranty / SLA / paid fix), - if over-limit or a new request that an estimate will be created for approval. All classifications and fixes are sent to the customer for approval per 10.2. ## 11. Invoicing ### 11.1 Billing period Invoicing happens at the end of the calendar month. ### 11.2 What gets invoiced The invoice covers requests that, in the given month: - were completed and accepted by the customer, or - were automatically accepted (after 14 days without response), or - were completed and approved for invoicing in justified cases, after prior agreement with the customer, requests that are approved and completed but have not yet passed acceptance testing may also be invoiced. ### 11.3 Invoiced amount The approved estimate is always invoiced, not the actual time spent. If the actual work exceeds the estimate, the difference is borne by Alfaveo. That is why strict scope discipline is critical (see 6.3 and 7.5). ## 12. Dispute and complaint resolution ### 12.1 Dispute over classification (bug vs. new request) If the customer disagrees with the classification per 9.2: - Alfaveo provides written justification for why the request does not fall under the acceptance criteria. - If the customer maintains their position, the issue is escalated to the Alfaveo manager. - The manager decides based on comparing the request with the original description and acceptance criteria. - The manager's decision is final. If it turns out the acceptance criteria were ambiguous, the fix is performed under warranty and the criteria are tightened for next time. ### 12.2 Estimate complaint If the customer disputes the validity of the invoiced amount: - Alfaveo provides a detailed estimate breakdown and a description of the work performed. - If Alfaveo demonstrably failed to deliver what was stated in the estimate, a correction or credit note is issued. ### 12.3 Delays on Alfaveo's and the customer's side Delays can occur on either side. The procedure differs depending on who caused the delay. #### Delays on Alfaveo's side Typical cases: exceeding the estimated hours, missing the completion deadline, delivering the estimate after the 48-hour window, exceeding SLA response times. - Alfaveo informs the customer immediately upon discovery not only after the deadline has passed. - The communication includes the reason for the delay and a new expected deadline. - Exceeding the estimated hours is borne by Alfaveo the approved estimate is invoiced, not the actual time (see 11.3). - Breaches of SLA response times are handled per the SLA contract (typically a discount on the monthly fee). - Repeated or serious delays are escalated by the Alfaveo manager, who decides on compensation beyond the above. #### Delays on the customer's side Typical cases: the customer does not respond to estimates, to questions from Alfaveo, or to handover for testing; fails to provide cooperation, inputs or access. - All deadlines in this document are automatically extended by the time spent waiting for cooperation (see 1.1). - The system sends automatic reminders failure to respond to an estimate within 10 working days closes the estimate automatically (see 5.4); failure to respond to testing within 14 days triggers automatic acceptance (see 7.4). - SLA response times for a specific ticket are paused while Alfaveo is demonstrably waiting on customer cooperation. - If a delay on the customer's side causes Alfaveo measurable costs (e.g. a planned developer is blocked and cannot work on another project), this is grounds for negotiating compensation handled by the manager. - If the customer systematically fails to cooperate, Alfaveo has the right to suspend work on further requests until the situation is resolved. #### Documenting delays Every delay on either side is recorded in the project history. The history is the basis for any potential billing adjustment, complaint, or evaluation of the cooperation. ## 13. SLA (Service Level Agreement) ### 13.1 Service description SLA is an optional paid technical support service. It guarantees response times for issue resolution and ongoing application maintenance. Bugfixing is included in the SLA flat fee with no hourly limit. ### 13.2 Defect classification For SLA purposes, defects are split into three categories: - Critical defect the system is unusable in its core functions. Standard ways of working cannot continue and there is no available workaround. - Major defect the system is degraded such that this state limits normal operation. The situation can however be mitigated or worked around. - Minor defect the defect does not significantly affect normal operation. Some user functions are limited but available by other means. ### 13.3 Response times Guaranteed start-of-work times for issue resolution: Defect type | Response time Critical defect | within 4 hours Major defect | within 12 hours Minor defect | within 3 working days The response time starts running upon confirmation of the request. If the request is reported outside the agreed support hours, the clock starts at the beginning of the next agreed window. ### 13.4 SLA packages overview SLA is composed of three independent packages: SP1 (basic support and response times), SP2 (prepaid consulting hours) and SP3 (monitoring and prophylaxis). The customer can order any combination. ### 13.5 SP1 Reactive support tiers SP1 defines the support hours (during which response times per 13.3 run) and is available in four tiers: Tier | Support hours BASIC | 9:00–16:00, working days SILVER | 6:00–20:00, working days GOLD | anytime except public holidays PLATINUM | anytime (24/7) Bugfixing within SLA is included in the flat fee for all SP1 tiers, with no monthly hourly limit. The tiers differ in support hours, response times, and the corresponding flat-fee price. ### 13.6 SP2 Prepaid consulting hours Flat 10 consulting hours per quarter. The customer uses the hours for consulting, training, analyses and small queries outside of bugfixing. Unused hours do not roll over to the next quarter they expire. ### 13.7 SP3 Product monitoring and prophylaxis Includes: - ongoing monitoring of performance and error rate, - proactive maintenance (log inspection, data cleanup, oversight of scheduled jobs), - verifying compatibility with infrastructure updates (Jetveo platform upgrades, DB, runtime), - regular reporting of application status to the customer's manager. ### 13.8 Security bugs (vulnerabilities) Security bugs are handled with priority over other bugs of the same severity. #### Two layers of responsibility: - Platform level (Jetveo) vulnerabilities in the Jetveo platform (runtime, framework, standard components, authentication, authorization, CSRF/XSS/SQLi in the basic building blocks, TLS, dependency updates) are primarily handled by the platform vendor. Alfaveo applies platform upgrades to customer applications under SP3 (or as a security hotfix outside SLA if SP3 is not contracted). - Application level (Alfaveo) vulnerabilities in custom code written by Alfaveo (business logic, custom integrations, custom input handling outside standard Jetveo components) are handled by Alfaveo. #### Severity classification uses standard scoring (e.g. CVSS): Severity | Alfaveo response Critical / High | Equivalent to Critical defect per 13.2 response time per SP1 tier. Fix as a hotfix without waiting for the next release. Medium | Equivalent to Major defect scheduled fix in the next release window. Low | Equivalent to Minor defect placed into the regular bugfixing backlog. Without SLA: security bugs in Alfaveo's custom code are handled under warranty (if within the warranty period of the delivered request). Security bugs outside warranty without an SLA are handled as a paid fix, but with the highest priority. Platform security patch: if a Jetveo platform upgrade is required (a critical vulnerability disclosed by the platform vendor), Alfaveo is required to inform the customer and roll out the upgrade within a timeframe proportionate to severity. The deployment cost is borne by customers with active SP3; for customers without SP3 the upgrade is billed as bugfixing per price list. Vulnerability reporting: external vulnerability reports (bug bounty, pentest findings, third-party reports) are filed as a standard ticket with CRITICAL priority and "security" classification. ## 14. Key definitions and principles To prevent disputes, the following principles apply: - Bug (product defect) = product behavior that is contrary to the approved specification and acceptance criteria and is demonstrably caused by the delivered solution. A product defect does not include problems caused by misuse, unauthorized customer modification, or failures of software or infrastructure not delivered by Alfaveo. - Customer responsibility: the customer is responsible for the correctness and completeness of the brief. Alfaveo works from what is written in the approved estimate. - Implicit expectations: behavior that is not explicitly defined in the request description and acceptance criteria is not part of the delivery and cannot be grounds for a complaint. ## 15. Process overview Request (customer) │ ▼ Project creation (description, acceptance criteria, estimate) │ ▼ Sent for approval │ ├── Approved → Development starts │ │ │ ▼ │ Development per scope │ │ │ ▼ │ Handover for testing │ │ │ ┌──────────┴──────────┐ │ ▼ ▼ │ Accepted No response 14 days │ │ │ │ ▼ ▼ │ Invoicing Auto-acceptance │ │ │ ▼ │ Invoicing │ ├── Rejected / change → New estimate │ └── No response → Reminder → Closure --- # Your ERP is fine. Everything else runs in Excel. | Alfaveo > A practical guide to fixing the processes that live outside your core system Source: https://alfaveo.com/guides/erp-excel ## Your ERP is fine. Everything else runs in Excel. A practical guide to fixing the processes that live outside your core system You have an ERP. It handles invoicing, stock levels, and basic accounting well enough. But approvals happen over email, production scheduling lives in a spreadsheet someone built three years ago, and the Monday morning report means someone spending half a day pulling data from three different places. The ERP is not the problem. The processes around it are. ### Why this happens ERPs are built to record what has already happened. They are not built for the messy middle, the approvals, the exceptions, the processes that involve multiple people making decisions in a specific order. When businesses try to extend their ERP to handle this, one of two things happens. The vendor quotes a large number for a module that still will not fit the way the team actually works. Or someone builds a workaround, a spreadsheet, a shared inbox, a WhatsApp group, that technically handles the process but creates new problems: no visibility, no audit trail, no way to know where something is stuck. The workaround becomes permanent. The spreadsheet becomes load-bearing infrastructure. The person who built it becomes indispensable. ### The five processes most likely costing you the most #### 1. Approval workflows Purchase orders, quotes, contracts, expenses, anything that has to go to multiple people before it moves forward. In most businesses these work like this: someone emails a request, it sits in an inbox, the approver approves or asks a question, the reply gets lost, someone chases, the approval eventually happens two weeks after it should have. What a fixed version looks like: a request goes in, it routes automatically to the right approver based on value or type, the approver gets a notification, they approve or reject with a comment, the requestor is notified, and there is a permanent record of what was approved, by whom, and when. The whole thing takes minutes instead of weeks, and nobody has to chase anyone. #### 2. Data entry between systems If someone in your business copies information from one system into another, from a customer email into your ERP, from your ERP into a spreadsheet, from a spreadsheet into a report, that is a process waiting to be automated. Every manual transfer is a source of errors and a waste of skilled time. A number entered wrong at step one is wrong everywhere it ends up. #### 3. Status and visibility “Where is this order?” “Has that been approved?” “What is the current stock level of X?” If the answer to any of these requires someone to check a spreadsheet, call a colleague, or dig through an email thread, you do not have visibility, you have a team of people holding information that should be in one place. #### 4. Reporting If producing a weekly or monthly report requires someone to manually compile it, the report is already out of date by the time it is read. Reporting is not where to start, it is the output of clean processes. Fix the data flows first and reporting becomes automatic. Try to fix reporting first and you are building dashboards on top of unreliable data, which is worse than no dashboard at all. #### 5. Exceptions and escalations Every process has exceptions, the order that does not fit the standard flow, the approval that needs someone senior, the request that falls between two categories. The same exception handled by different people on different days gets different outcomes. Customers and suppliers notice. ### What to do in order - Map what actually exists, walk through your current processes as they really work, not as they are supposed to. - Pick the one causing the most visible pain, not the most strategic one. A fast, visible win creates momentum. - Build the fix properly, clear input, clear output, no manual steps to keep it running, an automatic record. - Connect to your ERP, the new process feeds into the ERP via its APIs, it does not replace it. - Repeat, the second process is faster than the first. Within three to four months the five to eight processes generating most of your drag can run properly. ### What not to do - Do not try to replace your ERP. It almost certainly does not need replacing. - Do not buy an ERP-vendor module without checking it matches how you actually work. - Do not start with reporting. It feels productive. It is actually the last step. - Do not try to build everything at once, you end up with several half-finished things and no wins to show. ### What this is worth For every person spending more than four hours a week on manual process work, re-entering data, chasing approvals, compiling reports, you are spending roughly £7,000 to £10,000 a year on work that should not require a person. Most mid-sized businesses have five to fifteen people in this position. The total is usually larger than expected. The signal that this is your biggest problem: someone in your business could not do their job for a week if a specific spreadsheet disappeared. If that is true, you are one person leaving away from a crisis, and that person knows it. ### About Alfaveo Alfaveo builds custom software that connects to your existing systems and handles the processes they were never designed for. We start with a working prototype in 10 business days, real UI, real data, real workflow, so you can see exactly what you are getting before committing to a full build. If what you have read here describes your situation, the most useful next step is a 30-minute conversation. No proposal, no pitch, just an honest assessment of what is worth fixing first and roughly what it would take. Book a 30-minute call --- # Your business depends on people, not systems | Alfaveo > A practical guide to getting critical knowledge out of people’s heads and into something that survives them Source: https://alfaveo.com/guides/knowledge ## Your business depends on people, not systems A practical guide to getting critical knowledge out of people’s heads and into something that survives them When someone needs to know how something works, they ask a specific person. New starters take months to become useful because the only way to learn is to shadow someone. When a key person is sick or on holiday, things slow down or stop. And somewhere in the back of your mind is the awareness that if two or three specific people left, you would have a serious problem. This is not a people problem. It is a systems problem that looks like a people problem. ### Why this happens Knowledge accumulates in people naturally. Someone figures out how to handle a difficult supplier, learns the quirks of a particular client, develops a method for resolving a recurring problem. They do not write it down because writing it down takes time and there is always something more urgent to do. This works fine when the business is small. As it grows, the informal network cannot scale, and the distance between how things are supposed to work and how they actually work grows until the written process, if there is one, is fiction. ### What is actually at risk #### Key person dependency Most businesses have two or three people whose absence would cause serious disruption within a week. These people cannot take proper holidays. They get pulled into situations that should not require them. They become bottlenecks because they are the only route to information or decisions. #### Inconsistency When the process lives in someone’s head, it gets applied differently by different people on different days. The same customer query handled by two team members gets two different responses. Clients and suppliers notice, even if they cannot articulate exactly what is inconsistent. #### Training time, cost, and decision quality When the only way to learn is to shadow someone, onboarding takes months, and a senior person’s time is consumed without much value produced. And when information is not in a system, decisions get made without full context. ### What to do in order - Identify where the critical knowledge lives, list the people whose absence would cause the most disruption and exactly what they know that nobody else does. - Document it as it actually works, not as it should. The most valuable things to capture are the exceptions: what happens when the standard process does not apply, who decides, and on what basis. - Design processes so knowledge is captured automatically, as a by-product of work (an approval log, a job record, a stored interaction history), not as a separate exercise that goes stale. - Reduce single points of failure deliberately, ensure each critical area is known by at least two people. - Build a simple internal knowledge base, searchable and connected to the actual processes. The test: a new starter can answer 80% of their questions without asking a person after their first month. ### The mistakes most businesses make - Documenting without connecting to process, a folder of PDFs is not a knowledge system. - Treating it as an IT project, it is a business design problem. - Waiting for a crisis to start, after the key person leaves, the knowledge leaves with them. - Building for the standard case only, the value is in documenting the exceptions. ### What this is worth The average cost of replacing a mid-level employee, recruitment, lost productivity, training the replacement, is roughly six to twelve months of that person’s salary. For a key person carrying significant institutional knowledge, the real cost, including lost client relationships and operational disruption, is often higher. The bigger cost is the constraint on growth: a business whose operating system is a handful of senior people cannot scale without those people working more. The signal that this is your biggest problem: you have had to delay a decision, lose a client, or work through a weekend in the last year because a specific person was unavailable. If that has happened more than twice, this is your biggest problem, and it gets worse as the business grows, not better. ### About Alfaveo Alfaveo builds custom software that connects to your existing systems and handles the processes they were never designed for. We start with a working prototype in 10 business days, real UI, real data, real workflow, so you can see exactly what you are getting before committing to a full build. If what you have read here describes your situation, the most useful next step is a 30-minute conversation. No proposal, no pitch, just an honest assessment of what is worth fixing first and roughly what it would take. Book a 30-minute call --- # You are growing but the margin is not following | Alfaveo > A practical guide to building operations that get more efficient as the business scales, not less Source: https://alfaveo.com/guides/margins ## You are growing but the margin is not following A practical guide to building operations that get more efficient as the business scales, not less Revenue is up. Headcount is up at roughly the same rate. Profit margin is flat or declining. The business feels busier than ever but the extra revenue does not seem to reach the bottom line in the way it should. This is one of the most common and most misdiagnosed problems in growing businesses. The usual response is to look at pricing, or cost of sales, or overheads. The actual problem is almost always operational: the processes that run the business were designed for a smaller version of it, and they do not get more efficient as volume increases. They get less efficient. ### Why this happens When a business is small, inefficient processes are cheap. A process that wastes four hours a week costs maybe £7,000 a year. The same process at three times the volume often costs more than three times as much, because at higher volume the inefficiencies compound: more exceptions, more coordination, more management time. Meanwhile the business is hiring to keep up, which adds fixed costs. The margin gets squeezed from both sides. ### How to find where the margin is going - Map your operational cost by activity, not by department, what does it actually cost to deliver one unit of your core service, including management time, rework, exceptions, and coordination? - Identify the processes that scale badly, if you doubled volume tomorrow, which processes would cost more than twice as much to run? Those are the ones undermining your margin. - Calculate the real cost of manual work, hours per week on genuinely manual tasks × fully loaded hourly cost × 52. For most mid-sized businesses this is £150,000 to £400,000 a year. ### What to do in order - Fix the processes that scale badly first, the cost of leaving them unfixed compounds with growth. - Standardise before you automate, automating an inconsistent process just creates faster inconsistency. - Get visibility into margin by client and product, it is common to find 20–30% of clients account for most operational drag while contributing below-average margin. - Build for scale deliberately, the test is “does this work at three times current volume without adding headcount proportionally?” ### The hiring trap The most common response to operational drag is to hire. This solves the immediate symptom but does not fix the process, and it adds a fixed cost that is harder to remove later. Worse, the new hire learns the broken process and becomes dependent on it. The businesses that maintain margin through growth fix the process rather than hiring around it. ### What this is worth A business with £5m revenue and 18% margin is generating £900,000 in profit. If operational inefficiency is costing 5 percentage points of margin, conservative for a business with significant manual overhead, fixing it is worth £250,000 a year, growing with revenue. Every pound of margin improvement is worth more than every pound of revenue growth, because margin flows straight to profit. The signal that this is your biggest problem: your headcount has grown faster than your revenue over the last two years. If revenue is up 40% and headcount is up 60%, the business is funding growth with margin. That path has a limit. ### About Alfaveo Alfaveo builds custom software that connects to your existing systems and handles the processes they were never designed for. We start with a working prototype in 10 business days, real UI, real data, real workflow, so you can see exactly what you are getting before committing to a full build. If what you have read here describes your situation, the most useful next step is a 30-minute conversation. No proposal, no pitch, just an honest assessment of what is worth fixing first and roughly what it would take. Book a 30-minute call --- # You have a system nobody wants to touch | Alfaveo > A practical guide to modernising without the risk of a full replacement Source: https://alfaveo.com/guides/legacy ## You have a system nobody wants to touch A practical guide to modernising without the risk of a full replacement There is a system. It works, mostly. Nobody knows exactly how it works anymore. The person who built it left years ago. Every time someone wants to change something, it takes months, costs more than expected, and introduces a new bug somewhere else. So nothing gets changed, and the workarounds multiply. This is a solvable problem. But the way most businesses try to solve it is also the way most of them make it worse. ### Why replacing it is usually the wrong first move The instinct is to replace the legacy system with something modern. In most cases this is the most expensive and most risky answer, and it often does not solve the actual problem. Legacy systems become problems not because the technology is old, but because the business has changed and the system has not. When you try to replace one, you discover nobody can fully specify what it does, undocumented behaviours, edge cases nobody wrote down, data in mystery formats. Over 60% of full replacement projects run significantly over time and budget, and a meaningful proportion are abandoned. The safer, faster, and usually cheaper path is to wrap it. ### What wrapping means in practice Wrapping means building modern tooling around the legacy system, handling the processes that have outgrown it, improving the interfaces people use every day, and connecting it to other systems without touching the core. Over time, as trust is established, parts of the legacy system can be migrated incrementally, in stages small enough to be tested and validated. - It delivers value faster, the first piece of new tooling can run in three to five weeks, with no big-bang cutover. - It is lower risk, each stage is small enough to test and reverse; the core is not touched until there is high confidence. - It reveals the real requirements, you learn what the business actually needs by watching how people use what you build. ### How to start - Map what the legacy system actually does, including the undocumented behaviours and the manual steps people use to work around it. - Separate what works from what does not, keep the reliable parts, target the actively painful ones first. - Start with the edge processes, the things handled in spreadsheets around the system. Lowest integration risk, immediate value. - Connect to the legacy system carefully, reverse-engineer the data model so data flows automatically without depending on undocumented behaviour. - Migrate incrementally, small, tested, parallel-run stages. There is no deadline; some components may never need to migrate. ### The data question Legacy systems usually contain years of historical data the business relies on. Make the legacy database readable from the new layer (without writing to it) so historical records stay accessible from day one. Do not try to migrate historical data at the start, get the new system running on new data first, then migrate history later, in stages. ### What this is worth The direct cost of a legacy system, expensive support contracts, slow change processes, compounding integration costs, runs to £50,000 to £200,000 a year for most businesses. The indirect cost is harder to see: the growth that cannot happen because the system cannot support it. The signal that this is your biggest problem: you have said the words “we cannot change that” about a system in the last six months. If a system cannot be changed to fit how the business needs to work, it is a ceiling on growth, and that ceiling gets lower every year. ### About Alfaveo Alfaveo builds custom software that connects to your existing systems and handles the processes they were never designed for. We start with a working prototype in 10 business days, real UI, real data, real workflow, so you can see exactly what you are getting before committing to a full build. If what you have read here describes your situation, the most useful next step is a 30-minute conversation. No proposal, no pitch, just an honest assessment of what is worth fixing first and roughly what it would take. Book a 30-minute call --- # Everything is manual and you do not know where to start | Alfaveo > A practical guide to building your first operational system without getting it wrong Source: https://alfaveo.com/guides/no-system ## Everything is manual and you do not know where to start A practical guide to building your first operational system without getting it wrong No central system. Most things happen over email, WhatsApp, and spreadsheets. There is no single place where the state of the business lives. Different people have different versions of the truth. Things fall through the cracks. The answer to “where is this?” is usually a phone call. The good news is that this stage is actually the most tractable. There is no legacy to work around, no entrenched system to unpick. The challenge is sequencing it correctly. ### The mistake most businesses at this stage make The temptation when you can see all the problems is to fix all of them at once, either by buying a comprehensive platform that promises to handle everything, or by starting a large development project. Both usually fail. The platform forces you to adapt your processes to fit the software. The large project takes too long, the requirements change mid-build, and what ships does not match what the business needs. The businesses that make the most progress start with something specific, build it properly, prove it works, and use that as the foundation for the next thing. ### How to pick what to fix first - Where do things fall through the cracks most often? The process that generates the most “I thought you were handling that” conversations. - Where does the same information get entered more than once? Every manual transfer is an error waiting to happen. - Where does someone always have to ask someone else? If a recurring question can only be answered by a specific person, that information is in the wrong place. ### What to build first The specification is simple: a clear input, a clear output, no manual steps in between, and a record that gets created automatically. Do not overbuild. The first version should do one thing reliably for the standard case, and it needs to be something real people will actually use. - Job or order management, a single place where every job exists, with a current status, an owner, and a history. - Approval workflows, replace email chains with a tracked, structured flow. - Client or contact records, one place where everything about a client lives. - Invoice and document processing, automate the receive–review–approve–pay flow. ### What good looks like - People actually use it, if the team reverts to the old method within a month, the system failed. Usually it needs to be simpler, not more sophisticated. - It creates a record automatically, who did what, when, and the outcome. - It handles the exception, not just the rule, routes edge cases to a person rather than failing silently. - It connects to what you already use, email, accounting software, so the transition is gradual. ### What this is worth A simple job management system for a 20-person business typically saves 15 to 25 hours a week across the team. At an average fully loaded cost of £35 an hour, that is £27,000 to £45,000 a year, and the cost to build it is usually a fraction of the first year’s saving. The more important number is the growth it enables: a business on email and spreadsheets has a growth ceiling set by its people’s capacity to handle everything manually. The signal that this is your biggest problem: you cannot tell someone the current status of an important piece of work without making a phone call or checking a spreadsheet. If that is true, you do not have a system, you have a collection of people holding information that should be somewhere everyone can see. ### About Alfaveo Alfaveo builds custom software that connects to your existing systems and handles the processes they were never designed for. We start with a working prototype in 10 business days, real UI, real data, real workflow, so you can see exactly what you are getting before committing to a full build. If what you have read here describes your situation, the most useful next step is a 30-minute conversation. No proposal, no pitch, just an honest assessment of what is worth fixing first and roughly what it would take. Book a 30-minute call --- # Your team uses AI to make their job easier. Not to make the business more efficient. | Alfaveo > A practical guide to capturing the value of AI at a company level, not just an individual level Source: https://alfaveo.com/guides/ai ## Your team uses AI to make their job easier. Not to make the business more efficient. A practical guide to capturing the value of AI at a company level, not just an individual level Your team uses AI. ChatGPT for writing emails faster. Copilot for summarising documents. Someone discovered a tool that automates a report they used to spend two hours on. Individually, these save time. Collectively, the business is no more efficient than before, because the gains are sitting with individuals, not in the systems the business runs on. This is the most common AI situation in mid-sized businesses right now. It is not a failure, it is the natural first stage. The question is how to get to a position where AI makes the business itself more efficient, not just individual employees faster at their existing work. ### Why individual AI use does not compound When an employee uses AI to do their job faster, they either produce the same output in less time (a productivity gain invisible in the numbers) or fill the saved time with more of the same work (more productive, but the process is unchanged). Neither is the main opportunity. The main opportunity is using AI to change the process itself, to remove steps, catch things that fall through the cracks, and generate outputs that currently require skilled people. Individual AI use makes the runners faster. Company-level AI integration redesigns the race. ### What company-level AI actually looks like - Document processing, AI reads invoices, POs, contracts and forms, extracts the fields, validates against existing records, and routes only the exceptions to a human. A business processing 500 invoices a month at 8 minutes each spends 67 hours a month on data entry; extraction cuts that to the 10–15% that needs review. - Summarisation at the process level, connected to the CRM and job system so a client file is already synthesised when a new team member picks it up. - Decision support built into workflows, flagging an invoice that does not match its PO before it reaches the approver, or churn-risk patterns before the account manager notices. - Quality and consistency checking, catching errors and deviations across high volumes that a human reviewer would miss. ### The gap between individual tools and company systems The reason individual AI use does not compound is primarily a data problem. The AI cannot see across the business because the data is not connected. The sequence matters: - Fix the data flows first, clean, connected, structured data is the foundation. - Then automate the routine with AI, the high-volume, rule-based work consuming skilled human time. - Then use AI to augment the judgments that remain, surfacing relevant context at the point of decision. ### What not to do - Do not start with an AI strategy, start with a specific problem AI can solve. - Do not buy an AI platform and wait for it to deliver value, it delivers value only when connected to specific processes and data. - Do not try to automate judgment, AI is for volume, rules, surfacing information, and consistency. - Do not ignore what your team is already doing, the people using AI informally are showing you where the opportunity is. ### What this is worth Individual AI use typically saves 20–40 minutes a day per regular user, but the saving accrues to individuals and does not reduce cost. Company-level AI applied to a single high-volume process typically reduces the human time required by 60–80%. For a process consuming 200 hours a month, that is 120–160 hours returned to the business permanently, about £50,000 to £67,000 a year from one process. And each integrated process makes the next one easier. The signal that this is your biggest problem: your team talks about AI tools they use personally, but you cannot point to a single process in the business that is meaningfully different because of AI. If the tools are everywhere but the impact is invisible in the numbers, the gains are staying with individuals. ### About Alfaveo Alfaveo builds AI-native operational systems, including Document Miner, our own AI extraction engine for invoices and documents. We do not build AI strategies. We build specific things that solve specific problems, starting with a working prototype in 10 business days. If what you have read here describes your situation, the most useful next step is a 30-minute conversation. No proposal, no pitch, just an honest look at where AI can actually move the needle in your business. Book a 30-minute call ---