Subsidy Application System Development for Municipal Programs

A subsidy application system is often imagined as a form that collects input and a list that shows what was sent. If that were all, a general-purpose form service would do. What municipal subsidy, cooperation-payment and benefit programs actually need begins after the form: checking the content of applications, reviewing them, notifying results, and carrying the whole flow on to the next round of the program without friction. We develop web reception and review systems for these programs, built around the guidelines of each one.

"Wouldn't a web form or a spreadsheet be enough?"

Staff who have just been awarded secretariat operations often ask us this. If only reception is needed, an existing form service might do. Or perhaps applications could be collected in a spreadsheet and reviewed there.

For a small and simple program, that can be a sensible choice. Depending on the program, though, trouble tends to appear in the following places.

• The subsidy or payment amount requires a complicated calculation, and applicants make mistakes
• Contradictions in the input go unnoticed until the form is submitted
• With several reviewers, it becomes hard to track who has checked which application and how far
• Programs spanning several rounds need past application data to be consulted
• Duplicate applications across programs have to be checked

These problems grow with the number of applications and shrink with the time available. Our development work is aimed at exactly these points.

Designing so that applicants are not asked to do extra work

What we pay most attention to is not burdening applicants. Even when a program needs complicated calculations, the applicant does not have to calculate anything; the system derives the necessary values from the input.

If entries contradict each other, the system says so on the spot. For instance, when the content of one field is inconsistent with another, the applicant notices and corrects it before submission. This input verification prevents faulty applications from being submitted at all and greatly reduces checking work and returned applications for the secretariat.

Lightening the applicant's burden directly lightens the secretariat's burden. We believe that designing in this order is the shortest road to a program that runs smoothly.

Administration screens fitted to the review desk

Once reception begins, the work on the review side begins in earnest. For the review administration screens, too, we have gone beyond standard functions and implemented what each project's operation requires.

One example is bulk status updating. By selecting several applications and changing their status at once, we reduce the effort of updating as review proceeds. For programs that run over several rounds, we display past application data so reviewers can consult earlier rounds easily. We also deal with duplicate application checks against other systems and reduce duplicate data entry.

These efficiency tools are hard to achieve with standard functions. We implement them one by one after hearing how each program is operated. That is what we mean by custom development.

How program type changes the design

Under the single name of subsidy or benefit, programs differ in character, and so do the demands on the system.

In many subsidy programs, an applicant applies, receives a grant decision, carries out the project, reports the results and the final amount is then confirmed. The design therefore has to look beyond reception to the receipt of documents after project completion and to the cross-checking of application data against reports. Data collected at application must be structured with later steps in mind.

In programs that pay a fixed amount to businesses that meet certain requirements, such as cooperation payments and benefits, speed matters most: quick reception, quick review, and a short time to payment. Input verification and review efficiency are then the core of the design. Applications also tend to concentrate in a short period, so screens that applicants can complete without hesitation and that staff can check easily directly affect how smoothly the whole program runs.

What we have built across multiple municipalities in the Kansai region are web reception and review systems for cooperation-payment and benefit programs. We have gained experience in judging where, between reception and review, the effort should go. For subsidy programs as well, we will listen to the guidelines and propose the necessary scope.

Screens that applicants can fill in without hesitation

Many applicants are not experienced office staff. Sole proprietors and shop owners may apply in the gaps of their working day. The care taken so that such people do not get lost on a screen ends up reducing the secretariat's inquiries and returned applications.

Take the order of input fields. If the fields follow the order of the documents the applicant holds, they can type while looking at those documents. If the fields follow the program's internal logic instead, the applicant has to look at the same document again and again, and input errors increase. A clear distinction between required and optional fields, examples of the expected format, and a visible sense of how far the applicant has to go: these things give applicants peace of mind.

It is also important that, when something is wrong, the applicant understands where and how to correct it. Merely displaying "error" leaves people at a loss. By pointing out the contradiction and explaining how to fix it, we let applicants resolve problems themselves so that they do not need to contact the secretariat. We design our input verification from this viewpoint, because a mechanism that lets applicants notice and fix their own errors is also the surest preventive measure for the secretariat.

