Source: [How Firefly operates your service](https://fireflysoftware.io/how-we-operate/) Description: How Firefly runs your operation: the method behind each step, the four paths a case can take, exceptions, decisions, and capacity. Language: en [Home](https://fireflysoftware.io/)/How we operate # How we run your operation, case by case. We prove the service on your cases, put a controlled scope live, and then run it day to day, exceptions included. [Book an operations review](https://fireflysoftware.io/contact/) [Explore our services](https://fireflysoftware.io/services/) A fully digital operation ## The right technology for each step. Every step runs in software and leaves a record. On our side there is no manual back office and no legacy stack. Four methods, one line A fully digital operation on one platform, four pieces in a line on the APIs and events. Three amber Firefly modules carry the method each step runs on: an AI agent, an AI model and approved rules. The fourth, an olive decision brick marked with a person, is where your team decides. Amber is Firefly’s work, each module marked with its method. The olive brick is your team’s decision. AI agents Agentic AI for casework that takes several steps: gathering, chasing, investigating, and reconciling. AI models Reading, classifying, extracting, and drafting. Approved rules Deterministic code for work that must be exact: calculations, eligibility, postings, and permissions. Nothing that moves money runs on a model alone. Your team The decisions your institution reserves, on a package we prepare. The four paths ## Every case takes one of four paths. Most cases take the normal path. The other three are where operations tend to break, so each has an owner and a rule. ### Normal path The case arrives complete. AI reads, extracts, and drafts, our checks confirm the work, and we deliver the output. The output leaves with the record of how it was produced. Five stations, one line The normal path, seen from the front. Five amber Firefly modules stand in one line. We receive the case and check its inputs. The middle module, marked with an AI model, reads and drafts. The last module, marked with a document, delivers the output with its evidence. Amber is Firefly’s work. The AI mark shows where AI works, and the document is the output. ### Authority path When a case needs a decision you reserve, we send the package to whoever holds the authority and record the wait as your dependency. We prepare the package. Your approver decides. A decision on the line The authority path, seen from the front. Amber Firefly modules stand in a line, with an olive decision brick third, marked with a person. We prepare the decision package, and someone on your team with delegated authority decides. The next module is drawn in dashed outline, because the work waits, tracked, until the decision comes back. Amber is Firefly’s work and the olive brick is your decision. The dashed module waits for it. ### Failure path When a system action fails or its result is unclear, an AI agent takes the case off the line and checks what reached your systems. We never blindly repeat a payment or a record change after a failure. We reconcile what happened first. A failed action, off the line The failure path, seen from the front. Amber Firefly modules stand in a line, and the third is lifted off it after a failed action, its place marked by a dashed line. Beside it stand a module marked with an AI agent, which resolves the exception, and a module with a data tile, where we reconcile what happened. We never blindly repeat a payment or a record change. The case goes back on the line once the records agree. Amber is Firefly’s work. The lifted module is the failed action, and the data piece is the reconciliation. ### Change path When a model, rule, procedure, or integration changes, we test the new version on representative cases. It goes live only after you approve it. A completed case keeps the version that produced it. A new version, in the same place The change path, seen from the front. Five amber Firefly modules stand in a line. The middle one, in dashed outline, is the current version, being retired. Its approved replacement snaps into the same place while the other four keep running. Amber is Firefly’s work. The dashed module is retiring, and its approved replacement snaps into place. Run the work ## We own the work, exceptions included. Our AI agents resolve missing information, inconsistent records, and failed system actions within the limits you approve. Anything outside them goes to your team, with the evidence prepared. ### Intake and triage We receive each case from your channels, check the inputs, and classify it. A duplicate or out-of-scope case comes back with the reason. Case class Sets the procedure, the checks, and the service level Clock Starts when the case is complete ### Exception management An exception gets an owner, a reason code, and an age the moment it opens. We escalate by age and severity. Owner An AI agent or your team, from the start Reason code Shows which fixes remove the most rework ### Decision handoff An authority matrix sets which decisions are yours and who holds each. We prepare a package, record the answer, and resume the case. Decision package The facts, the evidence, and the policy points it turns on Capacity and continuity ## We size capacity to your volume. We provision compute, model quotas, and fallbacks for your volume, case mix, hours, and languages, and review them monthly. ### Peaks Tell us about a month-end or a renewal season, and we provision for it in advance. ### Hours and languages Each service runs in the hours and languages your service schedule sets. ### Fallbacks If a model is unavailable, an approved fallback takes the step. If none can, the case goes to your team. ### Quality Sampling, an error taxonomy, and calibration with your reviewers keep the output to standard. How we start ## Start with a blueprint. Grow into an operation. Each step ends in something you can check before the next one starts. One service, four steps One service assembly in four steps, left to right on one platform. The operations review is a bare product plate, with nothing built yet. The Service Blueprint draws every module in dashed outline, as the plan. In controlled deployment, two modules are in place and the third is snapping in. In managed operation, every module is solid and connected to the APIs and events backbone. Amber is Firefly’s work. Dashed modules are the plan; solid modules on the APIs and events are the operation running. 1. 01 ### Operations review No charge. One conversation about the process, the volume, and what “done” looks like. 2. 02 ### Service Blueprint We define the scope, inputs, outputs, authority, and commercial model with you. It ends in a service you can contract. 3. 03 ### Controlled deployment We validate on normal and difficult cases and put a controlled scope live. You accept it against the agreed criteria. 4. 04 ### Managed operation We run the work day to day, review performance with you each month, and change nothing without your approval. Your first operation ## Bring us one operation. Tell us the process, the volume, and what “done” looks like. We will come back with a scope, a deployment plan, and a proposal. [Book an operations review](https://fireflysoftware.io/contact/) [Request a demo](https://fireflysoftware.io/contact/?request=demo)