Looking beyond the review

After review, results are notified and, where applicable, payment procedures follow. At this stage the application system should keep the necessary information in a form that is easy to retrieve later.

Examples are lists for preparing decision notices, the information needed for payment, and totals of cases and amounts across the program. If the system can output them, the secretariat is freed from manual transcription and tallying. What outputs are needed depends on how the secretariat operates. We listen to the flow of operations and decide the form of the output in consultation.

For programs spanning several rounds, application data has to be managed round by round while past data stays available for reference. If a business that applies across rounds can carry its earlier information forward, both the applicant and the reviewer save effort. Checking for duplicate applications against other programs or systems also plays an important role in keeping a program fair.

How a build proceeds

A build proceeds in the following steps.

Guidelines and hearing

We ask about the draft guidelines, the expected number of applications and the schedule until reception opens, and we fix the scope of the build. You may consult us before the guidelines are completely final.

Building the reception system

We build the reception system in a short time after the guidelines are final. The earlier you consult us on an urgent project, the easier it is to make a realistic plan.

Building the review administration screens

In parallel with the start of reception, we build the review-side administration screens, including status management and bulk updates.

Support after reception opens

After web reception has begun, we respond to feature additions for issues found during operation. Changes following a revision of the guidelines are also welcome.

Price guide

Prices vary with the complexity of the program, the expected number of applications and the extent of customization. The guide below shows typical ranges. We present a formal quotation individually after hearing your requirements.

A quotation-only request is also welcome. If you tell us what you know, such as the draft guidelines and the expected number of applications, we will give you a rough estimate.

After the rough estimate, we hear the requirements in detail, confirm the scope and the schedule until reception opens, and present a formal quotation. We explain the grounds for each factor that changes the amount significantly, such as the complexity of calculations, the functions needed on the review screens and the need to connect with other systems. Whether to include support after reception starts is also decided at this stage.

Handling personal information

A subsidy application system holds applicants' names, addresses, business details and sometimes bank account information. If such data leaks or is tampered with, trust in the program itself is damaged. We treat this as the heaviest premise from the first day of a build to the last.

For systems that handle personal information, the following points are generally essential: communication is encrypted; access to the administration screens is limited and it can be checked afterwards who did what; data is stored appropriately in case of trouble; and the handling of data after the reception period is decided in advance. The level required depends on the character of the program and the policy of the client.

For this reason we ask about the operating environment and the required security level before building. Whether the system must run in the LGWAN environment, or whether the client has its own security standards, are things we want to know early. Please tell us any conditions you already know, even at the draft guidelines stage.

Single-year budgets, procurement methods and operating environments

Municipal budgets are, in principle, set for a single fiscal year, so schedules for single-year programs tend to be especially tight. For that reason, it is easiest for us to propose a build plan if you consult us from the draft guidelines stage. If you have just been awarded secretariat operations and the guidelines are not yet firm, that is no obstacle. In fact, the sooner you call us, the better we can plan a schedule that does not strain anyone.

We also adapt to the client's procurement method, including negotiated contracts. We will tell you which documents and track-record materials are needed when you contact us.

Experience across municipalities in the Kansai region

We have built more than 25 web reception and review systems for cooperation-payment and benefit programs across multiple municipalities in the Kansai region, including prefectures, designated cities and cities, as part of the secretariat teams run by major prime contractors. Because of confidentiality obligations we do not name the municipalities or the clients, but working as a member of the prime contractor's team is our basic style. See our track record page for more.

Please call us before the guidelines are decided

A secretariat is a job in which little can be done once it has started. You may consult us before the guidelines are final. Tell us what you know, such as the expected number of applications, the schedule until reception opens and whether existing systems must be connected. We will come back with the scope of the build, how to proceed and a rough estimate.

We look forward to hearing from companies and consortiums awarded secretariat operations, and from municipal officials. Please use our contact form. For an overview of our work for program secretariats, see also the page on system development for subsidy program secretariats.